On Jan 18, 2022, at 11:34 AM, Guido van Rossum <email@example.com> wrote:At best it shows that deprecations are complicated no matter how well you plan them. I remember that "noisy by default" deprecation warnings were widely despised.On Tue, Jan 18, 2022 at 6:49 AM Antoine Pitrou <firstname.lastname@example.org> wrote:On Tue, 18 Jan 2022 15:17:41 +0100
Victor Stinner <email@example.com> wrote:
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> We propose to revert the following 2 changes in Python 3.11 and
> postpone them in a later Python version, once most projects will be
> compatible with these changes:
> * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages
> * Removals from configparser module (bpo-45173) - broke 28 Fedora packages
Doesn't this show, once again, that making DeprecationWarning silent by
default was a mistake?
--One thought, what if they were off by default UNLESS you were doing unit tests?
_______________________________________________That would cut out a lot of the excessive noise issue, but put them in before the programmer when they are developing. Yes, they will get the warnings for dependencies but that lets the programmer apply pressure to fix it or warning they may need to change something if it won’t get fixed.
Python-Dev mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Message archived at https://firstname.lastname@example.org/message/UAHZKJNQTMXDORVGX5U5EHKI4HQAV7BN/
Code of Conduct: http://python.org/psf/codeofconduct/