[Python-Dev] PEP 594: Removing dead batteries from the standard library
steve at holdenweb.com
Thu May 23 15:32:08 EDT 2019
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.
On Thu, May 23, 2019 at 7:03 PM Barry Warsaw <barry at python.org> wrote:
> On May 20, 2019, at 13:15, Christian Heimes <christian at 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,
> > 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
> 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.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev