Use Py_ssize_t for rangeobject members

[abalkin]

BPO	1540617
Nosy	@loewis, @rhettinger, @mdickinson, @abalkin
Files	rangeobject-patch.diff: Unified diff against revision 51299

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-05-01.00:23:58.591>
created_at = <Date 2006-08-15.13:19:35.000>
labels = ['interpreter-core', 'type-feature']
title = 'Use Py_ssize_t for rangeobject members'
updated_at = <Date 2010-05-01.00:23:58.580>
user = 'https://github.com/abalkin'

bugs.python.org fields:

activity = <Date 2010-05-01.00:23:58.580>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2010-05-01.00:23:58.591>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2006-08-15.13:19:35.000>
creator = 'belopolsky'
dependencies = []
files = ['7468']
hgrepos = []
issue_num = 1540617
keywords = ['patch']
message_count = 9.0
messages = ['50889', '50890', '62711', '62712', '62715', '62941', '62973', '62982', '104679']
nosy_count = 4.0
nosy_names = ['loewis', 'rhettinger', 'mark.dickinson', 'belopolsky']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1540617'
versions = ['Python 2.7']

[abalkin]

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

[loewis]

Logged In: YES
user_id=21627

This might be superseded by 1546078

[abalkin]

bpo-1546078 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.

[rhettinger]

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.

[abalkin]

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?

[abalkin]

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.

[loewis]

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

[abalkin]

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.

[mdickinson]

Closing as out of date.