cnetzer at mail.arc.nasa.gov
Mon Feb 24 22:59:32 CET 2003
On Fri, 2003-02-21 at 19:45, Magnus Lie Hetland wrote:
> That's good advice, of course, but won't really help. Once the limit
> exceets the integer range (and, thus, is a long) xrange will no longer
> work (for some reason I don't really understand -- why must xrange use
It is implemented with a C structure that uses C long's as the
variables. It simply can't handle arbitrarily large numbers. And
simply changing it to do so would slow down the common case, so people
haven't done it.
I'm actually going to be submitting patches to 2.3 which change this
behavior for range(), and I'm working on an acceptable solution for
xrange(). Also, there is a possibility that an xrange()-like generator
or iterator will be added to the standard distribution at some point.
But, thanks for the added data point. I was not sure I could convince
the BDFL that this issue was anything more than a very occasional
quibble; and yet I've seen several others remark on the inconsistency,
and working with numerics and graphics, it has bitten me a few times.
In short, I have 'range(1e20, 1e21, 1e19)' working and hope to have
xrange() doing the same (all with NO performance penalty to the
non-long-int common case)
Bay Area Python Interest Group - http://www.baypiggies.net/
(any opinion expressed is my own and not NASA's or my employer's)
More information about the Python-list