(original) (raw)

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@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@gmail.com | Brisbane, Australia
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com