Michael Foord wrote: > M.-A. Lemburg wrote: >> Frank Wierzbicki wrote: >> >>> On Mon, Sep 14, 2009 at 1:06 PM, Michael Foord >>> <mich...@voidspace.org.uk> wrote: >>> >>>> No-one argues that the standard library should evolve quickly but >>>> there do >>>> seem to be those arguing that it should *never* evolve. >>>> >>> I'll add my voice against the folks who want the stdlib to never >>> evolve. Java's standard library provides a nice cautionary example. >>> >> >> I don't think anyone has voiced such an opinion. There are different >> views on what "evolve" should mean and when to apply what actions, >> though. >> >> > > From a recent post in this thread: > > "That is, actually, pretty much what I want a stdlib for. I don't want > it to contain the newest, greatest, and best ways of doing things. I > want it to contain the things that people are willing to maintain until > hell freezes over, which will largely be things that aren't ever going > to change until hell freezes over."
Sigh, when quoting people, could you please leave their name in place. Thanks. The above quote is from Laura and, yes, it can be read in many ways. People who have been working with Python for many many years and have a huge code base to maintain do have a more reserved attitude towards changes - simply because they know how much work is involved in applying such major API changes to a code base, including retesting it all and getting it to work in a production environment again. And no, it's not a good idea to stick with some old release of Python for the sake of stability - you end up having to maintain 3-5 different Python installations on every single deployment machine... >> Replacing prefectly fine working code just for the fun of it, does >> not count much as argument for evolving the stdlib. >> >> > > Unless you are attacking a complete strawman, which is unhelpful and > pointless so please refrain, can you point out who is suggesting > replacing working code "just for the fun of it"? Just have a look at the various arguments for adding argparse to the stdlib with the intention of replacing optparse and getopt. On one hand you have this new API which is not compatible with optparse: http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html#upgrading-optparse-code On the other you have a rather short list of features that make argparse different from optparse: http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html and the fact that argparse has been in the wild for 4.5 months. optparse was added to Python in 2002 and had been around for a few years before that. getopt was added in 1990. Now, take into consideration that most command line scripts you write use one of the two modules and imagine the huge number of scripts out there which would have to be updated because of such a change in API. If you put everything together you get what I call "replacing working code just for the fun of it". -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 14 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
