range or xrange disallowed for big numbers

Chad Netzer cnetzer at mail.arc.nasa.gov
Mon Oct 7 22:15:52 CEST 2002


On Saturday 05 October 2002 03:23, Alex Martelli wrote:
> Chad Netzer wrote:
> > Is there a reason (technical or philosophical) to disallow:
> >
> >     range( 10000000000L, 10000000000L + 1L )
>
> Slowing down common cases of range and xrange (by keeping PyObject's
> or Python longs rather than C-level long's) is an unpleasant prospect,

Right.  After thinking some more, I thought that perhaps there should be 
range-like builtins that DO allow for 'long' arguments.  In fact, range() 
just returns a list, so I contend the the above quoted use of range *should* 
already work; It is just a list with length one, after all.

Since we already have automatic upcasting from ints to longs, it came as a 
surprise that xrange couldn't handle the longs.  But, by checking the type of 
the arguments, the normal xrange() could be used when only ints are involved, 
and a type that handles longs could be used otherwise.

So on the one hand, I argue that range() should, in principle, be able to 
handle 'long' arguments, and if this is implemented, xrange() should be 
updated to work with longs as well (by building a different object that can 
handle longs, only if they are needed; increasing build time very slightly, 
but not otherwise affecting the common case which uses just ints)

However, this does change semantics, and having a separate range builders 
such as lrange() and xlrange(), which explicitly handle longs, would perhaps 
be useful as builtins.  I do think that extending the existing range() and 
xrange() is more natural, now that ints are automatically converted to longs.

Thoughts?

-- 

Chad Netzer
cnetzer at mail.arc.nasa.gov




More information about the Python-list mailing list