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

[Brett Cannon]

On Sun, Nov 8, 2009 at 13:40, Guido van Rossum <guido at python.org> wrote:
[SNIP]

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

Reflecting upon Guido's comment about compiled languages I have come
around to his view and want to make warnings silent by default. Here
are my reasons.

First, there is the app user perspective. If I use an application I do
not need to see any warnings, ever. Just because my interpreter got
upgraded (whether explicitly by me, my company's sysadmin, or my OS),
that should not suddenly start seeing warnings for some Python-based
application I use. We cannot expect all developers to release a new
version just before or the day of a new interpreter release. This is
what separates interpreted languages from compiled ones; just because
you upgrade your compiler does not mean new warnings will suddenly
show up for the compiled languages.

Now the idea has been floated to solve this by modifying distutils or
any other installers to include the line ``-W ignore`` in the shell
scripts they install. The problem with this is it assumes all users
use the shell script to launch the app. With the introduction of
__main__.py support for packages and zipfiles I can easily see people
starting to launch apps from the command-line with the newest
interpreter they have installed, e.g. ``python2.6 -m someapp``. And
just because I have enough knowledge to know how to specify what
Python interpreter to use does not mean I care about warnings in
Python (might not even know how to program in Python), nor know about
the ``-W ignore`` trick (let alone want to have to type that every
time I use the app).

Second is the perspective of someone not running with the warnings
turned on when they need to for tests. Some have said that there is
the possibility that they won't have the proper test coverage to pick
up the warnings. OK, fine, but that's not our problem. We cannot
dictate proper coding practices (nor should we for that leads down the
road of Java and checked exceptions). Python has always been about
consenting adults. If a development team does not dogfood their own
app with warnings turned on then that is their choice and they will be
bit in the ass at a later date. If a user gets bit by poor development
by a third-party that's unfortunate but once again not our fault since
we cannot dictate that people only use quality software.

In other words I think having warnings off by default is the best way
to improve the situation for users while still empowering developers
to know about things they need to change.

-Brett