What would _really_ help is getting the groups that maintain each dead parrot to collaborate on a "Python Legacy release" that adds back anything with a maintainer to the stdlib of the current Python version.
Even that will demand large resources, and if it's to be organised in a way that doesn't involve lots of dev time then perhaps the PSF could be involved? I presume the Steering Committee are the people to consider directions like this. Steve Holden On Thu, May 23, 2019 at 7:03 PM Barry Warsaw <ba...@python.org> wrote: > On May 20, 2019, at 13:15, Christian Heimes <christ...@python.org> wrote: > > > > here is the first version of my PEP 594 to deprecate and eventually > remove modules from the standard library. The PEP started last year with > talk during the Python Language Summit 2018, > https://lwn.net/Articles/755229/. > > > > The PEP can be confirmed in two stages. I'm not planning any code > changes for 3.8. Instead I only like to document a bunch of modules as > deprecated. Active deprecation is planned for 3.9 and removal for 3.10. The > long deprecation phase gives us 3 years to change our minds or handle edge > cases, too. > > Hi Christian, > > First, I appreciate the work you’ve done on this, and the general > sentiment. But I do feel like this is a partial solution to a problem the > Python distribution has had for a very long time. Maybe it’s a good step > forward, but in a sense it is incomplete and only chips away at the problem. > > We have two competing pressures, one to provide a rich standard library > with lots of useful features that come right out of the box. Let’s not > underestimate the value that this has for our users, and the contribution > such a stdlib has made to making Python as popular as it is. > > But it’s also true that lots of the stdlib don’t get the love they need to > stay relevant, and a curated path to keeping only the most useful and > modern libraries. I wonder how much the long development cycle and > relatively big overhead for contributing to stdlib maintenance causes a big > part of our headaches with the stdlib. Current stdlib development > processes also incur burden for alternative implementations. > > We’ve had many ideas over the years, such as stripping the CPython repo > stdlib to its bare minimum and providing some way of *distributing* a sumo > tarball. But none have made it far enough to be adopted. I don’t have any > new bright ideas for how to make this work, but I think finding a holistic > approach to these competing pressures is in the best long term interest of > Python. > > That all said, if PEP 594 can be viewed as part of the bigger picture, > then maybe it’s a good idea. Perhaps the approaches for maintaining such > deprecated libraries can be used as an experiment for finding a more > modern, useful, and vibrant approach to stdlib maintenance. > > Cheers, > -Barry > > _______________________________________________ > 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/steve%40holdenweb.com >
_______________________________________________ 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
