Welcome to LWN.net
The following subscription-only content has been made available to you
by an LWN subscriber. Thousands of subscribers depend on LWN for the
best news from the Linux and free software communities. If you enjoy this
article, please consider subscribing to LWN. Thank you
for visiting LWN.net!
By Jake Edge
March 16, 2022
Python has often been touted as a “batteries included” language because of
its rich standard library
that provides access to numerous utility modules and is distributed with
the language itself. But those libraries need maintenance, of course, and
that is provided by the Python core development team. Over the years, it
has become clear that some of the modules are not really being maintained
any longer and they probably are not really needed by most Python
users—either because better alternatives exist or because they address
extremely niche use cases. A long-running project to start the removal of those
modules has recently been approved.
A 2018 Python Language Summit session was
the start of Christian Heimes’s quest to unplug some of the old batteries
in the standard library. That discussion led to the first
draft of PEP 594
(“Removing dead batteries from the standard library“) in
May 2019. It listed more than two dozen modules, scattered across the
standard library, to consider for removal.
The PEP has been floating around in Python space since that time; in
general, core developers have been favorably inclined toward the idea,
though deciding exactly which modules would be removed was always
difficult. The process of removing a module from the standard library
starts with deprecation for two release cycles, followed by the actual removal. But
the project has struggled with how to handle deprecations in the language over the last few
years, as our Python article
index entry shows.
Revival
Discussion of the PEP occurred sporadically in a thread
on the Python discussion forum since Heimes first posted the PEP there
in 2019. In early February, the PEP was revived
by new co-author Brett Cannon in a new
forum post. Cannon said that he expected to propose it for a decision
by the steering council (of which he is a member) soon, “barring any
major objections that come up in this topic“. As can be seen in the
update
history section of the PEP, the list of modules to be removed has
evolved over time.
The current version removes 21 separate modules that are described in
the PEP abstract as: “mostly historic data formats
(e.g. Commodore and SUN file formats), APIs and operating systems that have
been superseded a long time ago (e.g. Mac OS 9), or modules that have
security implications and better alternatives (e.g. password and
login).”
The full list of modules that would be removed in the PEP is as follows:
Type Modules Data encoding uu (and the
associated uu codec) and
xdrlibMultimedia aifc,
audioop,chunk,
imghdr,
ossaudiodev,
sndhdr, and
sunauNetworking asynchat,
asyncore,
cgi,
cgitb,
smtpd,
nntplib,
and telnetlibOS interface crypt,
nis, and
spwdMiscellaneous msilib and
pipes
Comparing that table with the one in our article on the introduction of the
PEP shows that the broad strokes are the
same, but the details have changed somewhat. The removals were meant to be
largely non-controversial, so if good reasons to keep a module were
raised—and the maintenance burden was low—it was retained. The list is
also different because some of the modules have already
been removed.
Modules that were considered for removal along the way, but
retained (at least for now), were also described in the
PEP along with the reasons behind keeping them. One of the more
amusing reasons for retaining a module is for wave, which
handles the WAV sound-file format:
According
to David Beazley the wave module is easy to teach to kids and
can make crazy sounds. Making a computer generate sounds is a powerful and
highly motivating exercise for a nine-year-old aspiring developer. It’s a
fun battery to keep.
The wave module also provides an example of the kinds of work that
remains to be done if the modules are removed; wave relies on the
audioop mo