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 <gjcarne...@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 <ncogh...@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 | ncogh...@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
>>
>
>
>
> --
> Gustavo J. A. M. Carneiro
> Gambit Research
> "The universe is always one step beyond logic." -- Frank Herbert
> _______________________________________________
> 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/flying-sheep%40web.de
>
_______________________________________________
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/archive%40mail-archive.com
