Python 3.11 changed many C structures related to code object and executed code object: PyCodeObject, PyFrameObject, PyThreadState. The PyFrameObject members are no longer public in Python 3.11. A long list of incompatible changes was coming from these changes that were motivated by the work on optimizing Python. Apparently, the optimization work was endorsed by the community, but it was not clear how to deal with C API incompatible changes.

In my PEP 620 – Hide implementation details from the C API (that I decided to withdrawn), I proposed a Process to reduce the number of broken C extensions.

Does it sound possible to define some general guidelines/guidance to:

• Measure the impact of an incompatible change (ex: estimate the ratio of affected projects),
• Notify and/or fix most important affected projects,
• Decide when it's acceptable to introduce the change in Python?
• Contingency Plan. If more and more projects are reported as being affected, can it rollback (revert) the change? Is there a backup plan to keep the change but disable it?

In the past, the method was simple: just push the change, and then do nothing :-)

Nowadays, code seach in PyPI top 5,000 project is used, the change is merged in Python, and Fedora rebuilds Python packages with alpha/beta versions of the new Python and report the list of affected projects.

If an incompatible change is introduced, I think that we need two things at minimum:

• Document the change: explain which kind of code is affected, maybe explain how to identify affected code
• Provide a solution working on the old and the new API (old and new Python versions) with a single code base: the usage of an external helper project like pythoncapi_compat is acceptable when the recipe is non-trivial