[stdlib-sig] Breaking out the stdlib
Michael Foord
michael at voidspace.org.uk
Tue Sep 15 20:23:41 CEST 2009
Antoine Pitrou wrote:
> [snip...]
> 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.
>
Evolving an existing library, as a rule, is definitely better than
replacing it with a new one. There is a cost involved in removing a
library. It isn't always possible though to meet requirements with an
existing API - as is the case with optparse / argparse.
>
>> "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.
>
The bar for including a module in the standard library is high (which is
where the best of breed requirement comes from) because *we* do commit
to maintain it. That doesn't mean we commit to maintaining things
forever though (at least I can't find that promise in the documentation
anywhere...).
Flipping modules every two years would of course be ridiculous - but we
still don't guarantee that any module will remain forever.
I don't think I would go as far as Collin hinted (without necessarily
meaning anything so radical) in maintaining the standard library as a
constantly changing "current best of breed", but I agree with his other
sentiments.
Michael
> Regards
>
> Antoine.
>
>
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
More information about the stdlib-sig
mailing list