Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #85429
| 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) |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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