[Python-Dev] Please reconsider PEP 479.

Guido van Rossum guido at python.org
Mon Nov 24 19:19:05 CET 2014


On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <ischwabacher at wisc.edu>
wrote:

> On 11/23/14, Guido van Rossum  wrote:
>
> > It wouldn't be so bad if we had the occasional generator author writing
> "raise StopIteration" instead of "return" to exit from a generator. (We
> could just add a recommendation against this to the style guide.) But the
> problem is that an unguarded next() call also raises StopIteration.
> Sometimes this is intentional (as in some itertools examples). But
> sometimes an unguarded next() call occurs deep in the bowels of some code
> called by the generator, and this situation is often hard to debug, since
> there is no stack track.
>
> I'll admit I've only skimmed the massive volume of correspondence this PEP
> has generated, but it seems to me that this is the main argument for this
> change. I can only assume that your support for this PEP is informed by
> your experience building Tulip, but isn't this the kind of thing that can
> be accomplished with a warning? Then you can get the same behavior without
> even needing a __future__ import to protect code bases that expect
> StopIteration to propagate (which seems like the more elegant and natural
> thing to do, even if it is more error-prone).
>

Yes, this is my main reason for wanting the change -- but not just for
tulip/asyncio. The issue can be just as baffling for anyone using
unprotected next() calls in the context of a generator. But I'm not sure
where to put the warning. Are you proposing to issue a warning under the
same conditions the PEP says? But then the itertools examples would issue
warnings -- and I bet the advice would typically be "disable warnings"
rather than "fix the code, otherwise it will break hard in Python 3.7".

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141124/43a0bd83/attachment.html>


More information about the Python-Dev mailing list