[Python-Dev] Proposal: go back to enabling DeprecationWarning by default (original) (raw)

Philipp A. flying-sheep at web.de
Mon Nov 6 09:51:43 EST 2017

Hi! Just this minute I ran across a case where I’d want DeprecationWarnings on by default

(We want to rename a property in an API I’m co-developing. I has mainly scientists as target audience, so end users, not developers)

Gustavo Carneiro <gjcarneiro at gmail.com> schrieb am Mo., 6. Nov. 2017 um 15:19 Uhr:

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

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/flying-sheep%40web.de -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171106/eb692fc2/attachment.html>

More information about the Python-Dev mailing list