[Python-Dev] Proposal: go back to enabling DeprecationWarning by default (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Nov 6 03🔞55 EST 2017

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

More information about the Python-Dev mailing list