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

[Steve Holden]

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 <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,
> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190523/3c42b001/attachment.html>