On Wed, 14 Oct 2009 01:54:44 -0700 (PDT), Mark Dickinson <dicki...@gmail.com> wrote:
>On Oct 13, 10:39 pm, Steven D'Aprano ><ste...@remove.this.cybersource.com.au> wrote: >> On Tue, 13 Oct 2009 16:17:58 -0500, Peng Yu wrote: >> > Hi, >> >> > The following code does not run because range() does not accept a big >> > number. >> >> Incorrect. >> >> >>> range(sys.maxint+2, sys.maxint+5) >> >> [2147483649L, 2147483650L, 2147483651L] > >For what it's worth, there *is* a Python oddity lurking >under the surface here, at least for 64-bit. Here's >Python 2.6 on a 64-bit machine: Is that a 64-bit Python as well? >>>> range(2**31-1) >Traceback (most recent call last): > File "<stdin>", line 1, in <module> >MemoryError >>>> range(2**31) >Traceback (most recent call last): > File "<stdin>", line 1, in <module> >OverflowError: range() result has too many items > >The first call tries to allocate a list containing >2**31-1 integers. At 32 bytes per entry (8 for the >list pointer, 24 for the integer itself), that's not >surprising on a machine with < 64 Gb of memory. > >The second call, however, doesn't even try to >allocate the memory, but decides that the range can't >be represented. That's not right: this is an LP64 >machine, so the size of the list can be represented, >and the start, stop and step values are representable >as C longs (which is what CPython uses internally for >this purpose). On a machine with >64 Gb of memory, >this call should succeed. On an LP64 machine with ><64 Gb of memory, it should produce MemoryError, not >OverflowError. > >Mark -- http://mail.python.org/mailman/listinfo/python-list
