[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Nov 8 16:43:29 EST 2017
- Previous message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Next message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9 November 2017 at 07:09, Simon Cross <hodgestar+pythondev at gmail.com> wrote:
On Wed, Nov 8, 2017 at 10:33 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
For interactive use, the principle ends up being "Code you write gives deprecation warnings, code you import doesn't" (which is the main aspect I care about, since it's the one that semi-regularly trips me up when I forget that DeprecationWarning is off by default). I with Antoine here. The idea that "code in main" is the set of code someone wrote really seems a lot like guessing (and not even very good guessing). If everyone follows the "keep main small" then scripts won't automatically display deprecation warnings by default and so the original problem of "warnings are easy to miss" remains.
That's an intended outcome - the goal is to have applications that are packaged in any way (installed Python package, importable packages with a main submodule, zip archives with a main.py file) continue to silence deprecation warnings by default, as in those cases, the folks running them are users of those applications, rather than developers on them.
Counter proposal -- why don't testing frameworks turn on warnings by default? E.g. like pytest-warnings? That way people running tests will see warnings and others won't unless they ask to see them.
They do. The problem is that this only works for things that actually have test suites, which misses a lot of "Interactive Python is part of the user experience" use cases, like CPython's own REPL, and personal scripting on a platform like Linux or conda.
However, between them, the following two guidelines should provide pretty good deprecation warning coverage for the world's Python code:
- If it's in main, it will emit deprecation warnings at runtime
- If it's not in main, it should have a test suite
Thus the future answer to "I don't want deprecation warnings at runtime" becomes "Move it out of main into an importable module, and give it a test suite".
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Next message (by thread): [Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]