On Sun, Nov 5, 2017 at 9:38 PM, Nick Coghlan <ncogh...@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 _______________________________________________ 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
