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". 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. Cheers, Nick. -- 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