[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff (original) (raw)

Brett Cannon brett at python.org
Sat Nov 11 02:34:05 EST 2017

On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, <njs at pobox.com> wrote:

On Nov 8, 2017 16:12, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

On 9 November 2017 at 07:46, Antoine Pitrou <antoine at python.org> wrote: > > Le 08/11/2017 à 22:43, Nick Coghlan a écrit : >> >> However, between them, the following two guidelines should provide >> pretty good deprecation warning coverage for the world's Python code: >> >> 1. If it's in main, it will emit deprecation warnings at runtime >> 2. If it's not in main, it should have a test suite > > Nick, have you actually read the discussion and the complaints people > had with the current situation? Most of them don't specifically talk > about main scripts. I have, and I've also re-read the discussions regarding why the default got changed in the first place. Behaviour up until 2.6 & 3.1: once::DeprecationWarning Behaviour since 2.7 & 3.2: ignore::DeprecationWarning With test runners overriding the default filters to set it back to "once::DeprecationWarning".

Is this intended to be a description of the current state of affairs? Because I've never encountered a test runner that does this... Which runners are you thinking of? The rationale for that change was so that end users of applications that merely happened to be written in Python wouldn't see deprecation warnings when Linux distros (or the end user) updated to a new Python version. It had the downside that you had to remember to opt-in to deprecation warnings in order to see them, which is a problem if you mostly use Python for ad hoc personal scripting. Proposed behaviour for Python 3.7+: once::DeprecationWarning:main ignore::DeprecationWarning With test runners still overriding the default filters to set them back to "once::DeprecationWarning". This is a partial reversion back to the pre-2.7 behaviour, focused specifically on interactive use and ad hoc personal scripting. For ad hoc distributed scripting, the changed default encourages upgrading from single-file scripts to the zipapp model, and then minimising the amount of code that runs directly in main.py. I expect this will be a sufficient change to solve the specific problem I'm personally concerned by, so I'm no longer inclined to argue for anything more complicated. Other folks may have other concerns that this tweak to the default filters doesn't address - they can continue to build their case for more complex options using this as the new baseline behaviour. I think most people's concern is that we've gotten into a state where DeprecationWarning's are largely useless in practice, because no one sees them. Effectively the norm now is that developers (both the Python core team and downstream libraries) think they're following some sensible deprecation cycle, but often they're actually making changes without any warning, just they wait a year to do it. It's not clear why we're bothering through multiple releases -- which adds major overhead -- if in practice we aren't going to actually warn most people. Enabling them for another 1% of code doesn't really address this. As I mentioned above, it's also having the paradoxical effect of making it so that end-users are more likely to see deprecation warnings, since major libraries are giving up on using DeprecationWarning. Most recently it looks like pyca/cryptography is going to switch, partly as a result of this thread: https://github.com/pyca/cryptography/pull/4014 Some more ideas to throw out there: - if an envvar CI=true is set, then by default make deprecation warnings into errors. (This is an informal standard that lots of CI systems use. Error instead of "once" because most people don't look at CI output at all unless there's an error.)

One problem with that is I don't want e.g. mypy to start spewing out warnings while checking my code. That's why I like Victor's idea of a -X option that also flips on other test/debug features. Yes, this would also trigger for test runners, but that's at least a smaller amount of affected code.

-Brett

- provide some mechanism that makes it easy to have a deprecation warning that starts out as invisible, but then becomes visible as you get closer to the switchover point. (E.g. CPython might make the deprecation warnings that it issues be invisible in 3.x.0 and 3.x.1 but become visible in 3.x.2+.) Maybe:

# in warnings.py def deprecationwarning(libraryversion, visibleinversion, changeinversion, msg, stacklevel): ... Then a call like: deprecationwarning(mylibrary.version, "1.3", "1.4", "This function is deprecated", 2) issues an InvisibleDeprecationWarning if mylibrary.version < 1.3, and a VisibleDeprecationWarning otherwise. (The stacklevel argument is mandatory because the usual default of 1 is always wrong for deprecation warnings.) -n

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171111/b79ae663/attachment.html>

More information about the Python-Dev mailing list