On 21/05/2019 13.50, Victor Stinner wrote: > 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.
I'm open for suggestions for a better title. > 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. NNTP was added late in the writing of the PEP. I can rephrase the rational > 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? Whoever steps up and is interested to maintain the module. But we don't have to define this now. We have more than a year to come up with a plan. Except for the parser module, all modules will be maintained by Python core until 2026. > 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. This only affects nis, ossaudiodev, spwd, and msi. For crypt I already have a ctypes wrapper. ossaudiodev is dead and has been replaced by ALSA about two decades ago. spwd is bad and users should use PAM instead. > 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" :-) The latest version of the PEP lists many additional substitutes. I'll post a new version soonish. > Python itself is bad at fixing DeprecationWarning: imp and asyncore > are deprecated for years, but they are still widely used inside > Python... We are keeping the old packages to make transition from 2.7 to 3.8 easier. This is going to change with 3.9. > 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. I'm struggeling with asyncore in SSL tests, mostly because I don't grasp how asyncore works and I have no intention to dig into a deprecated technology. > 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. As you said, it's not directly related. These topics are not within scope for the PEP. Please open a new thread. I like to keep this thread on topic. > 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. getopt is very short, has no maintainance overhead, and useful for quick hacks. fileinput stays as well for the same reason. > 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. The PEP will be implemented over a course of two releases and three years. It gives us enough time to address concern or change our minds. Christian _______________________________________________ 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
