This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, loewis, rhettinger
Date 2008-02-24.21:35:52
SpamBayes Score 0.0022336398
Marked as misclassified No
Message-id <>
> enumerate() and itertools.count() both
> show how to support arbitrary longs without
> killing the performance of common cases.

Unlike enumerate() and count(), range object has 3 integer members: 
start, step and len.  Doubling all of them as in count does not sound 

On the other hand, range has a unique implementation advantage over 
enumerate() and count() because one can determine whether long integers 
will ever be produced at initialization.

It looks like a reasonable solution would be to have xrange produce a 
subtype of rangeobject type supporting long integers in the cases when 
current code bails out.

This smells too much like int/long dichotomy in 2.x that was rejected in 
3.0, but I don't see much of the downside.

In any case, I can produce a patch (simply reusing the code from py3k, 
but only when range_new determines that long ints will be produceable 
from the range), but would like to hear from Martin or Raymond first.
Date User Action Args
2008-02-24 21:35:53belopolskysetspambayes_score: 0.00223364 -> 0.0022336398
recipients: + belopolsky, loewis, rhettinger
2008-02-24 21:35:53belopolskysetspambayes_score: 0.00223364 -> 0.00223364
messageid: <>
2008-02-24 21:35:52belopolskylinkissue1540617 messages
2008-02-24 21:35:52belopolskycreate