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

[Antoine Pitrou]

On Mon, 6 Nov 2017 12:05:07 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> So my proposal is simple (and not really new): let's revert back to
> the way things were in 2.6 and earlier, with DeprecationWarning being
> visible by default, and app devs having to silence it explicitly
> during application startup (before they start importing third party
> modules) if they don't want their users seeing it when running on the
> latest Python version (e.g. this would be suitable for open source
> apps that get integrated into Linux distros and use the system Python
> there).
> 
> This will also restore the previously clear semantic and behavioural
> different between PendingDeprecationWarning (hidden by default) and
> DeprecationWarning (visible by default).

I'm on the fence on this.

I was part of the minority who opposed the original decision.  So I
really appreciate your sentiment.  Since then, I had to deal with a lot
of very diverse third-party libraries, and I learned that:

- most third-party libraries don't ever emit PendingDeprecationWarning;
  they only emit DeprecationWarning. So all their warnings would now be
  visible by default. (1)

- release cycles are much shorter on third-party libraries, so it's
  easier not to notice that one of your dependencies has started
  changing some of its APIs - maybe you'll notice in 3 months.  Also,
  perhaps you need a compatibility fallback anyway instead of
  unconditionally switching to the new version of the API, which adds
  to the maintenance cost.

- depending on not-well-maintained third-party libraries is a fact of
  life; these libraries may induce a lot of DeprecationWarnings on
  their dependencies, and still work fine until some maintainer
  comes out from the grave (or steps briefly into it before
  returning to their normal non-programming life) to apply a proper fix
  and make a release.


The one part where I think your proposal is good (apart from making
things a bit simpler for developers) is that I also noticed some
authors of third-party libraries don't notice until late that their
code emits DeprecationWarnings in dependencies.  By knowing earlier
(and having their users affected) they may be enticed to fix those
issues earlier.  But that's only true for third-party libraries with an
active enough maintainer, and a tight enough release schedule.


As for why (1) happens, I think it's partly because changing from one
warning to another is cumbersome; partly because many libraries don't
want to be constrained by a long deprecation cycle.

Regards

Antoine.