range or xrange disallowed for big numbers
Chad Netzer
cnetzer at mail.arc.nasa.gov
Mon Oct 7 16:15:52 EDT 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