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

[Nick Coghlan]

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