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 _______________________________________________ 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
