[Python-3000] range() issues

["Martin v. Löwis"]

Nick Coghlan wrote:
> 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

Right, inside, they are longs - but the *returned items* are all longs.

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

What simple pure C fixed point arithmetic would you be thinking of? The
long type *is* a pure C fixed point arithmetic.

There are perhaps some simplifications possible to longrangeiter_next
possible, e.g. it doesn't need to perform a multiplication, but could
just add the step each time. Also, it could cache the value 1 in a
global variable, rather than creating a fresh one each time.

Other than that, I cannot imagine why another fixed point arithmetic
might be significantly faster.

Regards,
Martin