On 13 November 2017 at 01:45, Guido van Rossum <guido@python.org> wrote:
On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan <ncoghlan@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-depre...) 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/30daada7867dd7f0e008545c7fd98612282ec6... 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@gmail.com | Brisbane, Australia