On Tue, Apr 23, 2013 at 10:30 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Tue, Apr 23, 2013 at 10:21 AM, Chris Angelico <ros...@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).
To expand on this, the prevailing wisdom here is that calls to next() should always be guarded with a StopIteration exception handler. The one exception to this is when the next() call is inside the body of a generator function, and the exception handler would cause the generator to exit anyway; in that case there is little difference between "except StopIteration: return" and letting the StopIteration propagate to the generator object. -- http://mail.python.org/mailman/listinfo/python-list
