On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, <n...@pobox.com> wrote: > On Nov 8, 2017 16:12, "Nick Coghlan" <ncogh...@gmail.com> wrote: > > On 9 November 2017 at 07:46, Antoine Pitrou <anto...@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 deprecation_warning(library_version, visible_in_version, > change_in_version, msg, stacklevel): > ... > > Then a call like: > > deprecation_warning(my_library.__version__, "1.3", "1.4", "This function > is deprecated", 2) > > issues an InvisibleDeprecationWarning if my_library.__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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.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
