Magnus Lie Hetland
mlh at furu.idi.ntnu.no
Tue Feb 25 03:22:07 CET 2003
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
>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):
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)
Magnus Lie Hetland "Nothing shocks me. I'm a scientist."
http://hetland.org -- Indiana Jones
More information about the Python-list