[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
runner.

Cheers,
Nick.

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


More information about the Python-Dev mailing list