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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
