[Python-Dev] PEP 565: Show DeprecationWarning in __main__

[Nick Coghlan]

On 13 November 2017 at 01:45, Guido van Rossum <guido at python.org> wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> In Python 2.7 and Python 3.2, the default warning filters were updated to
>> hide
>> DeprecationWarning by default, such that deprecation warnings in
>> development
>> tools that were themselves written in Python (e.g. linters, static
>> analysers,
>> test runners, code generators) wouldn't be visible to their users unless
>> they
>> explicitly opted in to seeing them.
>
> Looking at the official What's New entry for the change
> (https://docs.python.org/3/whatsnew/2.7.html#changes-to-the-handling-of-deprecation-warnings)
> it's not just about development tools. It's about any app (or tool, or
> utility, or program) written in Python whose users just treat it as "some
> app", not as something that's necessarily part of their Python environment.
> While in extreme cases such apps can *bundle* their own Python interpreter
> (like Dropbox does), many developers opt to assume or ensure that Python is
> avaiable, perhaps via the OS package management system. (Because my day job
> is software development I am having a hard time coming up with concrete
> examples that aren't development tools, but AFAIK at Dropbox the
> *deployment* of e.g. Go binaries is managed through utilities written in
> Python. The Go developers couldn't care less about that.)

It occurs to me that the original Dropbox client itself would be an
example of deprecation warnings in deployed code being unhelpful noise
- assuming that the runtime warnings were reported back to the
developers, the deprecation warnings would be entirely irrelevant to a
developer trying to debug a production issue with client/server
communication.

I've updated the PEP to try to make the explanation of the historical
rationale more accurate:
https://github.com/python/peps/commit/30daada7867dd7f0e008545c7fd98612282ec602

I still emphasise the developer tooling case, as I think that's the
easiest one for Python developers to follow when it comes to
appreciating the problems with the old defaults (I know it is for me),
but I've added some references to regular user facing applications as
well.

I've also added a new "Documentation Updates" section, which doesn't
technically need to be in the PEP, but I think is useful to include in
terms of giving the existing features more visibility than they might
otherwise receive (I learned quite a few new things myself about the
basics of warnings control researching and working on implementing
this PEP, so I assume plenty of end users are in a similar situation,
where we know the warnings module exists, but aren't necessarily
completely familiar with how to reconfigure it at runtime).

Cheers,
Nick.

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