classification
Title: Use Py_ssize_t for rangeobject members
Type: enhancement Stage: test needed
Components: Interpreter Core Versions: Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: belopolsky, loewis, mark.dickinson, rhettinger
Priority: normal Keywords: patch

Created on 2006-08-15 13:19 by belopolsky, last changed 2010-05-01 00:23 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
rangeobject-patch.diff belopolsky, 2006-08-15 13:19 Unified diff against revision 51299
Messages (9)
msg50889 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2006-08-15 13:19
Use Py_ssize_t for rangeobject start, step and len and rangeiterobject's 
index, start, step and length.
msg50890 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-09-16 17:41
Logged In: YES 
user_id=21627

This might be superseded by 1546078
msg62711 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-23 01:25
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.
msg62712 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-02-23 01:29
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.
msg62715 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-23 02:22
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?
msg62941 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-24 21:35
> 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.
msg62973 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-02-25 06:09
I fail to see the need for this, from more than an academic point of
you. What specific event triggered your working on this?
msg62982 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-25 14:33
> 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.
msg104679 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-05-01 00:23
Closing as out of date.
History
Date User Action Args
2010-05-01 00:23:58mark.dickinsonsetstatus: open -> closed

nosy: + mark.dickinson
messages: + msg104679

resolution: out of date
2009-05-15 02:29:04ajaksu2setstage: test needed
type: enhancement
versions: + Python 2.7, - Python 2.6
2008-02-25 14:33:08belopolskysetmessages: + msg62982
2008-02-25 06:09:53loewissetmessages: + msg62973
2008-02-24 21:35:52belopolskysetmessages: + msg62941
2008-02-23 02:22:59belopolskysetmessages: + msg62715
2008-02-23 01:29:18rhettingersetnosy: + rhettinger
messages: + msg62712
2008-02-23 01:25:33belopolskysetmessages: + msg62711
2006-08-15 13:19:35belopolskycreate