> On 29 Mar 2022, at 19:51, Brett Cannon <br...@python.org> wrote: > > > > On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <ronaldousso...@mac.com > <mailto:ronaldousso...@mac.com>> wrote: > > >> On 29 Mar 2022, at 00:34, Brett Cannon <br...@python.org >> <mailto:br...@python.org>> wrote: >> >> >> >> Once >> https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ >> >> <https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/> >> is considered resolved, the next part of my "what is the stdlib" plan is to >> finally try to suss all of this out and more-or-less write a stdlib policy >> PEP so we stop talking about this. My guess it will be more of guidance >> about what we want the stdlib to be and thus guide what things belong in it. >> No ETA on that work since I also have four other big Python projects on the >> go right now whose work I am constantly alternating between. > > Having such a policy is a good thing and helps in evolving the stdlib, but I > wonder if the lack of such a document is the real problem. IMHO the main > problem is that the CPython team is very small and therefore has little > bandwidth for maintaining, let alone evolving, large parts of the stdlib. In > that it doesn’t help that some parts of the stdlib have APIs that make it > hard to make modifications (such as distutils where effectively everything is > part of the public API). Shrinking the stdlib helps in the maintenance > burden, but feels as a partial solution. > > You're right that is the fundamental problem. But for me this somewhat stems > from the fact that we don't have a shared understanding of what the stdlib > is, and so the stdlib is a bit unbounded in its size and scope. That leads > to a stdlib which is hard to maintain.
That (the hard to maintain part) is not necessarily true, if we had enough resources…. In theory the stdlib could be split into logical parts with teams that feel responsible for those parts (similar to having maintainers sign up for various platforms). That doesn’t work because of the small team, and partially also due to necessarily having very strict rules w.r.t. backward compatibility. > It's just like dealing with any scarce resource: you try to cut back on your > overall use as best as you can and then become more efficient with what you > must still consume; I personally think we don't have an answer to the "must > consume" part of that sentence that leads us to "cut back" to a size we can > actually keep maintained so we don't have 1.6K open PRs > <https://github.com/python/cpython/pulls>. I agree, but this is something to state explicitly when describing what should and should not be in scope for the stdlib. I’m a fan of a batteries included stdlib, but with our current resources we cannot afford to have some bits in the stdlib that would “obviously” be a candidate for a modern batteries included stdlib, such as a decent HTTP stack with support for HTTP/1, /2 and /3. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JS23QUVXW3HZHQFMZBOXUCKT332KGRYS/ Code of Conduct: http://python.org/psf/codeofconduct/
