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
We reported the issue to many affected projects, or when possible, we
also wrote a pull request to make the code compatible (lot of those
were made by others, e.g. Hugo van Kemenade, thank you!).
+1 to rolling both of these back for 3.11. Deprecation removals are hard. Surfacing these to the impacted upstream projects to provide time for those to integrate the changes is the right way to make these changes stick in 3.12 or later. Thanks for doing a significant chunk of that work!
As you've done the work to clean up a lot of other OSS projects, I suggest we defer this until 3.12 with the intent that we won't defer it again. That doesn't mean we can't hold off on it, just that we believe pushing for this now and proactively pushing for a bunch of cleanups has improved the state of the world such that the future is brighter. That's a much different strategy than our passive aggressive DeprecationWarnings.
The problem is that fixing a Fedora package requires multiple steps:
* (1) Propose a pull request upstream
* (2) Get the pull request merged upstream
* (3) Wait for a new release upstream
* (4) Update the Fedora package downstream, or backport the change in
Fedora (only needed by Fedora)
Identifying the Python incompatible changes causing most troubles took
us a lot of time, but we did this work. Reverting the two Python 3.11
incompatible changes (causing most troubles) will save us "bug triage"
time, to get more time on updating projects to Python 3.11 for the
other remaining incompatible changes.
We are not saying that these incompatible changes are bad, it's just a
matter of getting most projects ready before Python 3.11 final will be
By the way, before making a change known to be incompatible, it would
be nice to run a code search on PyPI top 5000 projects to estimate how
many projects will be broken, and try to update these projects
*before* making the change.
For example, only introduce an incompatible change into Python once
less than 15 projects are affected. Getting a pull request merged is
nice, but a release including the fix is way better for practical
reasons: people use "pip install <project name>".
Fedora work on Python 3.11 is public and tracked at:
Click on "depends on" to see current issues:
Example of bz #2025600: mom fails to build with Python 3.11:
AttributeError: module 'configparser' has no attribute
Victor Stinner -- in the name of the Python Red Hat / Fedora maintenance team
Night gathers, and now my watch begins. It shall not end until my death.
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/GJTREADEXYAETECE5JDTPYWK4WMTKYGR/
Code of Conduct: http://python.org/psf/codeofconduct/