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@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
