On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <ischwabac...@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)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
