[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Nick Coghlan]

On 6 November 2017 at 21:58, Antoine Pitrou <solipsis at pitrou.net> wrote:
> I guess my takeaway point is that many situations are complicated, and
> many third-party library developers are much less disciplined than what
> some of us would idealistically expect them to be (those developers
> probably often have good reasons for that).  For someone who takes care
> to only use selected third-party libraries of high maintenance quality,
> I'm very +1 on your proposal.  For the more murky (but rather common)
> cases of relying on average quality third-party libraries, I'm +0.

Agreed, and I'm thinking there could be a lot of value in the variant
of the idea that says:

- tweak the default warning filters to turn DeprecationWarning back on
for __main__ only
- add a new warnings module API specifically for managing deprecation warnings

The first change would restore DeprecationWarning-by-default for:

- ad hoc single file scripts (potentially including Jupyter notebooks,
depending on which execution namespace kernels use)
- ad hoc experimentation at the REPL
- working through outdated examples at the REPL

For installed applications using setuptools (or similar), "__main__"
is the script wrapper, not any of the application code, and those have
been getting more minimal over time (and when they do have non-trivial
code in them, it's calling into setuptools/pkg_resources rather than
the standard library).

The second change would be designed around making it easier for app
developers to say "Always emit DeprecationWarnings for my own code,
don't worry about anything else".

With DeprecationWarning still off by default, that might look like:

    warnings.reportdeprecations("myproject")

Cheers,
Nick.

P.S. For those interested, the issue where we switched to the current
behaviour is https://bugs.python.org/issue7319

And the related stdlib-sig thread is
https://mail.python.org/pipermail/stdlib-sig/2009-November/000789.html

That was apparently in the long gone era when I still read every
python-checkins message, so there's also a very short thread on
python-dev after it landed in SVN:
https://mail.python.org/pipermail/python-dev/2010-January/097178.html

The primary argument for the change in the stlib-sig thread is
definitely "App devs don't hide deprecation warnings, and then their
users complain about seeing them". Guido even goes so far to describe
app developers using the warnings filter interface as designed to
manage what they emit on stderr as "a special hack".

Later in the thread Georg Brandl brought up a fairly compelling
argument that Guido was right about that, which is that programmatic
filters to manage warnings currently don't compose well with the
command line and environment variable settings, since there's only one
list of warning filters, which means there's no way to say "put this
*before* the default filters, but *after* any filters that were
specified explicitly with -W or PYTHONWARNINGS". Instead, your options
are limited to prepending (the default behaviour) which overrides both
the defaults and any specific settings, or appending, which means you
can't even override the defaults.

When DeprecationWarnings were enabled by default, this meant there was
no native way to override application level filters that ignored them
in order to turn on DeprecationWarnings when running your test suite.

By contrast, having them be off by default with runtime programmatic
filter manipulation being rare offers a simple way to turn them on
globally, via "-Wd". Adding "-W once::DeprecationWarning:__main__" to
the default filter list doesn't change that substantially.

That said, this does make me wonder whether the warnings module should
either place a sentinel marker in its warning filter list to mark
where the default filters start (and adjust the append mode to insert
filters there), or else provide a new option for programmatic
configuration that's "higher priority than the defaults, lower
priority than the explicit configuration settings".

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia