Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CALwzidk6qz4qHOFWYqv_cDEtjbhvS_kjG0vXJZmeB0dJ07doTQ@mail.gmail.com>
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: Tue, 23 Apr 2013 22:29:07 +0100
Subject: Re: Nested iteration?
To: Ian Kelly <ian.g.kelly@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Python <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.996.1366752575.3114.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:44217

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