Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #44217
| References | <kl6a1f$k2l$1@panix2.panix.com> <CAPTjJmpKR8z7Cub1WaurmsuugNgCvPYFdh9WYqJd_1OTfpLw6Q@mail.gmail.com> <CALwzidk6qz4qHOFWYqv_cDEtjbhvS_kjG0vXJZmeB0dJ07doTQ@mail.gmail.com> |
|---|---|
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
| Date | 2013-04-23 22:29 +0100 |
| Subject | Re: Nested iteration? |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.996.1366752575.3114.python-list@python.org> (permalink) |
On 23 April 2013 17:30, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Tue, Apr 23, 2013 at 10:21 AM, Chris Angelico <rosuav@gmail.com> wrote: >> The definition of the for loop is sufficiently simple that this is >> safe, with the caveat already mentioned (that __iter__ is just >> returning self). And calling next() inside the loop will simply >> terminate the loop if there's nothing there, so I'd not have a problem >> with code like that - for instance, if I wanted to iterate over pairs >> of lines, I'd happily do this: >> >> for line1 in f: >> line2=next(f) >> print(line2) >> print(line1) >> >> That'll happily swap pairs, ignoring any stray line at the end of the >> file. Why bother catching StopIteration just to break? > > The next() there will *not* "simply terminate the loop" if it raises a > StopIteration; for loops do not catch StopIteration exceptions that > are raised from the body of the loop. The StopIteration will continue > to propagate until it is caught or it reaches the sys.excepthook. In > unusual circumstances, it is even possible that it could cause some > *other* loop higher in the stack to break (i.e. if the current code is > being run as a result of the next() method being called by the looping > construct). I don't find that the circumstances are unusual. Pretty much any time one of the functions in the call stack is a generator this problem will occur if StopIteration propagates. I just thought I'd add that Python 3 has a convenient way to avoid this problem with next() which is to use the starred unpacking syntax: >>> numbers = [1, 2, 3, 4] >>> first, *numbers = numbers >>> first 1 >>> for x in numbers: ... print(x) ... 2 3 4 >>> first, *numbers = [] Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: need more than 0 values to unpack Since we get a ValueError instead of a StopIteration we don't have the described problem. Oscar
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Nested iteration? roy@panix.com (Roy Smith) - 2013-04-23 11:40 -0400
Re: Nested iteration? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-04-23 17:05 +0100
Re: Nested iteration? Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-23 10:05 -0600
Re: Nested iteration? Peter Otten <__peter__@web.de> - 2013-04-23 18:15 +0200
Re: Nested iteration? Chris Angelico <rosuav@gmail.com> - 2013-04-24 02:21 +1000
Re: Nested iteration? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-23 16:35 +0000
Re: Nested iteration? Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-23 10:30 -0600
Re: Nested iteration? Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-23 10:39 -0600
Re: Nested iteration? Chris Angelico <rosuav@gmail.com> - 2013-04-24 02:42 +1000
Re: Nested iteration? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-23 16:53 +0000
Re: Nested iteration? Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-23 16:49 -0400
Re: Nested iteration? Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-23 22:14 +0100
Re: Nested iteration? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-04-23 22:29 +0100
Re: Nested iteration? Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-23 22:41 +0100
Re: Nested iteration? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-04-23 23:42 +0100
csiph-web