[Python-Dev] PEP 594: Removing dead batteries from the standard library

[Steven D'Aprano]

Let me be clear: I do not oppose the removal of modules where necessary, 
but I do not like this PEP as it stands. But full credit to Christian 
for graciously accepting feedback; I also acknowledge that if this PEP 
is accepted, we still have at least two releases to change our minds 
about individual modules.

My largest issue with the PEP as a whole is that I don't like lumping a 
whole lot of unrelated modules together in one PEP. I believe it 
encourages a risky sense of "we ought to clean house and throw out all 
this junk!" rather than a measured consideration of pros and cons of 
each module individually.

I would rather see a serious of much smaller mini-PEPs, one per module. 
They need not be large: we can take as a given that we can and should 
remove "dead batteries" (but not merely unloved batteries in good 
working order, or slightly leaking batteries that just need a bit of 
care.) Each mini-PEP need only lay out the case for and against removal 
of one module (or perhaps a small number of closely related modules, not 
defend the principle in the abstract.

As I see it, there is a problem with this approach of a single omnibus 
PEP. A single PEP has reduced visibility for users of any specific 
module. This can easily lead to users of a module being under- 
represented in the discussion even if they are subscribed to Python-Dev.

Let's say Alice is a heavy user of the "aardvark" module. If Alice sees 
a PEP "Deprecate and remove aardvark", she is likely to speak up and air 
her objections.

But if Alice sees a single PEP "Remove dead batteries", she's likely to 
think "of course the aardvark library is not a dead battery, people like 
me us it all the time" and not realise she needs to make her objection 
known. Especially if the discussion thread is large. This thread has 
already reached 70 messages.

    "To meaningfully contribute, I will need to read all 70 messages
    in the Dead Battery thread, most of which are about modules I 
    don't care about."

versus:

    "I need to read 5 messages in the Remove Aardvark thread."

So I think that, relative to having one mini-PEP per module, a single 
PEP may be unintentionally biased towards the "Yes remove the lot" case 
and under-representing those who use some of these unloved batteries.

The problem is compounded by the prejudicial language used: nobody 
thinks of the modules they use as "dead batteries". How can they be dead 
when they work fine?

E.g. the binhex module *just works* -- if there are any bugs in it, I 
haven't come across them. binhex is not an obsolete file format for 
people like me who sometimes needs to read and write old Mac files.
It might be an old and unloved battery, but its not dead.


> On the other hand, Python's standard library is piling up cruft, unnecessary
> duplication of functionality, and dispensable features. This is undesirable
> for several reasons.

What you are calling cruft and dispensable, others call useful and 
indispensable. We've already seen at least three modules removed from 
the list of "cruft": colorsys, nttplib, fileinput. There may have been 
more by now -- I haven't caught up on all 70 posts yet.

I also think the PEP doesn't make the case for some of the things being 
asserted. For example:

> * Any additional module increases the maintenance cost for the Python core
>   development team. The team has limited resources, reduced maintenance cost
>   frees development time for other improvements.

This may often be the case, but not always.

If a module is stable, there's little maintenance cost to speak of. It 
works, there are (hopefully!) no known bugs, or at least no *serious* 
bugs, so why touch it? A module that isn't being changed could mean two 
things:

1. It is essentially complete. It does what it does, more or less 
correctly, and doesn't need new features or bug fixes.

2. It is suffering from bitrot.

I think the PEP fails to make the case for 2 over 1.


> * Modules in the standard library are generally favored and seen as the
>   de-facto solution for a problem. A majority of users only pick 3rd party
>   modules to replace a stdlib module, when they have a compelling reason, e.g.
>   lxml instead of `xml`.

Is this a problem that we need to fix?


>   The removal of an unmaintained stdlib module
>   increases the chances of a community contributed module to become widely
>   used.

I don't think the conclusion is justified. It could just as easily lead 
to a lack of any such library (the would-be users lack the ability or 
time to maintain one), or a plethora of alternatives:

"Should I use binhex 1.2, or MacBinHex 0.5, or BinnyMacHexFace 5.7, or 
xehnib 0.8?, or ... "



> * A lean and mean standard library benefits platforms with limited resources
>   like devices with just a few hundred kilobyte of storage (e.g. BBC
>   Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
>   (e.g. pyodide) also benefit from reduced download size.

And I think this argument needs to be strongly challenged. I don't think 
the CPython stdlib should be cut down to be "lean and mean" for the sake 
of people using Python on micro-platforms. Let the tiny Pythons choose 
their own standard library.


Some more comments:

> All deprecated modules will also undergo a feature freeze. No additional
> features should be added. Bug should still be fixed.

I disagree with this. If people are requesting or contributing features 
to a module, that's a good sign that it *is* in use and isn't dead 
and we shouldn't remove it.

It seems perverse to say "we ought to remove this module because nobody 
is maintaining it" and then reject attempts to maintain it!

You'll notice that so far, apart from the example of binhex above, I 
haven't come out in favour or against removing any specific library. 
That's intentional: I would like to seperate criticism of the PEP as a 
document from arguments about which modules should stay.

Thank you,



-- 
Steven