[Python-Dev] [python-committers] Enabling depreciation warnings feature code cutoff

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


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

More information about the Python-Dev mailing list