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

Antoine Pitrou solipsis at pitrou.net
Mon Nov 6 08:39:52 EST 2017

On Mon, 6 Nov 2017 23:23:25 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 6 November 2017 at 21:58, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > I guess my takeaway point is that many situations are complicated, and
> > many third-party library developers are much less disciplined than what
> > some of us would idealistically expect them to be (those developers
> > probably often have good reasons for that).  For someone who takes care
> > to only use selected third-party libraries of high maintenance quality,
> > I'm very +1 on your proposal.  For the more murky (but rather common)
> > cases of relying on average quality third-party libraries, I'm +0.  
> Agreed, and I'm thinking there could be a lot of value in the variant
> of the idea that says:
> - tweak the default warning filters to turn DeprecationWarning back on
> for __main__ only

Thats sounds error-prone.  I'd rather have them on by default

> - add a new warnings module API specifically for managing deprecation warnings


And I think we need to handle two different use cases:

- silencing warnings *emitted by* a certain module (e.g. a widely-used
  module which recently introduced major API changes)

- silencing warnings *reported in* a certain module (e.g. a
  sporadically-maintained library whose usage frequently emits
  deprecation warnings coming from other libraries)

Ideally, we also need a CLI switch (or environment variable) to override
these settings, so that one can run in "dev mode" and see all
problematic usage accross their library, application and third-party



More information about the Python-Dev mailing list