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

Nick Coghlan ncoghlan at gmail.com
Thu Nov 9 19:46:40 EST 2017

On 10 November 2017 at 01:45, Barry Warsaw <barry at python.org> wrote:

On Nov 9, 2017, at 07:27, Tres Seaver <tseaver at palladion.com> wrote:

IIUC, that would be as expected: you would see the warnings when running your test suite exercising that imported code (which should run with all warnings enabled), but not when running the app.

Seems like a reasonable choice to me. I’m coming around to that view too. FWIW, I definitely do want to see the DeprecationWarnings in libraries I use, even if I didn’t write them. That let’s me help that package’s author identify them, maybe even provide a fix, and let’s me evaluate whether maybe some other library is better suited to my needs. It probably does strike the right balance to see that in my own test suite only.

Right, this was my reasoning as well: if someone has gone to the trouble of factoring their code out into a support library, it's reasonable to expect that they'll also write at least a rudimentary test suite for that code. (The one case where that argument falls down is when they only have an integration test suite, and hence run their application in a subprocess, rather than directly in the test runner. However, that's a question for test frameworks to consider: the case can be made that test runners should be setting PYTHONWARNINGS in addition to setting the warning filter in the current process)

By contrast, I have quite a bit of main-only code, and I routinely use the REPL to check the validity of snippets of code that I plan to use (or advise someone else to use). Those are the cases where the status quo sometimes trips me up, because I forget that I'm not getting deprecation warnings.

Cheers, Nick.

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

More information about the Python-Dev mailing list