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

[Gustavo Carneiro]

Big +1 to turning warnings on by default again.

When this behaviour first started, first I was surprised, then annoyed that
warnings were being suppressed.  For a few years I learned to have `export
PYTHONWARNINGS=default` in my .bashrc.

But eventually, the warnings in 3rd-party Python modules gradually
increased because, since warnings are disabled by default, authors of
command-line tools, or even python modules,  don't even realise they are
triggering the warning.

So developers stop fixing warnings because they are hidden.  Things get
worse and worse over the years.  Eventually I got fed up and removed the
PYTHONWARNINGS env var.

Showing warnings by default is good:
 1. End users who don't understand what those warnings are are unlikely to
see them since they don't command-line tools at all;
 2. The users that do see them are sufficiently proficient to be able to
submit a bug report;
 3. If you file a bug report in tool that uses a 3rd party module, the
author of that tool should open a corresponding bug report on the 3rd party
module that actually caused the warning;
 4. Given time, all the bug reports trickle down and create pressure on
module maintainers to fix warnings;
 5. If a module is being used and has no maintainer, it's a good indication
it is time to fork it or find an alternative.

Not fixing warnings is a form of technical debt that we should not
encourage.  It is not the Python way.


On 6 November 2017 at 02:05, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both
> mistakenly though the async/await deprecation warnings were missing
> from 3.6.
>
> They weren't missing, we'd just both forgotten those warnings were off
> by default (7 years after the change to the default settings in 2.7 &
> 3.2).
>
> So my proposal is simple (and not really new): let's revert back to
> the way things were in 2.6 and earlier, with DeprecationWarning being
> visible by default, and app devs having to silence it explicitly
> during application startup (before they start importing third party
> modules) if they don't want their users seeing it when running on the
> latest Python version (e.g. this would be suitable for open source
> apps that get integrated into Linux distros and use the system Python
> there).
>
> This will also restore the previously clear semantic and behavioural
> different between PendingDeprecationWarning (hidden by default) and
> DeprecationWarning (visible by default).
>
> As part of this though, I'd suggest amending the documentation for
> DeprecationWarning [1] to specifically cover how to turn it off
> programmatically (`warnings.simplefilter("ignore",
> DeprecationWarning)`), at the command line (`python -W
> ignore::DeprecationWarning ...`), and via the environment
> (`PYTHONWARNINGS=ignore::DeprecationWarning`).
>
> (Structurally, I'd probably put that at the end of the warnings
> listing as a short introduction to warnings management, with links out
> to the relevant sections of the documentation, and just use
> DeprecationWarning as the specific example)
>
> Cheers,
> Nick.
>
> [1] https://docs.python.org/3/library/exceptions.html#DeprecationWarning
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> gjcarneiro%40gmail.com
>



-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171106/831c5cfd/attachment.html>