On 11/24/14, Guido van Rossum wrote: > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher > <ischwabac...@wisc.edu(javascript:main.compose()> 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?
Yes, I'm proposing issuing the warning at the point where the PEP raises, so that the PEP's behavior can be obtained with a warning filter (and such a filter could be installed by default around the asyncio main loop). > But then the itertools examples would issue warnings -- That's definitely problematic. They should either be fixed, or have the warning silenced with a comment about how the bubbling-up case is expected. > and I bet the advice would typically be "disable warnings" rather than "fix > the code, otherwise it will break hard in Python 3.7". I don't think it's the language's responsibility to second guess a user who decides to explicitly silence such a warning. And if this *is* accomplished with a warning, then the user can just continue silencing it in 3.7. In my experience, though, python's documentation, StackOverflow presence, blogs, etc. have been absolutely stellar in terms of explaining why things are the way they are and how one should write pythonic code. I don't doubt the community's ability to educate users on this. I think the biggest stumbling block for this proposal is the fact that the current warning machinery doesn't appear to be up to the task of silencing a known-harmless warning in one generator without silencing meaningful warnings in generators it calls. ijs _______________________________________________ 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
