[Python-Dev] PEP 479: Change StopIteration handling inside generators

[Terry Reedy]

On 11/20/2014 2:36 PM, Guido van Rossum wrote:

> 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

For StackOverflow, someone with a high-enough rep (you, Guido?) should 
add a tag for StopIteration with text like "The Python `StopIteration` 
exception."  (Copied from the current AttributeError tag, typeerror and 
NameError also exist.).  If and when the PEP is accepted, I would be 
willing to add comments and the new tag to existing and future 
questions/answers.

> - with Python 3.5, introduce "from __future__ import generator_return",
> and silent deprecation warnings
> - with Python 3.6, start issuing non-silent deprecation warnings

I agree that two deprecation periods are needed.

> - 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.

Agree that explicit fixes are needed.  Deprecation message could refer 
to section of PEP.

> 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?

-- 
Terry Jan Reedy