[Python-Dev] PEP 594: update 1

[Steven D'Aprano]

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.

https://old.reddit.com/r/Python/comments/brgl8v/pep_594_removing_dead_batteries_from_the_standard/eodvexl/

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 
"keep" list;

- 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*:

https://github.com/python/cpython/commit/34a042d301d6ab88645046a6dfa6c38265ca4b39

"This is the last time I fix binhex. If it breaks again it goes in the 
dustbin"

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:

https://bugs.python.org/issue29566

but I'm not sure if that's actually a bug or not. There was a 
documentation bug (in the source code) in 2017:

https://bugs.python.org/issue29557

and one enhancement request to clean up the code:

https://bugs.python.org/issue34063

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?


-- 
Steven