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

[Nick Coghlan]

On 7 November 2017 at 19:30, Paul Moore <p.f.moore at gmail.com> wrote:
> On 7 November 2017 at 04:09, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Given the status quo, how do educators learn that the examples they're
>> teaching to their students are using deprecated APIs?
>
> By reading the documentation on what they are teaching, and by testing
> their examples with new versions with deprecation warnings turned on?
> Better than having warnings appear the first time they run a course
> with a new version of Python, surely?
>
> I understand the "but no-one actually does this" argument. And I
> understand that breakage as a result is worse than a few warnings. But
> enabling deprecation warnings by default feels to me like favouring
> the developer over the end user. I remember before the current
> behaviour was enabled and it was *immensely* frustrating to try to use
> 3rd party code and get a load of warnings. The only options were:
>
> 1. Report the bug - usually not much help, as I want to run the
> program *now*, not when a new release is made.
> 2. Fix the code (and ideally submit a PR upstream) - I want to *use*
> the program, not debug it.
> 3. Find the right setting/environment variable, and tweak how I call
> the program to apply it - which doesn't fix the root cause, it's just
> a workaround.

Yes, this is why I've come around to the view that we need to come up
with a viable definition of "third party code" and leave deprecation
warnings triggered by that code disabled by default.

My suggestion for that definition is to have the *default* meaning of
"third party code" be "everything that isn't __main__".

That way, if you get a deprecation warning at the REPL, it's
necessarily because of something *you* did, not because of something a
library you called did. Ditto for single file scripts.

We'd then offer some straightforward interfaces for people to say
"Please also report legacy calls from 'module' as warnings".

You'd still get less-than-helpful warnings if you were running a
single file script that someone *else* wrote (rather than one you
wrote yourself), but that's an inherent flaw in that distribution
model: as soon as you ask people to supply their own Python runtime,
you're putting them in the position of acting as an application
integrator (finding a combination of Python language runtime and your
script that actually work together), rather than as a regular software
user.

Cheers,
Nick.

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