On Tue, Mar 29, 2022, 10:55 AM Brett Cannon <br...@python.org> wrote:
> > > On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <ronaldousso...@mac.com> > wrote: > >> >> >> On 29 Mar 2022, at 00:34, Brett Cannon <br...@python.org> wrote: >> >> >> >> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker <python...@gmail.com> >> wrote: >> >>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore <p.f.mo...@gmail.com> wrote: >>> >>>> >>>> >> 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. 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>. > One of the things that's often missed in discussions is that a *good* policy document can also help grow the number of maintainers. As just one example, i found two interesting items in the discussion started by Skip about determining what modules don't have maintainers just downstream if this. (1) There's a file which matches maintainers to modules in the stdlib (this is documented but i only found out about it a few years ago and Skip, who's been around even longer than me didn't know about it either... So this means something about how our policy docs are currently structured could be improved). (2) Terry brought up that you don't have to be a core maintainer in order to take up ownership of something in the stdlib. That's awesome! But this is definitely something i didn't know. I've been "focusing"[1] on becoming a core maintainer because i thought that was a prerequisite to getting anything done in the stdlib. Knowing that getting involved with stdlib maintenance is different could be vastly helpful. [1] focusing is the wrong word... It expresses the feeling of "directed action" correctly but doesn't convey the lack of activity that sprinkles my attempts. Nor does it account for discouragement, helplessness, and imposter-y feelings which are the reasons for that lack. -toshio
_______________________________________________ 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/GBNDUQXWTBGCP5243L4HUU5UVLKQ7UWB/ Code of Conduct: http://python.org/psf/codeofconduct/
