[Python-Dev] Proposal: go back to enabling DeprecationWarning by default (original) (raw)

Nathaniel Smith njs at pobox.com
Mon Nov 6 03:25:11 EST 2017

On Sun, Nov 5, 2017 at 9:38 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

We've been running the current experiment for 7 years, and the main observable outcome has been folks getting surprised by breaking changes in CPython releases, especially folks that primarily use Python interactively (e.g. for data analysis), or as a scripting engine (e.g. for systems administration).

It's also caused lots of projects to switch to using their own ad hoc warning types for deprecations, e.g. off the top of my head:

https://github.com/matplotlib/matplotlib/blob/6c51037864f9a4ca816b68ede78207f7ecec656c/lib/matplotlib/cbook/deprecation.py#L5 https://github.com/numpy/numpy/blob/d75b86c0c49f7eb3ec60564c2e23b3ff237082a2/numpy/_globals.py#L45 https://github.com/python-trio/trio/blob/f50aa8e00c29c7f2953b7bad38afc620772dca74/trio/_deprecate.py#L16

So in some ways the change has actually made it harder for end-user applications/scripts to hide all deprecation warnings, because for each package you use you have to somehow figure out which idiosyncratic type it uses, and filter them each separately.

(In any changes though please do keep in mind that Python itself is not the only one issuing deprecation warnings. I'm thinking in particular of the filter-based-on-Python-version idea. Maybe you could have subclasses like Py35DeprecationWarning and filter on those?)

-n

-- Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list