[stdlib-sig] Breaking out the stdlib

[Michael Foord]

M.-A. Lemburg wrote:
> Michael Foord wrote:
>   
>> M.-A. Lemburg wrote:
>>     
>>> [snip...]
>>>       
>>>>> 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.
>>>   
>>>       
>> Here's an email from 2007 asking when it will be in the standard library:
>>
>> http://mail.python.org/pipermail/python-list/2007-January/592646.html
>>     
>
> I was looking at this page:
>
> http://code.google.com/p/argparse/downloads/list
>
> It turned 1.0 in July and the first release (on Google Code) was on
> April 1st this year.
>
> That doesn't say anything about the robustness of the code, but then:
> how much traction can you get in those few months and how likely are
> API changes to the code in a 1.1 or 2.0 release ?
>
>   
argparse has been available and in use in the community since at the 
*latest* 2006. As for API stability you will have to ask Steven.

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog