On 11 November 2017 at 17:34, Brett Cannon <br...@python.org> wrote: > On Thu, Nov 9, 2017, 17:33 Nathaniel Smith, <n...@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 | 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
