On Tue, Jan 18, 2022 at 9:43 AM Richard Damon Richard@damon-family.org wrote:
On Jan 18, 2022, at 11:34 AM, Guido van Rossum firstname.lastname@example.org 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 email@example.com wrote:
On Tue, 18 Jan 2022 15:17:41 +0100 Victor Stinner firstname.lastname@example.org 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 others:
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
Doesn't this show, once again, that making DeprecationWarning silent by default was a mistake?
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?) http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/*
One thought, what if they were off by default UNLESS you were doing unit tests?
I believe pytest already does this.
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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/UAHZKJNQ... Code of Conduct: http://python.org/psf/codeofconduct/