<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2019 at 11:03 AM Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On May 20, 2019, at 13:15, Christian Heimes <<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>> wrote:<br>
> <br>
> 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, <a href="https://lwn.net/Articles/755229/" rel="noreferrer" target="_blank">https://lwn.net/Articles/755229/</a>.<br>
> <br>
> 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.<br>
<br>
Hi Christian,<br>
<br>
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.<br></blockquote><div><br></div><div>Yep, but I will take this chipping away over nothing. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br></div></div></div>