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