Martin v. Löwis wrote:
In the slow example given, only one of the returned items needs to be a
long
This is Py3k. They are all longs.
Not inside the object they aren't - I believe the optimised one uses C
longs internally, and converts to a Python long when it returns the
values, whereas 'longrange' uses Python long objects internally as well.
Oddly enough, this is going to make the increment/decrement operations
for the counter quite a bit slower :)
One way to optimise this (since all we need to support here is counting
rather than arbitrary arithmetic) would be for the longrange iterator to
use some simple pure C fixed point arithmetic internally to keep track
of an arbitrarily long counter, and only convert to a Python long when
it has to (just like the optimised shortrange iterator).
I'm not sure it is worth the hassle though.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
