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

[Antoine Pitrou]

> First, there is the app user perspective. If I use an application I do
> not need to see any warnings, ever.

But most end users don't launch their applications via the command-line,
so they won't get to see any stderr warnings anyway.
(have you ever launched a Gnome or KDE app from the command-line? they
can spout *tons* of warnings)

> We cannot expect all developers to release a new
> version just before or the day of a new interpreter release.

And that's precisely why deprecation warnings are necessary to warn them
beforehand. If you silence deprecation warnings by default,
developers /will/ end up in situations where they have to do an
emergency release to support the latest Python interpreter.

(OTOH, noisy deprecation warnings, however annoying they may be to you,
don't force developers to do an emergency release in order to fix them;
they allow developers to take their time)

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

Uh? These would be pretty advanced users. The "-m" option is certainly
not known let alone used by the average non-Python savvy user.
And, of course, the Python savvy user is perfectly able to report a bug
to the application developer.

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

This sounds really sophistic. If you know about "-m", you know to type
"python --help" which immediately will give you the list of available
options, including a possible "-W ignore", "-w" or whatever is added to
that purpose.

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

How condescending is that?
Even /we/ are far from 100% test coverage.

> Python has always been about
> consenting adults.

Being consenting adults, however, does not mean giving people a gun to
shoot themselves in the foot, or removing any useful feature which might
let them know that their code should be fixed. We may not be Java, but
neither are we C++ or C.

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

Brett, Python is a rich and diverse ecosystem. We as core developers may
live in an ideal world where perfect development practices are followed
(and even that is a lie, since we don't have 100% test coverage, some of
our tests are flaky and our buildbots are often red), but our software
is used in many situations, including by people (scientists, teachers,
system administrators, webmasters) who are not professional Python
programmers.

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

Actually, it doesn't make the situation significantly better for users,
or even for developers, it just satisfies our own little egoistical
comfort as power users who don't like the annoying sight of warnings in
a terminal.

I think this proposal is totally counter-productive, and counter to the
idea that Python caters for diverse categories of developers.