Nick Coghlan <ncogh...@gmail.com> added the comment:

OK, I've had a couple of days to become not-annoyed about this, and given the 
discovery that pytest doesn't currently enable DeprecationWarning by default 
(even though the default DeprecationWarning behaviour changed more than 7 years 
ago), I'm now prepared to write a short PEP explicitly defining our updated 
expectations around how deprecation warnings will be handled:

* Change the default warning filters so that DeprecationWarning is once again 
visible by default for code in __main__
* Clearly document the assumption that anything factored out into a support 
library will have a test suite. If developers choose not to do that, then 
they're on their own when it comes to deprecation warnings for the APIs they 
use, just as they're on their own in relation to maintaining the compatibility 
of their own APIs.
* Clearly document the assumption that test runners will override the 
interpreter's suitable-for-end-user-application defaults with defaults that are 
more appropriate for testing use cases
* Recommend that test runners also set this in the environment (so it's 
inherited by subprocesses), not just in the current process
* Clearly document "-We", "-Wi", "-Wd" as shorthands to override the default 
warnings filters with universal "error", "ignore" and "default" settings (right 
now you have to reverse engineer this from the warnings docs)
* Clearly document "PYTHONWARNINGS=error", "PYTHONWARNINGS=ignore", and 
"PYTHONWARNINGS=default" as the environmental equivalents (right now you have 
to reverse engineer this from the warnings docs)
* Explicitly recommend FutureWarning as the "always visible by default" 
alternative to DeprecationWarning
* Explicitly recommend PendingDeprecationWarning as the "never visible by 
default" alternative to DeprecationWarning

I suspect if we'd been clearer about our assumptions back when the change was 
made and advertised in the Python 2.7 What's New, we'd have had fewer problems 
in the time since (e.g. third party test runner developers would have been more 
likely to realise that we meant for them to make the same change that we made 
to unittest's defaults - re-reading 
https://docs.python.org/3/whatsnew/2.7.html#changes-to-the-handling-of-deprecation-warnings
 now, I'm no longer surprised they didn't catch that implication)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31975>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to