On 6 November 2017 at 21:58, Antoine Pitrou <solip...@pitrou.net> wrote: > I guess my takeaway point is that many situations are complicated, and > many third-party library developers are much less disciplined than what > some of us would idealistically expect them to be (those developers > probably often have good reasons for that). For someone who takes care > to only use selected third-party libraries of high maintenance quality, > I'm very +1 on your proposal. For the more murky (but rather common) > cases of relying on average quality third-party libraries, I'm +0.
Agreed, and I'm thinking there could be a lot of value in the variant of the idea that says: - tweak the default warning filters to turn DeprecationWarning back on for __main__ only - add a new warnings module API specifically for managing deprecation warnings The first change would restore DeprecationWarning-by-default for: - ad hoc single file scripts (potentially including Jupyter notebooks, depending on which execution namespace kernels use) - ad hoc experimentation at the REPL - working through outdated examples at the REPL For installed applications using setuptools (or similar), "__main__" is the script wrapper, not any of the application code, and those have been getting more minimal over time (and when they do have non-trivial code in them, it's calling into setuptools/pkg_resources rather than the standard library). The second change would be designed around making it easier for app developers to say "Always emit DeprecationWarnings for my own code, don't worry about anything else". With DeprecationWarning still off by default, that might look like: warnings.reportdeprecations("myproject") Cheers, Nick. P.S. For those interested, the issue where we switched to the current behaviour is https://bugs.python.org/issue7319 And the related stdlib-sig thread is https://mail.python.org/pipermail/stdlib-sig/2009-November/000789.html That was apparently in the long gone era when I still read every python-checkins message, so there's also a very short thread on python-dev after it landed in SVN: https://mail.python.org/pipermail/python-dev/2010-January/097178.html The primary argument for the change in the stlib-sig thread is definitely "App devs don't hide deprecation warnings, and then their users complain about seeing them". Guido even goes so far to describe app developers using the warnings filter interface as designed to manage what they emit on stderr as "a special hack". Later in the thread Georg Brandl brought up a fairly compelling argument that Guido was right about that, which is that programmatic filters to manage warnings currently don't compose well with the command line and environment variable settings, since there's only one list of warning filters, which means there's no way to say "put this *before* the default filters, but *after* any filters that were specified explicitly with -W or PYTHONWARNINGS". Instead, your options are limited to prepending (the default behaviour) which overrides both the defaults and any specific settings, or appending, which means you can't even override the defaults. When DeprecationWarnings were enabled by default, this meant there was no native way to override application level filters that ignored them in order to turn on DeprecationWarnings when running your test suite. By contrast, having them be off by default with runtime programmatic filter manipulation being rare offers a simple way to turn them on globally, via "-Wd". Adding "-W once::DeprecationWarning:__main__" to the default filter list doesn't change that substantially. That said, this does make me wonder whether the warnings module should either place a sentinel marker in its warning filter list to mark where the default filters start (and adjust the append mode to insert filters there), or else provide a new option for programmatic configuration that's "higher priority than the defaults, lower priority than the explicit configuration settings". -- 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/archive%40mail-archive.com