On Mon, 6 Nov 2017 23:23:25 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > On 6 November 2017 at 21:58, Antoine Pitrou <solip...@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 everywhere. > - add a new warnings module API specifically for managing deprecation warnings +1 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 dependencies. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com