[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Nick Coghlan]

On 6 November 2017 at 17:09, Guido van Rossum <guido at python.org> wrote:
> I still find this unfriendly to users of Python scripts and small apps who
> are not the developers of those scripts.

At a distro level, these warnings being off by default has actually
turned out to be a problem, as it's precisely those users of Python
scripts and small apps running in the system Python that don't find
out they're at risk of a future distro upgrade breaking their tools
until they hit the release where they actually break. They then go to
the developers of either the distro or those tools saying "Everything
is broken, now what do I do?", rather than less urgently asking "Hey,
what's up with this weird warning I'm getting now?".

So compared to that current experience of "My distro upgrade broke my
stuff", getting back to the occasional "After my distro upgrade, a
bunch of my stuff is now emitting messages I don't understand on
stderr" sounds likes a positive improvement to me :)

> Isn't there a better heuristic we can come up with so that the warnings tend
> to be on for developers but off for end users?

That depends on where you're drawing the line between "developer" and
"end user". Someone working on a new version of Django, for example,
would probably qualify as an end user from our perspective, while
they'd be a framework developer from the point of view of someone
building a website.

If we're talking about "Doesn't even know what Python is" end users,
then the most reliable way for devs to ensure they never see a
deprecation warning is to bundle Python with the application, instead
of expecting end users to handle the task of integrating the two
together.

If we're talking about library and frameworks developers, then the
only reliable way to distinguish between deprecation warnings that are
encountered because a dependency has a future compatibility problem
and those that are internal to the application is to use module
filtering:

    warnings.filterwarnings("ignore", category=DeprecationWarning)
    warnings.filterwarnings("once", category=DeprecationWarning,
module="myproject.*")
    warnings.filterwarnings("once", category=DeprecationWarning,
module="__main__.*")

This model allows folks to more selectively opt-in to getting warnings
from their direct dependencies, while ignoring warnings from further
down their dependency stack.

As things currently stand though, there's little inherent incentive
for new Python users to start learning how to do any of this -
instead, the default behaviour for the last several years has been
"Breaking API changes just happen sometimes without any prior
warning", and you have to go find out how to say "Please tell me when
breaking changes are coming" (and remember to opt in to that every
time you start Python) before you get any prior notification.

I do like Barry's suggestion of introducing a gentler API specifically
for filtering deprecations warnings, though, as I find the warnings
filtering system to be a bit like logging, in that it's sufficiently
powerful and flexible that getting started with it can be genuinely
confusing and intimidating.

In relation to that, the "warn" module README at
https://pypi.python.org/pypi/warn/ provides some additional examples
of how it can currently be difficult to craft a good definition of
which deprecation warnings someone actually wants to see.

Cheers,
Nick.

P.S. That README also points out another problem with the status quo:
DeprecationWarning still gets silenced by default when encountered in
third party modules as well, meaning that also shows up as an abrupt
compatibility break for anyone that didn't already know they needed to
opt-in to get deprecation warnings.

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