Alexander Belopolsky added the comment: > 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. _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1540617> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com