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

Nick Coghlan ncoghlan at gmail.com
Sat Nov 11 18:29:36 EST 2017

On 11 November 2017 at 17:34, Brett Cannon <brett at python.org> wrote:

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

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.

For mypy itself, the CLI is declared as a console_scripts entry point, so none of mypy's own code actually runs in main - it's all part of an imported module.

And given that one of the key benefits of static analysis is that it doesn't run the code, I'd be surprised if mypy could ever trigger a runtime warning in the code under tests :)

For other test runners that do import the code under test, I think that our responsibility is to make it clearer that the default warning state isn't something that test runner designers should passively inherit from the interpreter - deciding what the default warning state should be (and how to get subprocesses to inherit that setting by default) is part of the process of designing the test runner.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list