On 10 November 2017 at 01:45, Barry Warsaw <ba...@python.org> wrote: > On Nov 9, 2017, at 07:27, Tres Seaver <tsea...@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 | 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
