[stdlib-sig] Breaking out the stdlib

[Jesse Noller]

On Tue, Sep 15, 2009 at 2:15 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Le mardi 15 septembre 2009 à 13:48 -0400, Collin Winter a écrit :
>>
>> The commonly-expressed idea behind the stdlib is that it represents
>> best-of-breed code: it should have an independent userbase first, it
>> should have proven itself in the wild before it is allowed into the
>> stdlib.
>
> Asking libraries to be proven in the wild sounds like a good idea, but
> it promotes disruptive changes (replacing a module with another one)
> rather than evolutionary changes. It also means that we get potentially
> bloated or bizarrely idiomatic packages, because they weren't subject to
> the same standards of simplicity / austerity that we value in the stdlib
> (multiprocessing comes to mind, doesn't it? how much time did we lose
> because of its byzantine API and implementation? how robust and
> maintainable is it, even now, although the original PyPI package was
> acclaimed?).

Yup, multiprocessing is a perfect example of something popular in the
wild, but was rushed to inclusion because I proposed it late in the
cycle. If I had to do it again - as the guy who is still on the hook
for bug fixes, evolving it, and general maintenance, I'd not have
gotten it in there in the state it went in. I should have proposed it
earlier in the 2.6/3.0 process, and spent more time working on it.

Thanks for your vote though.

Today, I still fix bugs, work on improvements, etc. In my mind,
multiprocessing is a poor example because it was pulled in *so
quickly* - not because it was pulled in, and not because it has bugs.
But rather a bar that should have been met, was not due to time.

On the other hand - at least it has a maintainer (me) unlike some 50%
of the rest of the libraries. So it has some small thing going for it.
It also has tests. And documentation. And I continue to add to those
when I can.

How much of the rest of the standard libs can claim that?

jesse