Mark Dickinson dicki...@gmail.com added the comment:
Closing as out of date.
--
nosy: +mark.dickinson
resolution: - out of date
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1540617
Changes by Daniel Diniz aja...@gmail.com:
--
stage: - test needed
type: - feature request
versions: +Python 2.7 -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1540617
___
Martin v. Löwis added the comment:
I fail to see the need for this, from more than an academic point of
you. What specific event triggered your working on this?
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1540617
Alexander Belopolsky added the comment:
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
Raymond Hettinger added the comment:
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.
--
nosy: +rhettinger
_
Tracker [EMAIL PROTECTED]
Alexander Belopolsky added the comment:
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
