On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher <ischwabacher@wisc.edu> wrote:

On 11/24/14, Guido van Rossum wrote:
> On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <ischwabacher@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.

So you agree with the problem that the PEP is trying to solve, you want people to fix their code in exactly the same way that the PEP is trying to get them to fix it, you want all new code that exhibits the problem to be flagged by a warning, and yet you do not support adding a __future__ statement and a a transition plan that replaces the warnings with hard failures in Python 3.7 (whose release date is going to be at least about four years in the future)?

That sounds like the most loyal opposition I can wish for! :-)

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

Python's philosophy for (runtime) warnings is pretty clear -- a warning should never be silenced indefinitely. Warnings mean something's wrong with your code that won't get better by ignoring it, and you should fix it at some point. Until then you can silence the warning. Silencing warnings is an important mechanism for users who have no control over the code that issues the warning, and for devs who have more pressing priorities. But they should not be used to permanently enable coding in an "alternate universe" where the language has different features.

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.

You can get pretty darn specific with the warnings silencing machinery: up to the module and line number. It's intentional that you can't specify a class/method -- the latter would just encourage devs to silence a specific warning because they think they know better.

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