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

[Paul Moore]

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.

I appreciate that this is open source, and using free programs comes
with an obligation to contribute back or deal with issues like this,
but even so, it's a pretty bad user experience.

I'd prefer it if rather than simply switching warnings on by default,
we worked on making it easier for the people in a position to actually
*fix* the issue (coders writing programs, educators developing
training materials, etc) to see the warnings. For example, encourage
the various testing frameworks (unittest, pytest, nose, tox, ...) to
enable warnings by default, promote "test with warnings enabled" in
things like the packaging guide, ensure that all new deprecations are
documented in the "Porting to Python 3.x" notes, etc.

Paul