On Sep 15, 2009, at 1:44 AM, Michael Foord wrote:
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.
Please, the suggestion for adding argparse has nothing to do with
Jesse's suggestion of splitting the stdlib and making sure the stdlib
modules are top-notch. Let's keep the discussion on topic.
Orestis
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
