On 6 December 2017 at 06:43, Victor Stinner <victor.stin...@gmail.com> wrote: > At the end, I'm not sure that the PEP 565 is really needed or would help > anyone.
Folks, I'd really appreciate it if you could comment on the merits of the PEP without implicitly claiming that I don't exist, and that Linux system administrators don't exist :) Right now, Linux distro Python library upgrades (including CPython updates to a new feature release) may result in *hard compatibility breaks*, as previously deprecated features disappear without warning. With PEP 565, ad hoc personal scripts will at least get a DeprecationWarning when APIs they're using are at risk of disappearing as a result of a distro package or version update. Right now, they don't get a warning at all. There is *no way* for any opt in flag to help these users. Now, PEP 565 being rejected wouldn't be the end of the world on that front - we can apply comparable changes as a downstream patch. However, these problems aren't unique to Linux, and they aren't unique to any specific distro: they apply whenever folks are using Python for personal workflow automation, rather than for redistributable applications and libraries. So it makes more sense to me to do this upstream, rather than having the default warnings handling be a redistributor dependent behaviour. That said, I go agree we could offer easier to use APIs to app developers that just want to hide warnings from their users, so I've filed https://bugs.python.org/issue32229 to propose a straightforward "warnings.hide_warnings()" API that encapsulates things like checking for a non-empty sys.warnoptions list. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
