[stdlib-sig] Breaking out the stdlib

[Brett Cannon]

On Tue, Sep 15, 2009 at 11:15, 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?).
>
> Therefore, I think it shouldn't be imposed as a general rule, rather a
> guideline.
>
> For example, Michael's work on unittest (a work of evolutionary changes)
> is much better news, IMO, that someone proposing to include nose in the
> stdlib. And I say that as a nose user. I don't want to maintain nose in
> the stdlib.
>

I don't think anyone is suggesting that we always reach outside of the
standard library when evolution is desired. It happens that for
argparse that occurred, and that's partially because optparse did not
lend itself to extension. Michael's work was great that it fit right
in, but that also occurred because he was given commit privileges to
do it. Without it he would either have needed to wait for someone to
check his stuff in or start a fork to get things done. Another reason
we need to do what we can to get through patches on the issue tracker.

>>  "Best" comes with baggage: it means that other solutions are
>> worse, and it admits the possibility that other code will someday
>> overtake the current solution to *become* best-of-breed.
>
> Of course. But it is also a double-sided argument because, if each new
> package remains the best-of-breed during only 2 years after it is
> integrated into the stdlib, we will spend a lot of time considering new
> packages for inclusion, deprecating other ones, and ultimately confusing
> the hell of our users.

We are not about to change modules every release.

-Brett