This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bethard
Recipients bethard, loewis, orsenthil, rickysarraf
Date 2009-06-10.02:56:27
SpamBayes Score 2.724454e-10
Marked as misclassified No
Message-id <1244602589.63.0.262646013963.issue6247@psf.upfronthosting.co.za>
In-reply-to
Content
I'm happy to contribute argparse to the standard library and volunteer
to maintain it.

For what it's worth, I don't agree that there are already too many
argument parsing libraries in the standard library. I do agree that
there are already too many *option* parsing libraries. But both getopt
and optparse don't know how to parse positional arguments at all. For
example, if your program usage looks like:

    prog eggs [spam] [baz [baz [...]]]

then getopt and optparse are worthless to you - they'll just return
sys.argv[1:] since there are no options. The argparse module, on the
other hand, can correctly parse out "eggs", "spam" and the "baz" list
into appropriate attributes (in addition to doing all the other stuff
that optparse does).

I also don't think there's much of a chance of optparse ever growing
most of the argparse features. When I started argpasre, my goal was
exactly that - to keep the module fully backwards compatible with
optparse and just to add the missing features. The optparse code just
wasn't written in a way that allowed me to do that. In particular, the
optparse extension API is horribly designed, and exposes so many
internals of optparse that it's nearly impossible to add any new
features to optparse without breaking this.
History
Date User Action Args
2009-06-10 02:56:29bethardsetrecipients: + bethard, loewis, orsenthil, rickysarraf
2009-06-10 02:56:29bethardsetmessageid: <1244602589.63.0.262646013963.issue6247@psf.upfronthosting.co.za>
2009-06-10 02:56:28bethardlinkissue6247 messages
2009-06-10 02:56:27bethardcreate