Message89182
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. |
|
Date |
User |
Action |
Args |
2009-06-10 02:56:29 | bethard | set | recipients:
+ bethard, loewis, orsenthil, rickysarraf |
2009-06-10 02:56:29 | bethard | set | messageid: <1244602589.63.0.262646013963.issue6247@psf.upfronthosting.co.za> |
2009-06-10 02:56:28 | bethard | link | issue6247 messages |
2009-06-10 02:56:27 | bethard | create | |
|