<div dir="ltr">Big +1 to turning warnings on by default again.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Showing warnings by default is good:</div><div> 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;</div><div> 2. The users that do see them are sufficiently proficient to be able to submit a bug report;</div><div> 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;</div><div> 4. Given time, all the bug reports trickle down and create pressure on module maintainers to fix warnings;</div><div> 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.</div><div><br></div><div>Not fixing warnings is a form of technical debt that we should not encourage.  It is not the Python way.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 6 November 2017 at 02:05, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On the 12-weeks-to-3.7-feature-freeze thread, Jose Bueno & I both<br>
mistakenly though the async/await deprecation warnings were missing<br>
from 3.6.<br>
<br>
They weren't missing, we'd just both forgotten those warnings were off<br>
by default (7 years after the change to the default settings in 2.7 &<br>
3.2).<br>
<br>
So my proposal is simple (and not really new): let's revert back to<br>
the way things were in 2.6 and earlier, with DeprecationWarning being<br>
visible by default, and app devs having to silence it explicitly<br>
during application startup (before they start importing third party<br>
modules) if they don't want their users seeing it when running on the<br>
latest Python version (e.g. this would be suitable for open source<br>
apps that get integrated into Linux distros and use the system Python<br>
there).<br>
<br>
This will also restore the previously clear semantic and behavioural<br>
different between PendingDeprecationWarning (hidden by default) and<br>
DeprecationWarning (visible by default).<br>
<br>
As part of this though, I'd suggest amending the documentation for<br>
DeprecationWarning [1] to specifically cover how to turn it off<br>
programmatically (`warnings.simplefilter("<wbr>ignore",<br>
DeprecationWarning)`), at the command line (`python -W<br>
ignore::DeprecationWarning ...`), and via the environment<br>
(`PYTHONWARNINGS=ignore::<wbr>DeprecationWarning`).<br>
<br>
(Structurally, I'd probably put that at the end of the warnings<br>
listing as a short introduction to warnings management, with links out<br>
to the relevant sections of the documentation, and just use<br>
DeprecationWarning as the specific example)<br>
<br>
Cheers,<br>
Nick.<br>
<br>
[1] <a href="https://docs.python.org/3/library/exceptions.html#DeprecationWarning" rel="noreferrer" target="_blank">https://docs.python.org/3/<wbr>library/exceptions.html#<wbr>DeprecationWarning</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>gjcarneiro%40gmail.com</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Gustavo J. A. M. Carneiro<div>Gambit Research<br>"The universe is always one step beyond logic." -- Frank Herbert</div></div></div>
</div>