Range() limit

[Magnus Lie Hetland]

In article <mailman.1046124223.31565.python-list at python.org>, Chad Netzer wrote:
>On Fri, 2003-02-21 at 19:45, Magnus Lie Hetland wrote:
>
>> That's good advice, of course, but won't really help. Once the limit
>> exceets the integer range (and, thus, is a long) xrange will no longer
>> work (for some reason I don't really understand -- why must xrange use
>> ints?)
>
>It is implemented with a C structure that uses C long's as the
>variables.  It simply can't handle arbitrarily large numbers.  And
>simply changing it to do so would slow down the common case, so people
>haven't done it.
>
>I'm actually going to be submitting patches to 2.3 which change this
>behavior for range(), and I'm working on an acceptable solution for
>xrange().  Also, there is a possibility that an xrange()-like generator
>or iterator will be added to the standard distribution at some point.

I thought perhaps the following would work, but, alas, no...

  from itertools import islice, count

  for i in islice(count(), 10**10):
      do_something(i)

here, too, the requirement is that i remains an int. But with this
amount of code, it's just as easy to implement it yourself, of course.

>But, thanks for the added data point.  I was not sure I could convince
>the BDFL that this issue was anything more than a very occasional
>quibble; and yet I've seen several others remark on the inconsistency,
>and working with numerics and graphics, it has bitten me a few times.

Yup. It will me interesting to see how your patch turns out.

>In short, I have 'range(1e20, 1e21, 1e19)' working and hope to have
>xrange() doing the same (all with NO performance penalty to the
>non-long-int common case)

Great :)

-- 
Magnus Lie Hetland               "Nothing shocks me. I'm a scientist." 
http://hetland.org                                   -- Indiana Jones