l = range(int(1E9))

[BartC]

On 02/05/2015 22:40, Jon Ribbens wrote:
> On 2015-05-02, BartC <bc at 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