[Python-Dev] PEP 594: update 1
steve at pearwood.info
Thu May 23 20:44:22 EDT 2019
On Thu, May 23, 2019 at 02:06:13PM -0700, Brett Cannon wrote:
> On Wed, May 22, 2019 at 1:23 PM Sean Wallitsch <
> sean.wallitsch at dreamworks.com> wrote:
> > My apologies for that oversight. My understanding is that many of the
> > methods present in aifc depend heavily on audioop for reading and writing.
> But are people using audioop directly?
Yes they are.
Shouldn't the PEP be responsable for establishing (as well as any
negative can be proven) that these modules aren't used, rather than
merely assuming that they aren't?
Of course it is hard to establish that a module isn't being used. Not
all code can be searched for on the Internet, there's huge amounts of
non-open source code written by users that never leaves their computer,
or behind corporate firewalls.
The difficulty of proving this negative requires that we be especially
conservative about removal. At the very least, we should demonstrate
that the package is *an active burden*.
Its not enough to say "nobody has touched this module for ages" since
stable, working code doesn't rot unless we change the language (or the
std lib!) and break it.
So far, the PEPs record hasn't been too good: out of the 31 modules
listed in the original draft, the PEP marks four as "keep", leaving 27
to be deprecated. So far, we've found:
- the sound libraries are in heavy use by hobbyists and the professional
audio-visual industry; aifc in particular is a mature, stable library
that isn't break and doesn't need much attention;
- cgi and cgitb are used by people who don't need a heavyweight HTML
solution (see Reddit);
- colorsys, fileinput and nntplib (at least) have been added to the
- the removal of spwd (and crypt?) has been controversial.
So far, nearly 30% of the so-called "dead batteries" turn out to be not
so dead after all.
I may have missed some. Nor have I even talked much about modules which
I personally use occasionally, like binhex, because it's not about *me*
its about the community. As much as I would prefer binhex to remain, if
it is removed I will be disappointed but I'll make do.
Speaking of binhex, I tried to get a sense of how much of a burden it
actually is. There was a comment by Guido in *2007*:
"This is the last time I fix binhex. If it breaks again it goes in the
which of course is Guido's perogative to say Won't Fix. Its now 2019 and
it hasn't broken again, or at least it hasn't broken again sufficiently
to make any difference. Serhey found one issue:
but I'm not sure if that's actually a bug or not. There was a
documentation bug (in the source code) in 2017:
and one enhancement request to clean up the code:
Other than that, Serhey touched binhex.py as part of a mass patch to
almost the whole stdlib to modernise file handling to use "with".
So by my count, in 12 years since Guido's frustrated comment about
binhex, it has seen:
- removal of an obsolete and ambiguous comment from the source code;
- addition of a few with blocks to modernise file handling;
- one enhancement request still outstanding;
- one possibly a bug (or maybe not) still outstanding.
I may have missed some, but we're talking about one issue per three
years. How is this a maintenance burden?
More information about the Python-Dev