In my mind, I’ve gone back and forth on this possibility. And I realize I left out two crucial considerations.
First, leaving the code in place indefinitely leaves a maintenance burden of that code. It remains a surface vulnerable to bugs and security risks and simple user requests. Its mere presence adds a cognitive burden to inspecting the code. And since the code was intended to be deprecated, it’s considered frozen and allowed to be unprotected by tests.
Second, because the backport and CPython implementation are kept in sync, choosing not to remove the functionality from CPython would imply also not removing it from the backport or maintaining divergent implementations.
The goal in deprecating this functionality was to set it on the path to retirement so that what remains after some years is a clean implementation without the burden of legacy code.
Since the steering council has not given any guidance either here or in the relevant pull request, here’s my plan:
- Merge the pull request to introduce the deprecation warning on Python 3.11. This will give four Python versions (3.9-3.12) of cross compatibility, such that only 3.8 and 3.13 are incompatible (and thus honoring compatibility across all supported Python versions), a very generous window for functionality that’s available for Python 2.7 (via the backport).
- If someone volunteers to carry the maintenance burden of the legacy module (documentation, bug triage, tests, etc) and any divergence in CPython, I’ll allow that person to decide if and how to deprecate the module (including backing out the existing deprecation to a PendingDeprecationWarning or removing the warning completely).