Use Py_ssize_t for rangeobject start, step and len and rangeiterobject's 
index, start, step and length.

Logged In: YES 
user_id=21627

This might be superseded by 1546078

issue1546078 presents a much more ambitious patch - supporting arbitrary 
longs in range.  It looks like that patch was applied to py3k branch 
where performance issues are not yet a concern.

Unless there are plans to backport 1546078, I would like to see this 
patch  make it in 2.6.  (On 64-bit platforms, it is probably as good as 
supporting arbitrary longs and thus will make 2.6 closer to 3.0.)

The patch is still valid for the trunk.

FWIW, the current Py2.6 code for enumerate() and itertools.count() both
show how to support arbitrary longs without killing the performance of
common cases.

Yes, index/longindex optimization is nice and can be applied to xrange.  
However, I don't think python-dev will be happy with the 1546078-style 
changes going to 2.6 and optimization patches are probably premature for 
3.0.

The ssize_t approach has a nice property of not affecting 32-bit 
platforms where objects with offsets >2**31 cannot exist and will 
satisfy most of the needs on 64-bit platforms.

I cannot think of a use case for xrange output that cannot be used as 
index.  On the other hand, such functionality would be trivial to 
implement if needed by an application:

def range(start, stop, step): 
    i = start 
    while i < stop: 
        yield i 
        i += step


Maybe you could mark this issue as "easy" and see if the patch can be 
reviewed in one of the bugs days?

> 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 
right.

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.

I fail to see the need for this, from more than an academic point of
you. What specific event triggered your working on this?

> What specific event triggered your working on this?

That was a long time ago, but IIRC, we had some code dealing with large 
files that grew up beyond 2G.  The files contained fixed-length records 
and we used xrange to iterate over record offsets. We worked around that 
problem by replacing uses of xrange with large "start"/"end" with 
nympy's arange.