Argparse looks promising, but it suffers from the same annoyance that optparse and others do: too much typing. For 90% of the cases when command line arguments are needed, something like this would work:

http://dpaste.com/31071/

The gist is it's easier to have a simple builder method that just takes a data array for all arguments, rather than forcing a API user to repetitively call add_argument on parser for each. All the existing methods could stay for the advanced usage, and then this could be an alternative.

Ooops, this shouldn't be an issue, just an enhancement. Sorry.

I'm not sure I see what this gains over simply rebinding "parser.add_argument" to something shorter, e.g.::

parser = argparse.ArgumentParser() a = parser.add_argument a('integers', metavar='int', type=int, choices=xrange(10), nargs='+', help='an integer in the range 0..9') a('--sum', dest='accumulate', action='store_const', const=sum, default=max, help='sum the integers (default: find the max)') args = parser.parse_args()

By my count, the above code is actually fewer characters than the version you posted.

You know, I think I saw you present a lightning talk at PyCon. IIRC you were practically begging people to come try your API. I tried it, and the first thing I thought was nearly the exact same thing you wrote above:

"Well, this looks like the same amount of typing and function calling I need with optparse. Why bother?"

In the end, it's all a matter of taste. I personally prefer smart data handed to dumb algorithms over complex functions with keyword arguments in varying forms. You like single character function names off complex rebindings.

Being it's your library, you should at least aim to make something like this part of the API, instead of stubbornly insisting that what you've written is actually better than the nearly same amount of code optparse requires.

Because, if there's not a times 10 multiplier in the simplicity of using your lib over optparse, then people like me will just use optparse.

The main point of the lightning talk was that argparse handles positional arguments, where optparse doesn't. Sorry that wasn't clear. If you only have optional arguments (flags), then in most cases I recommend you continue to use optparse, since it's already in the standard library and the functionality and APIs are extremely similar.

I'm sorry I came across as being stubborn in offering an alternative approach to declaring arguments. I was trying to address the concerns of your original issue which said the main problem with argparse was "too much typing", so providing code which required no more typing than your code seemed like a reasonable response. I'm sorry you felt that it wasn't.

If I understand you right now, your actual complaint is not about the amount of typing, but that you would prefer to define the parser through a nested dict object rather than through calls to add_argument(...), right?

I'm closing this bug since as was no response from the OP, there doesn't seem to be additional interest from other users, and the function that the OP suggests is only a few lines of code.