[stdlib-sig] standardizing the deprecation policy (and how noisy they are)

[Guido van Rossum]

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

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

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