[Python-Dev] PEP 479: Change StopIteration handling inside generators
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 proposal unifies the behavior of list comprehensions and generator expressions along the lines I had originally in mind when they were introduced. It renders useless/illegal certain hacks that have crept into some folks' arsenal of obfuscated Python tools. In Python 3.5 the proposed change is conditional on: from __future__ import replace_stopiteration_in_generators This would affect all generators (including generator expressions) compiled under its influence. The feature would become standard in Python 3.6 or 3.7. The PEP is here: https://www.python.org/dev/peps/pep-0479/ To avoid a lot of requests for clarification you may also want to read up on the python-ideas discussion, e.g. here: https://groups.google.com/forum/#!topic/python-ideas/yJi1gRot9yY I am leaning towards approving this PEP, but not until we've had a review here at python-dev. I would like to thank Chris Angelico for writing the original PEP draft. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators
On Wed, Nov 19, 2014, at 15: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 proposal unifies the behavior of list comprehensions and generator > expressions along the lines I had originally in mind when they were > introduced. It renders useless/illegal certain hacks that have crept into > some folks' arsenal of obfuscated Python tools. > > In Python 3.5 the proposed change is conditional on: > > from __future__ import replace_stopiteration_in_generators Drive-by comment: This seems like a terribly awkward name. Could a shorter and sweeter name not be found? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators
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)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators
On Thu, Nov 20, 2014 at 7:48 AM, MRAB wrote:
> 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 point here is primarily about some other function (maybe a
next(iter), or maybe something else entirely) raising StopIteration.
(If it explicitly raises StopIteration right there in the generator,
it can be trivially converted into a return statement, anyway.) The
return statement is an explicit indication that the generator should
now return; permitting a StopIteration to bubble up through and out is
the implicit option; but the 'plicitness' isn't necessarily obvious.
ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] PEP 479: Change StopIteration handling inside generators
On Thu, Nov 20, 2014 at 3:45 AM, Nick Coghlan wrote:
> The part I found most compelling was when you pointed out that in the
> special method implementations, the normal return path was always spelled
> with "return", while the "value missing" result was indicated with a special
> kind of exception (StopIteration, AttributeError, IndexError or KeyError),
> and then any other exception was consider unexpected.
>
> Generators add the third notion of being able to suspend execution via
> "yield", which then left them with two different ways of spelling
> termination inside the frame: "return" OR "raise StopIteration". The second
> spelling ("raise StopIteration") is then inherently surprising, as it's
> entirely redundant, *except* in that it allows you to effectively have a
> "hidden return" in a generator frame that can't be done anywhere else.
(The above was said on -ideas, but discussion is now moving to -dev,
so I hope it's okay to send the response there.)
Added a paragraph to the PEP draft:
https://github.com/Rosuav/GenStopIter/commit/695961
Should today's date be added to the Post-History?
ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
