Python removes ‘dead batteries’ from standard library

An initiative to remove outdated and unmaintained modules from Python’s standard library has been approved as Python Enhancement Proposal (PEP) 594. The modules being pruned are all antiquated, unmaintained, replaced by other modules, or some combination of the above.

There is little chance a modern Python developer will need to rewrite existing apps as a result of these changes. In any case, the modules slated for elimination will not be fully removed until two years from now.

Python has long had a “batteries included” philosophy, with the goal of providing a versatile standard library that handles many common development tasks. But criticisms have arisen in the past of how “dead batteries” in the standard library—outdated and hard-to-maintain modules—have outlasted their usefulness and ought to be removed.

PEP 594, authored by Python contributors Christian Heimes and Brett Cannon, was originally submitted in 2019, but finally approved for Python 3.11 on March 11. With this PEP, Python 3.11 will mark certain modules as deprecated, and Python 3.12 will be the last version to include those modules. By Python 3.13, the deprecated modules will be removed entirely. This provides a two-year window for those modules to be replaced wherever they might still be in use.

Few of the deprecated modules will ring any bells with modern Python developers. For instance, the uu module provides an encoding mechanism for the uuencode format, originally used to allow binaries to be encoded in emails. Aside from uuencode being rarely used today, the same codec is now provided elsewhere in Python.

Others might be somewhat familiar, if only because other standard library offerings have already eclipsed them. The pipes module was deprecated long ago in favor of subprocess, and the asynchat and asyncore modules have been replaced by asyncio.

PEP 594 does not provide a general mechanism for evaluating other standard library modules for removal in the future, but there’s clearly a need to have discussions about such efforts going forward. This point was raised by CPython core developer Gregory P. Smith in the discussion thread approving the PEP.

“Resolving ongoing discussions around how we define the stdlib for the long term does not block this PEP,” Smith wrote. “It seems worthwhile for us to conduct regular reviews of the contents of the stdlib every few releases so we can avoid accumulating such a large pile of dead batteries, but this is outside the scope of this particular PEP.”