(original) (raw)

I've made some updates to the PEP:

- added 19-Nov-2014 to Post-History

- removed "implicitly-raised" from the abstract

- changed the \_\_future\_\_ thing to generator\_return

- added a clarifying paragraph that Chris added to his own draft

- added a link to http://bugs.python.org/issue22906 which has a proof-of-concept patch

There's still a lively discussion on python-ideas; Steven D'Aprano has dug up quite a bit of evidence that StopIteration is used quite a bit in ways that will break under the new behavior, and there also seems to be quite a bit of third-party information that recommends StopIteration over return to terminate a generator early.

However I don't see much evidence that the current behavior is \*better\* than the proposal -- I see the current behavior as a definite wart, and I have definitely seen people struggle to debug silent early loop termination due to an "escaped" StopIteration.

That said, I think for most people the change won't matter, some people will have to apply one of a few simple fixes, and a rare few will have to rewrite their code in a non-trivial way (sometimes this will affect "clever" libraries).

I wonder if the PEP needs a better transition plan, e.g.

- right now, start an education campaign

- with Python 3.5, introduce "from \_\_future\_\_ import generator\_return", and silent deprecation warnings

- with Python 3.6, start issuing non-silent deprecation warnings

- with Python 3.7, make the new behavior the default (subject to some kind of review)

It would also be useful if we could extend the PEP with some examples of the various categories of fixes that can be applied easily, e.g. a few examples of "raise StopIteration" directly in a generator that can be replaced with "return" (or omitted, if it's at the end); a few examples of situations where "yield from" can supply an elegant fix (and an alternative for code that needs to be backward compatible with Python 3.2 or 2.7); and finally (to be honest) an example of code that will require being made more complicated.

Oh, and it would also be nice if the PEP included some suggested words that 3rd party educators can use to explain the relationship between StopIteration and generators in a healthier way (preferably a way that also applies to older versions).

Chris, are you up to drafting these additions?

On Thu, Nov 20, 2014 at 2:05 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 20 November 2014 06:15, Benjamin Peterson <benjamin@python.org> wrote:

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?

I think my suggestion was something like "from \_\_future\_\_ import generator\_return".

I saw that style as somewhat similar to "from \_\_future\_\_ import division" - it just tells you what the change affects (in this case, returning from generators), while requiring folks to look up the documentation to find out the exact details of the old behaviour and the new behaviour.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

--Guido van Rossum (python.org/\~guido)