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

Toshio Kuratomi a.badger at gmail.com
Tue Nov 7 09:42:18 EST 2017

On Nov 7, 2017 5:47 AM, "Paul Moore" <p.f.moore at gmail.com> wrote:

On 7 November 2017 at 13:35, Philipp A. <flying-sheep at web.de> wrote:

Sorry, I still don’t understand how any of this is a problem.

If you’re an application developer, google “python disable DeprecationWarning” and paste the code you found, so your users don’t see the warnings. If you’re a library developer, and a library you depend on raises DeprecationWarnings without it being your fault, file an issue/bug there. For super-increased convenience in case 2., we could also add a convenience API that blocks deprecation warnings raised from certain module or its submodules. Best, Philipp

If you're a user and your application developer didn't do (1) or a library developer developing one of the libraries your application developer chose to use didn't do (2), you're hosed. If you're a user who works in an environment where moving to a new version of the application is administratively complex, you're hosed.

As I say, the proposal prioritises developer convenience over end user experience.

I don't agree with this characterisation. Even if we assume a user isn't going to fix a DeprecationWarning they still benefit: (1) if they're a sysadmin it will warn them that they need to be careful when upgrading a dependency. (2) if the developer never hears about the DeprecationWarning then it is ultimately the user who suffers when the tool they depend on breaks without warning so seeing and reporting the DeprecationWarning helps the end user. (3) if DeprecationWarnings are allowed to linger through multiple releases, it may tell the user about the quality of the software they're using.

More information is helpful to end users. Developers are actually the ones that it inconveniences as we'll be the ones grumbling when an end user who hasn't evaluated the deprecation cycles of upstream projects as we have demand immediate changes for deprecations that are still years away from causing problems. But unlike end users, we do have the ability to solve that by turning those deprecations off in our code if we've done our due diligence (or even if we haven't done our due diligence).

-Toshio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/59b6b2ee/attachment.html>

More information about the Python-Dev mailing list