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

[Victor Stinner]

Hi Christian,

I dislike the PEP 594 title: "Removing dead batteries from the
standard library". A module is never "dead", there are always users,
even if there are less than 5 of them.

Extract of the Rationale: "The modules are mostly historic data
formats and APIs that have been superseded a long time ago"

If we take the example of NNTP: even if it's old and "superseded",
people still uses NTTP. Python doesn't have to be opinionated about
formats.


Wait, I like the overall PEP. I'm just talking about how it's explained.

IMHO the question here is if the core developers want to continue to
pay the price of the maintenance burden for modules which have "few"
users (define few...). The other question is if it would be acceptable
to move these modules to PyPI. "import wave" would continue to work as
previously, but the maintenance would be moved *outside* Python.

Who will maintain these modules on PyPI? Do we have to define this right now?

If a module is pure Python, well, the easy solution is to embed it
into your code: cp /path/to/cpython/Lib/<module>.py
/path/to/yourapp/<module>.py. If it's a C extension, it's more
complicated.

For me the risk of the PEP 594 is to create a new Python 3 mess.
Pedantic core devs who explain to users that their code is wrong and
they must fix it... But the code was running fine for 20 years!

The PEP is full of "Substitute: none". I'm not comfortable with that.
I would prefer to require that there is always a solution, like
putting the code on PyPI and let it die there. The old mojo "the
stdlib is where modules die" would become "PyPI is where old stdlib
modules die" :-)

Python itself is bad at fixing DeprecationWarning: imp and asyncore
are deprecated for years, but they are still widely used inside
Python...

"Stop using deprecated imp module; imp should now emit a real
DeprecationWarning" is open since 2015:
https://bugs.python.org/issue25160

"Replace asyncore" open since 2016
https://bugs.python.org/issue28533

"test_poplib replace asyncore" open since 2017
https://bugs.python.org/issue30514

I dislike DeprecationWarning *but* ... well, does it really hurt so
much to keep these modules around? asyncore has know bugs, *but* many
tests of our test suite are based on that and we managed to make these
tests very reliable only with minor work.

---

Even if it's not said this way, in fact this PEP reopens the question
of splitting the stdlib. It would be helpful to have some references
into the PEP about previous discussions on this topic. Recent
discussion:

"Amber Brown: Batteries Included, But They're Leaking "
http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html

By the way, even if it's not directly related, the PEP doesn't address
one of the common question: be able to override a stdlib module with a
more recent version. For example, if the Python provided by your OS
contains a bug in asyncio, you are stuck and cannot easily upgrade it
to get a new version without the fix.

---

For me, "getopt" is a dead battery. The PEP says "Although users are
encouraged to use argparse instead, the getopt module is still widely
used."

Well, that makes sense. But so, what is the metric to decide if a
module is "widely used" or not?

Should we keep a module at soon as at least one user says "I'm using
it!". In other replies, users asked to keep spwd, fileinput, nntplib,
etc.


---

Sorry, I mostly opened questions. I don't have answers. I just wanted
to share that this PEP scares me a little bit. At least, the current
version of the PEP.

Victor


Victor