[stdlib-sig] Breaking out the stdlib

[Antoine Pitrou]

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.

>  "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.

Regards

Antoine.