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

[Nick Coghlan]

On 6 November 2017 at 16:26, Stephen J. Turnbull
<turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
> Nick Coghlan writes:
>
>  > Hence the proposed documentation change: the responsibility for
>  > silencing these warnings (for both their own code and for their
>  > dependencies) should rest with *application* developers,
>
> How do you propose to handle users with legacy apps that they can't or
> their organization won't or they don't wanna upgrade?  As I understand
> it, their only option would be something global, which they may not
> want to do.

Put "PYTHONWARNINGS=ignore::DeprecationWarning" before whatever
command is giving them the warnings.

Even on Windows, you can put that in a batch file with the actual
command you want to run and silence the warnings that way.

This is the same philosophy we applied in PEP 493 to provide a
smoother transition to HTTPS verification (via selective application
of PYTHONHTTPSVERIFY=0)

>  > We've been running the current experiment for 7 years, and the main
>  > observable outcome
>
> Well, yeah.  You can't observe something that doesn't happen, period.
>
> Bottom line: this is NOT a simple proposal, because it inherently
> deals in counterfactual reasoning.

No, it doesn't, as we've tried both approaches now: warning by default
for the ~20 years leading up to Python 2.7, and not warning by default
for the ~7 years since.

Prior to 2.7, the complaints we received mainly related to app
developers wanting to pass responsibility for *their* UX problems to
us, and ditto for poorly maintained institutional infrastructure.

So we've tried both ways now, and the status quo has led to *us*
failing to provide adequate advance notice of breaking changes to
*our* direct users. That's a far more important consideration for
CPython's default behaviour than the secondary impact on users of
applications that happen to be written in Python that are paying
sufficient attention to stderr to be scared by DeprecationWarnings,
but not paying sufficient attention to learn what those
DeprecationWarnings actually mean.

Cheers,
Nick.

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