[stdlib-sig] standardizing the deprecation policy (and how noisy they are)
brett at python.org
Mon Nov 9 03:05:51 CET 2009
On Sun, Nov 8, 2009 at 13:40, Guido van Rossum <guido at python.org> wrote:
> On Sun, Nov 8, 2009 at 1:26 PM, Brett Cannon <brett at python.org> wrote:
>> During the moratorium PEP discussions Guido said he wanted to quiet
>> down deprecation warnings. I see there being two options on this.
>> One is to keep things as is, but to require two releases with
>> PendingDeprecationWarning so there are three years of
>> silent-by-default warnings to update your code. But that last release
>> before removal came would still be noisy.
>> The other option is to simply have all warnings filtered out by
>> default. We could alter -W so that when it is used w/o an argument it
>> turns to what is currently the default behaviour (or even turn all
>> warnings which is more than what happens now). This will require that
>> people proactively check for warnings when updating for compatibility,
>> else they will eventually use a Python release where there code will
>> simply break because something changed. This route means we do not
>> have to specify any deprecation policy right now (that would be a
>> separate discussion).
>> Channeling Guido he is after the latter, but a general discussion
>> would still be good since he didn't explicitly say what he was after
>> other than to quiet down warnings.
> I was specifically after all kinds of deprecation warnings, which
> generally are telling you that you need to make a change in order to
> remain compatible in the future. That's sometimes interesting but
> often irrelevant noise. So I would agree with Gregory P Smith's
> proposal to just treat all deprecation warnings as silent.
> There are other kinds warnings which might be useful for other reasons
> -- they typically point out code that does not do what you might think
> it does. A good example is the warning added in 2.6 about "assert (x,
> y)". This is something you ignore at your peril.
> On Sun, Nov 8, 2009 at 1:35 PM, Michael Foord <michael at voidspace.org.uk> wrote:
>> Almost no-one is ever going to run Python with PendingDeprecation
>> warnings switched on, so there should be at least one 'noisy' release in
>> my opinion.
> I disagree. The -3 option is an example of a better approach: silent
> by default, warnings enabled by a command line flag. If we can trust
> developers to use -3 to check for Py3k incompatibilities, we should
> also be able to trust them to check for deprecation warnings
There is also the argument that if people are told they have to
explicitly turn on warnings to get them and the switch turns them all
on then it might be the case that more people will see and deal with
PendingDeprecationWarnings than they do now. The arguments that people
will not switch them on is based on current practice. Guido's and
Greg's argument is that habits will change such that it is not going
to be an issue.
What does this mean for the warning filter? It will obviously tone
down its need, but would it be needed at all? If warnings are off by
default the need to actively filter them out goes down by a lot. And
you probably don't want to accidentally filter out a warning if you
have to explicitly turn them on. I would argue that if you have to
explicitly turn filters on then you don't have much of a need to
selectively silence them and thus the filter can just go away.
> (Another argument to think about: if you download and install some 3rd
> party code, deprecation warnings about that code are *only noise*
> since they are not yours to fix. Warnings in a dynamic language work
> very different than warnings in a compiled language.)
That's very true. Until Mercurial caught up to Python 2.6 the sha/md5
warnings were very annoying. I actually modified my copy to turn them
More information about the stdlib-sig