On 02/05/2015 22:40, Jon Ribbens wrote:
On 2015-05-02, BartC <b...@freeuk.com> wrote:
So do I, I think, if no-one is willing to admit that the original way of
implementing range() was a glaring mistake.
I think the issue is that nobody else here thinks the "original way"
of iterating was to use range(), for anything other than extremely
small ranges.
What /is/ the way to iterate then?
I don't have much Python code lying around, but the first couple of
files I looked at (not mine), one had this:
for i in range(7,-1,-1):
for j in range(8):
another had:
for l in range(1,17):
for i in range(1, self.bits[l] + 1):
for i in range(256):
and so on. Plenty of examples. This was probably converted to Python
from elsewhere, but why shouldn't it be able to run code trivially
converted from somewhere else, without being unnecessarily slow? (What
would be the 'Pythonic' way of writing a Jpeg decoder, as this was, anyway?)
I don't think the small size of the range is a mitigating factor, other
than it won't run out of memory. Even a small loop can be executed
millions of times.
For information, it looks like xrange() was added on 26 Oct 1993,
which pre-dates Python 1.0.
OK, so it's just an irritation then, as a workaround has been available
for a long time. (For example, if you use xrange, it won't work on 3.x.
If you use range, then it might be inefficient on 2.x.)
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
