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


Groups > comp.lang.python > #85429

Re: __next__ and StopIteration

Date 2015-02-09 22:16 -0800
From Charles Hixson <charleshixsn@earthlink.net>
Subject Re: __next__ and StopIteration
References <mailman.18573.1423509383.18130.python-list@python.org> <54d94307$0$12998$c3e8da3$5496439d@news.astraweb.com> <CALwzidnufuFPX1K0QrAJZbEtS79xvOmhM7ZZ8t9dJSiKVvhUqQ@mail.gmail.com> <54D98A35.9060203@earthlink.net> <CAPTjJmrcbOYCuZCgiq9gStEG34nAvQ2gS-vZC-WUuAOPUV3hPw@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.18596.1423549003.18130.python-list@python.org> (permalink)

Show all headers | View raw


On 02/09/2015 08:46 PM, Chris Angelico wrote:
> On Tue, Feb 10, 2015 at 3:33 PM, Charles Hixson
> <charleshixsn@earthlink.net> wrote:
>>> The proper version of the "hard way" is:
>>>
>>> 1) The __iter__ method of the iterable constructs a new iterator
>>> instance and returns it.
>>>
>>> 2) The __iter__ method of the *iterator* simply returns itself.
>>>
>>> 3) The __next__ method of the iterator tracks the current value and
>>> returns the next value. Note that the iterator should never store the
>>> iterable's data internally, unless the iterable is immutable and the
>>> calculation is trivial (e.g. a range object). Instead, it should
>>> determine the next value by referring to its source iterable.
>> So if I'm understanding this correctly, I should implement as an internal
>> class within Grid something like:
>>      class GridIter(Iterator):
> Apart from the fact that you shouldn't have to explicitly subclass
> Iterator, yes. But this is the hard way to do things. The easy way is
> to simply define an __iter__ method on your Grid which returns an
> iterator - and one excellent form of iterator, for custom classes like
> this, is a generator object. Your original code can slot happily in,
> with one tiny change:
>
> class Grid:
>      blah blah
>
>      def __iter__(self):
>          for row in range(self._rows):
>              for col in range(self._cols):
>                  if self._grid[row][col]:
>                      yield self._grid[row][col]
>
> The only change is to remove the explicit StopIteration at the end;
> once your generator function terminates, the generator object will
> raise StopIteration forever afterward, without any help from you.
> (Also, post-PEP479, the explicit raise will actually cause
> RuntimeError, so it's not just superfluous, but actually a problem.)
>
> But I'm guessing that your grid and rows are actually iterable
> themselves. If they are, you can cut the code down to this:
>
>      def __iter__(self):
>          for row in self._grid:
>              for cell in row:
>                  if cell: yield cell
>
> or a generator expression:
>
>      def __iter__(self):
>          return (cell for row in self._grid for cell in row if cell)
>
> or itertools.chain and filter, if you so desired. As long as you
> return an iterator, you're fine. This is far and away the easiest way
> to make a class iterable.
>
> ChrisA
Yes, rows and cols are lists, but I'm going to need to iterate through 
them more than once.  I'd rather do without a included class, but if a 
properly formed iterator can only be cycled through once, and if I 
understand properly that means I can't use the "class instance is it's 
own iterator" form.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

__next__ and StopIteration Charles Hixson <charleshixsn@earthlink.net> - 2015-02-09 11:14 -0800
  Re: __next__ and StopIteration Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-02-09 19:27 +0000
  Re: __next__ and StopIteration Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-10 10:30 +1100
    Re: __next__ and StopIteration Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-09 16:56 -0700
      Re: __next__ and StopIteration Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-10 11:42 +1100
        Re: __next__ and StopIteration Chris Angelico <rosuav@gmail.com> - 2015-02-10 11:54 +1100
          Re: __next__ and StopIteration Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-10 12:11 +1100
            Re: __next__ and StopIteration Chris Angelico <rosuav@gmail.com> - 2015-02-10 12:58 +1100
        Re: __next__ and StopIteration Chris Kaynor <ckaynor@zindagigames.com> - 2015-02-09 16:59 -0800
          Re: __next__ and StopIteration Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-10 16:54 +1100
        Re: __next__ and StopIteration Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-10 01:30 -0700
        Re: __next__ and StopIteration Chris Kaynor <ckaynor@zindagigames.com> - 2015-02-10 09:27 -0800
    Re: __next__ and StopIteration Charles Hixson <charleshixsn@earthlink.net> - 2015-02-09 20:33 -0800
    Re: __next__ and StopIteration Chris Angelico <rosuav@gmail.com> - 2015-02-10 15:46 +1100
    Re: __next__ and StopIteration Charles Hixson <charleshixsn@earthlink.net> - 2015-02-09 22:16 -0800
    Re: __next__ and StopIteration Chris Angelico <rosuav@gmail.com> - 2015-02-10 17:38 +1100
    Re: __next__ and StopIteration Ethan Furman <ethan@stoneleaf.us> - 2015-02-10 08:44 -0800
    Re: __next__ and StopIteration Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-10 09:53 -0700
    Re: __next__ and StopIteration Ethan Furman <ethan@stoneleaf.us> - 2015-02-10 09:33 -0800

csiph-web