Let's be more careful with planned removals

Core Development
1

Hello,
In Fedora, we’ve been testing Python 3.12 since the first Alpha versions.
Beta 1 has, a as usual for a beta 1, made more breaking changes than the usual pre-release. Adapting to any breaking change takes time and effort, especially for maintainers/integrators, who need to coordinate with primary developers and don’t know their code that closely.
If a widely-used project is broken, we can’t test its dependents until it’s at least hot-fixed.

I would like to “soften the blow” of beta 1, so that integration testing/fixing can be better spread out over time. The hope is both that Fedora can do better at testing and adapting the ecosystem, and that others might join the effort more easily. (Specifically, the imp removal forced an avoidable hustle. I don’t want to blame anyone for following the current process, but I’d also like to not repeat it in the future.)
I’d also like to ensure we follow current best practices when finalizing very old deprecations.

I propose that:

  • Finalizing a change that had a formal deprecation period (e.g. removal of deprecated API) must be done by the last 3.x.0 Alpha release. If it’s not done by then, it should wait until the next minor version.
  • Deprecations without an explicit planned removal date/version should not be finalized.
  • Adding a planned removal date/version should be treated as a new deprecation, e.g. choose a date at least 2 releases in the future, do the proper announcements, make sure the docs are ship-shape.

As always, the Steering Council can approve exceptions.

Does that sound reasonable?

7 Likes
2

Removing a function can take several weeks in practice, whereas the time window between of a new stable branch and the first alpha version is “short”. Sometimes, it takes time to stop using the function in Python itself. And doing that before the function is actually removed is less appealing. Sometimes, a major Python project (like pip or Cython) is impacted, the issue is discovered later, and we are waiting for a fix and/or a release including a fix which will come soon. Also, developers availability is not constant, sometimes people come and back depending on their other life duties.

Yes, it’s always better to batch most removal at the early stage of a new Python devcycle (I did that in Python 3.13!!!), but there are exceptions.

3

Shouldn’t that be done before deprecating it?

If it takes months to port CPython away from something, maybe it’s not yet the right time to deprecate it for everyone else.

Which is why I’m proposing the last alpha.

There always are. IMO, they need project-wide coordination/discussion. Getting the exception approved by the SC is a good proxy for that.

3 Likes
4

Notes on the imp module removal.

The imp removal was scheduled for a long time (the module was marked as deprecated and emitted a warning since Python 3.4), but it was blocked by pip (!): Remove more deprecated importlib APIs from Python 3.12. It also took many years to remove the imp usage in the Python code base. Obviously, last bits were only updated to importlib recently. The impact of imp removal (153 affected projects on PyPI top 5,000 projects) was known and taken in account in the decision. The imp removal was part of the larger change about the importlib module: Meta issue for cleaning up import system cruft.

There is now ongoing work to enhance the “update imp to importlib” documentation and helping affected projects:

2 Likes