[Python-Dev] PEP 479: Change StopIteration handling inside generators (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Nov 20 10:35:32 CET 2014

On 20 November 2014 06:48, MRAB <python at mrabarnett.plus.com> wrote:

On 2014-11-19 20:10, Guido van Rossum wrote:

There's a new PEP proposing to change how to treat StopIteration bubbling up out of a generator frame (not caused by a return from the frame). The proposal is to replace such a StopIteration with a RuntimeError (chained to the original StopIteration), so that only returning from a generator (or falling off the end) causes the iteration to terminate.

The PEP says """any generator that depends on an implicitly-raised StopIteration to terminate it will have to be rewritten to either catch that exception or use a for-loop""" Shouldn't that be "... explicitly-raised ...", because returning raises StopIteration implicitly? ("raise StopIteration" is explicit)

The ways a generator can currently be terminated:

return [value]
raise StopIteration[([value])]
<any other expression that may raise StopIteration>

The first case is unchanged, and (as Chris noted), the second case can be trivially converted to the first case.

It's the third implicit case which would no longer be allowed, which means no more "or stop()" tricks to get generator expressions to terminate early. (If folks wanted to restore that capability, they'd instead need to propose new syntax that works the same way in both comprehensions and generator expressions, rather than relying on the lazy evaluation of generator expressions)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20141120/40bda597/attachment.html>

More information about the Python-Dev mailing list