On Mon, 6 Nov 2017 12:05:07 +1000 Nick Coghlan <[email protected]> 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. _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com