Antoine Pitrou <pit...@free.fr> added the comment: > * Recommend that test runners also set this in the environment (so it's > inherited by subprocesses), not just in the current process
+1 > * 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) +1 > * 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) +1 > * Explicitly recommend FutureWarning as the "always visible by default" > alternative to DeprecationWarning That's rather weird. It seems more and more library authors are discontent with DeprecationWarning's default behaviour. Why not change DeprecationWarning's behaviour to match expectations instead of starting recommending people switch to something less obvious? > 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 I think the main reason is that our assumptions weren't clear at all. The people who promoted this change didn't envision the issues that would come with it. ---------- _______________________________________ 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