[Python-Dev] we will probably be having an difficult discussion about the stdlib after PEP 594 is done (was: PEP 594: Removing dead batteries from the standard library)

[Brett Cannon]

On Thu, May 23, 2019 at 11:03 AM 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.
>

Yep, but I will take this chipping away over nothing. :)


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

I'm personally viewing it as a first step in addressing the maintenance
burden we have with such a large stdlib. Christian started this work over a
year ago and I think it's worth seeing through. After that we should
probably have a discussion as a team about how we view the stdlib long-term
and how that ties into maintaining it so that people's opinion of the
stdlib's quality goes up rather than viewing the quality of it as varying
module-to-module.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190523/5facd739/attachment-0001.html>