| msg93063 - (view) |
Author: Krzysztof Szawala (kszawala) |
Date: 2009-09-24 10:38 |
| range() method fails with the following error message: " Traceback (most recent call last): File "", line 1, in OverflowError: range() result has too many items " when passing a valid integer value of 9999999999. This value is obtained from OptParse command-line option as a valid ingeter. Applies to both Windows and Linux (32 and 64-bit). |
|
|
| msg93064 - (view) |
Author: Eric V. Smith (eric.smith) *  |
Date: 2009-09-24 10:54 |
| This doesn't crash the interpreter, so I'm changing it to "behavior". The number of items in a range() must fit into a native int. What are you doing with the range? Could you use xrange instead? |
|
|
| msg93066 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-09-24 11:08 |
| I *think* range uses long internally, so 9999999999 should be okay on an LP64 machine. Except that of course the range() result must also fit in memory: on a 64-bit machine range(9999999999) would need more than 300 Gb of memory. (That's 32 bytes per entry: 24 bytes for each integer and 8 bytes for the list pointer.) |
|
|
| msg93070 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-09-24 11:25 |
| Might it make more sense for this range call to return a MemoryError rather than an OverflowError, on 64-bit machines? |
|
|
| msg93071 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-09-24 11:36 |
| Mark] > I *think* range uses long internally Aargh! Sorry, Eric. I take it back. *xrange* uses longs internally (and used to use ints once upon a time, IIRC), but there's a weird mix of int and long in builtin_range that doesn't make any sense to me. I suspect it's historical, and may have to do both with the xrange int->long switch and the int -> Py_ssize_t switch. |
|
|
| msg93095 - (view) |
Author: Brett Cannon (brett.cannon) * |
Date: 2009-09-24 20:53 |
| Both range and xrange were mucked with so much just before and during py3k development that I am sure odd inconsistencies of what they use internally are oversights. |
|
|
| msg95928 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-12-03 12:17 |
| I suspect the ints in builtin_range should have been changed to Py_ssize_t when PEP 353 was implemented. I've fixed them in trunk in r76625; it doesn't seem worth changing this in the 2.6 branch. So on an LP64 machine with sufficient memory, range(2**31) should now work. |
|
|
| msg95929 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-12-03 12:21 |
| Whoops. That revision number should have been r76648. |
|
|