[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

Michael Foord wrote:
> M.-A. Lemburg wrote:
>> Frank Wierzbicki wrote:
>>  
>>> On Mon, Sep 14, 2009 at 1:06 PM, Michael Foord
>>> <michael at 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/