| msg50889 - (view) |
Author: Alexander Belopolsky (belopolsky) *  |
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) * |
Date: 2006-09-16 17:41 |
| Logged In: YES user_id=21627 This might be superseded by 1546078 |
|
|
| msg62711 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2008-02-23 01:25 |
| 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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2010-05-01 00:23 |
| Closing as out of date. |
|
|