Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89638 > unrolled thread

l = range(int(1E9))

Back to article view | Back to comp.lang.python

Contents

  l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 18:06 +0200
    Re: l = range(int(1E9)) Grant Edwards <invalid@invalid.invalid> - 2015-04-30 16:33 +0000
      Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 19:26 +0200
        Re: l = range(int(1E9)) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 03:41 +1000
          Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 20:44 +0200
      Re: l = range(int(1E9)) Roel Schroeven <roel@roelschroeven.net> - 2015-04-30 21:40 +0200
    Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-04-30 16:55 +0000
      Re: l = range(int(1E9)) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 03:20 +1000
        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-01 15:20 +1000
          Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 08:08 +0200
        Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 16:26 +0100
          Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 16:40 +0100
            Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 17:17 +0100
              Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 17:39 +0100
                Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 19:34 +0100
                  Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 20:15 +0100
                    Re: l = range(int(1E9)) Marko Rauhamaa <marko@pacujo.net> - 2015-05-02 22:26 +0300
                    Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 20:51 +0100
                      Re: l = range(int(1E9)) Joel Goldstick <joel.goldstick@gmail.com> - 2015-05-02 17:21 -0400
                      Re: l = range(int(1E9)) Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-02 15:31 -0600
                      Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-02 21:40 +0000
                        Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 23:26 +0100
                        Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 23:33 +0100
                          Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-03 00:13 +0000
                          Re: l = range(int(1E9)) Michael Torrie <torriem@gmail.com> - 2015-05-02 20:07 -0600
                          Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-03 03:16 +0100
                            Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:16 +1000
                              Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-03 21:30 +1000
                              Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-03 19:36 +0100
                          Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:15 +1000
                            Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-03 21:29 +1000
                        Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 19:26 -0400
                          Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-03 00:01 +0000
                            Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 23:18 -0400
                              Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-03 03:40 +0000
                        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:05 +1000
                      Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 19:51 -0400
                      Re: l = range(int(1E9)) Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-02 22:51 -0600
                        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:21 +1000
                  Re: l = range(int(1E9)) Marko Rauhamaa <marko@pacujo.net> - 2015-05-02 22:15 +0300
              Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 20:32 +1000
                Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-03 20:59 +1000
          Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 18:41 -0400
      Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 19:28 +0200
    Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-04-30 13:02 -0400
    Re: l = range(int(1E9)) Gary Herron <gherron@digipen.edu> - 2015-04-30 10:05 -0700
      Re: l = range(int(1E9)) Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-04-30 17:12 +0000
        Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 20:50 +0200
          Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-30 21:53 +0100
            Re: l = range(int(1E9)) ElChino <elchino@cnn.cn> - 2015-04-30 23:23 +0200
              Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-01 08:45 +1000
                Re: l = range(int(1E9)) ElChino <elchino@cnn.cn> - 2015-05-01 01:03 +0200
              Re: l = range(int(1E9)) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 09:12 +1000
                Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 07:04 +0200
                  Re: l = range(int(1E9)) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-01 13:15 +0200
                    Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 14:22 +0200
                  Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-01 22:00 -0400
              Use ‘python2’ or ‘python3’, explicit is better than implicit  (was: l = range(int(1E9))) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 09:19 +1000
                Re: Use 'python2' or 'python3', explicit is better than implicit  (was: l = range(int(1E9))) Rustom Mody <rustompmody@gmail.com> - 2015-04-30 19:24 -0700
              Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-01 09:23 +1000
            Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 06:19 +0200
              Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-01 05:41 +0100
              Re: l = range(int(1E9)) Michael Torrie <torriem@gmail.com> - 2015-05-01 07:25 -0600
                Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 16:12 +0200
    Re: l = range(int(1E9)) Gisle Vanem <gvanem@yahoo.no> - 2015-04-30 20:23 +0200
      Re: l = range(int(1E9)) alister <alister.nospam.ware@ntlworld.com> - 2015-04-30 18:48 +0000
        Re: l = range(int(1E9)) Dave Angel <davea@davea.name> - 2015-04-30 14:59 -0400
          Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 22:18 +0200
            Re: l = range(int(1E9)) Tim Chase <python.list@tim.thechases.com> - 2015-04-30 16:41 -0500
              Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 07:19 +0200
    Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-01 14:42 +1000
      Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 07:13 +0200
      Re: l = range(int(1E9)) Tony the Tiger <tony@tiger.invalid> - 2015-05-02 21:28 +0000
        Re: l = range(int(1E9)) Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-02 15:32 -0600
        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 20:56 +1000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#89805

On 2015-05-02, BartC <bc@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.

For information, it looks like xrange() was added on 26 Oct 1993,
which pre-dates Python 1.0.

[toc] | [prev] | [next] | [standalone]

#89808

On 02/05/2015 22:40, Jon Ribbens wrote:
> On 2015-05-02, BartC <bc@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.
>
> For information, it looks like xrange() was added on 26 Oct 1993,
> which pre-dates Python 1.0.
>

No chance, or so I thought, but to save others from looking it up 
https://hg.python.org/cpython/annotate/89e1e5d9ccbf/Python/bltinmodule.c

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#89809

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

[toc] | [prev] | [next] | [standalone]

#89819

On 2015-05-02, BartC <bc@freeuk.com> wrote:
> On 02/05/2015 22:40, Jon Ribbens wrote:
>> 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?

Other people have already explained that to you several times.
If you want a literal 'for (i = 0; i < x; i++)' loop then it's
'for i in xrange(x)' (from Python 1.0 to Python 2.7), but most
of the time you simply wouldn't be writing code that works that
way.

> 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.

... of extremely small ranges, just as I said.

> 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.

So what? The overhead of creating a list of 17 integers is trivial
compared to executing the rest of the code. As the man said:
"premature optimization is the root of all evil".

[toc] | [prev] | [next] | [standalone]

#89820

On 05/02/2015 04:33 PM, BartC wrote:
> 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.)

In both Python 2.7 and 3.3+, you can use the 3rd-party six module to
help with forward compatibility:

from six.moves import xrange

In Python 2.7, it's just the normal xrange (importing is a no op
basically), but in Python 3 it points to range.

Kind of wish parts of six were in the Python standard library.

[toc] | [prev] | [next] | [standalone]

#89821

On 03/05/2015 03:07, Michael Torrie wrote:
> On 05/02/2015 04:33 PM, BartC wrote:
>> 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.)
>
> In both Python 2.7 and 3.3+, you can use the 3rd-party six module to
> help with forward compatibility:
>
> from six.moves import xrange
>
> In Python 2.7, it's just the normal xrange (importing is a no op
> basically), but in Python 3 it points to range.
>
> Kind of wish parts of six were in the Python standard library.
>

Links to other useful third party modules are given here 
https://docs.python.org/3/howto/pyporting.html

I doubt that six will ever make the standard library as 2.7 only has 
another five years in official support.  By that time I suppose we'll to 
going through the porting pain all over again with the transition from 
Python 3 to Python 4.  Alright, alright, only joking :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#89860

On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote:

> I doubt that six will ever make the standard library as 2.7 only has
> another five years in official support.  By that time I suppose we'll to
> going through the porting pain all over again with the transition from
> Python 3 to Python 4.  Alright, alright, only joking


Guido has said that Python 4 will just be an incremental update from 3.x.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89863

On Sun, May 3, 2015 at 9:16 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote:
>
>> I doubt that six will ever make the standard library as 2.7 only has
>> another five years in official support.  By that time I suppose we'll to
>> going through the porting pain all over again with the transition from
>> Python 3 to Python 4.  Alright, alright, only joking
>
>
> Guido has said that Python 4 will just be an incremental update from 3.x.

There is still, as I understand it, the possibility that Python 4.0
will ditch some things that will have been deprecated for a long time
by 3.9. But yes, it'll be no more upheavalous to go from 3.9 to 4.0
than from 3.8 to 3.9.

ChrisA

[toc] | [prev] | [next] | [standalone]

#89889

On 03/05/2015 12:30, Chris Angelico wrote:
> On Sun, May 3, 2015 at 9:16 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote:
>>
>>> I doubt that six will ever make the standard library as 2.7 only has
>>> another five years in official support.  By that time I suppose we'll to
>>> going through the porting pain all over again with the transition from
>>> Python 3 to Python 4.  Alright, alright, only joking
>>
>>
>> Guido has said that Python 4 will just be an incremental update from 3.x.
>
> There is still, as I understand it, the possibility that Python 4.0
> will ditch some things that will have been deprecated for a long time
> by 3.9. But yes, it'll be no more upheavalous to go from 3.9 to 4.0
> than from 3.8 to 3.9.
>
> ChrisA
>

https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_GET_SIZE

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#89859

On Sun, 3 May 2015 08:33 am, BartC wrote:

> 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.)


That is trivially easy to deal with. Put this at the top of your module:

try:
    xrange
except NameError:
    xrange = range


and then use xrange throughout the module. Or if you prefer:

try:
    range = xrange
except NameError:
    pass

and just use range.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89862

On Sun, May 3, 2015 at 9:15 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Or if you prefer:
>
> try:
>     range = xrange
> except NameError:
>     pass
>
> and just use range.

I prefer this idiom, on the basis that code should be written for the
more recent version, and have minimal code to support older versions.
Then when you drop support for the older versions, all you have to do
is delete a bit at the top. The same principle applies to the
__future__ import system - you can declare that your Python 2.5 code
is able to use the 'with' statement, but you can't (and shouldn't)
make your 2.6+ code use 'with' as a name.

ChrisA

[toc] | [prev] | [next] | [standalone]

#89815

On 5/2/2015 5:40 PM, Jon Ribbens wrote:

> For information, it looks like xrange() was added on 26 Oct 1993,
> which pre-dates Python 1.0.

1.0 was released Feb 1991.  3.2 exactly 20 years later.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#89817

On 2015-05-02, Terry Reedy <tjreedy@udel.edu> wrote:
> On 5/2/2015 5:40 PM, Jon Ribbens wrote:
>> For information, it looks like xrange() was added on 26 Oct 1993,
>> which pre-dates Python 1.0.
>
> 1.0 was released Feb 1991.  3.2 exactly 20 years later.

No, you are thinking of 0.9, which was indeed February 1991.

[toc] | [prev] | [next] | [standalone]

#89823

On 5/2/2015 8:01 PM, Jon Ribbens wrote:
> On 2015-05-02, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 5/2/2015 5:40 PM, Jon Ribbens wrote:
>>> For information, it looks like xrange() was added on 26 Oct 1993,
>>> which pre-dates Python 1.0.
>>
>> 1.0 was released Feb 1991.  3.2 exactly 20 years later.
>
> No, you are thinking of 0.9, which was indeed February 1991.

'scuse me, I meant 1992


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#89824

On 2015-05-03, Terry Reedy <tjreedy@udel.edu> wrote:
> On 5/2/2015 8:01 PM, Jon Ribbens wrote:
>> On 2015-05-02, Terry Reedy <tjreedy@udel.edu> wrote:
>>> On 5/2/2015 5:40 PM, Jon Ribbens wrote:
>>>> For information, it looks like xrange() was added on 26 Oct 1993,
>>>> which pre-dates Python 1.0.
>>>
>>> 1.0 was released Feb 1991.  3.2 exactly 20 years later.
>>
>> No, you are thinking of 0.9, which was indeed February 1991.
>
> 'scuse me, I meant 1992

No, it was January 1994.

http://python-history.blogspot.co.uk/2009/01/brief-timeline-of-python.html

[toc] | [prev] | [next] | [standalone]

#89857

On Sun, 3 May 2015 07:40 am, Jon Ribbens wrote:

> On 2015-05-02, BartC <bc@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.
> 
> For information, it looks like xrange() was added on 26 Oct 1993,
> which pre-dates Python 1.0.

Ah yes, you are right: my searching failed to find xrange in Python 1.0.1,
but it was actually introduced in 1.0.0. This is from the Misc/NEWS file:

* New function xrange() creates a "range object".  Its arguments are
the same as those of range(), and when used in a for loop a range
objects also behaves identical.  The advantage of xrange() over
range() is that its representation (if the range contains many
elements) is much more compact than that of range().  The disadvantage
is that the result cannot be used to initialize a list object or for
the "Python idiom" [RED, GREEN, BLUE] = range(3).  On some modern
architectures, benchmarks have shown that "for i in range(...): ..."
actually executes *faster* than "for i in xrange(...): ...", but on
memory starved machines like PCs running DOS range(100000) may be just
too big to be represented at all...





-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89816

On 5/2/2015 5:31 PM, Ian Kelly wrote:

> Would it have been better if range() had been implemented as xrange()
> from the beginning? Sure, that would have been great. Except for one
> small detail: the iterator protocol didn't exist back then.

For loops originally used the getitem iterator protocol. xrange objects 
have a __getitem__ method, but not __iter__ or __next__.  As Mark 
pointed out, they were introduced in 1993.

Getitem iterators still work.  If iter(ob) is passed object ob without 
.__iter__, iter looks for ob.__getitem__ and if present, returns 
iterator(ob), where iterator is an internal protocol adapter class.  Its 
__next__ method calls ob.__getitem__ and converts IndexError to 
StopIteration.

In 3.4.3:

class xrange:
     def __init__(self, start, stop, step):
         if step < 1:
             raise ValueError('incomplete xrange require positive step')
         self.val = start
         self.stop = stop
         self.step = step
     def __getitem__(self, dummy):
         val = self.val
         self.val = val + self.step
         if val < self.stop:
             return val
         else:
             raise IndexError('')

it = iter(xrange(1, 10, 3))
print(type(it))
for i in it:
     print(i)
#
<class 'iterator'>
1
4
7

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#89829

On Sat, May 2, 2015 at 5:51 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 5/2/2015 5:31 PM, Ian Kelly wrote:
>
>> Would it have been better if range() had been implemented as xrange()
>> from the beginning? Sure, that would have been great. Except for one
>> small detail: the iterator protocol didn't exist back then.
>
>
> For loops originally used the getitem iterator protocol. xrange objects have
> a __getitem__ method, but not __iter__ or __next__.  As Mark pointed out,
> they were introduced in 1993.

I'm aware of getitem iterators; just didn't realize that xrange used
it or was that old.

[toc] | [prev] | [next] | [standalone]

#89861

On Sun, 3 May 2015 02:51 pm, Ian Kelly wrote:

> On Sat, May 2, 2015 at 5:51 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 5/2/2015 5:31 PM, Ian Kelly wrote:
>>
>>> Would it have been better if range() had been implemented as xrange()
>>> from the beginning? Sure, that would have been great. Except for one
>>> small detail: the iterator protocol didn't exist back then.
>>
>>
>> For loops originally used the getitem iterator protocol. xrange objects
>> have
>> a __getitem__ method, but not __iter__ or __next__.  As Mark pointed out,
>> they were introduced in 1993.
> 
> I'm aware of getitem iterators; just didn't realize that xrange used
> it or was that old.


Yep, xrange objects are *not* iterators:

py> r = xrange(100)
py> iter(r) is r
False
py> next(r)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: xrange object is not an iterator



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89788

BartC <bc@freeuk.com>:

> (I tried an empty loop counting to 1 billion in Python 2.x, using 'for
> i in range'. It ran out of memory. Counting to 100 million instead, it
> worked, but still used a massive 1.5GB RAM while doing so (and took 6
> seconds to count to 100M, not too bad for Python)
>
> Outside Python, it might typically take a few seconds to count to 1
> billion, and would use virtually no memory.
>
> Why would anyone want to loop over all those numbers instead of
> iterating over actual data? For any number of reasons. Counting how
> many happy numbers are in that range for one!)

You're doing it wrong. Here's the Pythonic way to iterate over a billion
numbers:

    def loop(i):
        if i < 1000000000:
            do_stuff(i)
            keep_iterating(i + 1)

    loop(0)


Marko

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web