[Python-Dev] Please reconsider PEP 479.

[Guido van Rossum]

On Mon, Nov 24, 2014 at 3:07 PM, Isaac Schwabacher <ischwabacher at wisc.edu>
wrote:

> On 11/24/14, Guido van Rossum  wrote:
> > On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher <
> ischwabacher at wisc.edu <ischwabacher at wisc.edu')" target="1">
> ischwabacher at wisc.edu> wrote:
> >
> > > On 11/24/14, Guido van Rossum wrote:
> > > > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <
> python.org/~guido(javascript:main.compose('new', 't=ischwabacher at wisc.edu>(java_script: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! :-)
>
> I agree with you that escaping StopIteration should be easier to notice,
> but with the opposition that allowing StopIteration to escape on purpose is
> a useful technique. But when you put it that way...
>
> > > > 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 take it all back. ;D Nothing I've run across in the python ecosystem has
> made this point to me. (And google searches for "python warning philosophy"
> and the like don't find it, either.) I was interpreting the warning as
> indicating that there *might* be a problem in user code, so if the user
> knows why the system believes this and knows that the problem is a mirage,
> then it is reasonable to silence the warning indefinitely. In this
> interpretation it would make sense to simply add the warning and rely on
> users to determine whether their escaping StopIterations were intentional
> or not, without ever changing the default handling of the warning to
> "raise". But if warnings should never be silenced indefinitely, then this
> is a silly thing to do.
>
> > > 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.
>
> And this fact makes so much more sense in context.
>

In my defense, the docs for the warnings module on docs.python.org at start
like this:

"Warning messages are typically issued in situations where it is useful to
alert the user of some condition in a program, where that condition
(normally) doesn’t warrant raising an exception and terminating the
program. For example, one might want to issue a warning when a program uses
an obsolete module."

I admit that's only a single example, but it does refer to something that
will break in the future.

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