Zachary Ware and me removed 19 modules in Python 3.13 stdlib, modules deprecated in Python 3.11 by PEP 594 – Removing dead batteries from the standard library.
Moreover, I also removed the 2to3 program and lib2to3 module in Python 3.13, deprecated in Python 3.11: PEP 617 PEG Parser.
By the way, Python 3.12 removed 5 stdlib modules:
smtpd: PEP 594
distutils: PEP 632
imp: replaced by importlib (added to Python 3.11)
I suppose that in all of these removed modules, the ones which will cause most troubles will be:
distutils(setuptools may save us, it still provides distutils)
PEP 594 (created in 2019) was controversial: people have good reasons to want a large and functional Python stdlib and we took them in account. But the Steering Council took a decision and approved it. I now suggest to move on to make this migration as smooth as possible. I chose to remove PEP 594 modules as soon as possible in Python 3.13 development cycle to get user feedback as soon as possible, and have more time to prepare the Python ecosystem for this migration: to help projects to move away from these removed modules.
For me, PEP 594 moves the maintainance of the removed modules outside Python. People using them now have to organize themselves to decide how to maintain the code they are relying on outside the Python project. The rationale is that the team maitaining Python is mostly made of volunteers and is too small to maintain 300 stdlib modules and C extensions (that’s a lot of code, tests and documentation). This maintainance is expected to be more healthy and efficient outside the Python projects with less constraints about contributions (it’s long and hard to become a Python core developer, PR reviews in Python is a known bottleneck and no simple solution was found so far).
Python 3.12 final release is scheduled in 4 months (October 2023) and Python 3.13 final release is scheduled in 1 year and 4 months (October 2024).
See my notes about the Python standard library which lists added and removed stdlib modules since Python 3.0, with references to PEPs, issues and deprecations.
If your project is affected, you have different solutions:
- Do nothing! For now, only remain compatible with Python 3.11 and older. IMO it’s a dangerous long-term choice. The technical debt only becomes more expensive over time. But maybe someone will come with a solution for you in the meanwhile.
- Attempt propose recipes and alternatives in the What’s New documents.
- Create a group of volunteers and give a new life to the removed module by maintaining them on PyPI. You will be able to use
pip install <module>. Then Linux distributions should package it and add it as a new dependency to your projects.
- Copy the removed module inside your project and maintain it there. Usually it’s a single short
.pyfile, if you chose to skip documentation and tests. Just be careful about the license and copyright. You’re now on your own to maintain it, but this solution is quick and simple.
See the Python license.
About PyPI, the removed
nntplib module already found a new home there: PyPI nntplib project. So far, users feedback seem to be positive. If possible, I suggest to attempt keeping the Git history of copied files like:
Lib/test/test_<module>.py. Again, please be careful about licensing and copyright. To keep the Git history, you can try:
- git-filter-repo project
Please comment below if you have some concrete advices and feedback about these tools.
Another example is the old-demos Git repository which contains demos and scripts removed from Python 3.12 (it seems like this one didn’t keep the Git history).
You can use this discussion to share your recipes on how to move away of some removed modules, and to organize the creation of a new warm home of some removed modules.