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