Suggestion for a single API function to reduce the amount of typing needed.

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by zed.s...@gmail.com on 10 Apr 2009 at 4:41

[GoogleCodeExporter]

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

Original comment by zed.s...@gmail.com on 10 Apr 2009 at 4:42

[GoogleCodeExporter]

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.

Original comment by steven.b...@gmail.com on 10 Apr 2009 at 9:30

[GoogleCodeExporter]

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.

Original comment by zed.s...@gmail.com on 23 Apr 2009 at 11:04

[GoogleCodeExporter]

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?

Original comment by steven.b...@gmail.com on 23 Apr 2009 at 11:52

[GoogleCodeExporter]

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.

Original comment by steven.b...@gmail.com on 22 May 2009 at 4:06

• Changed state: WontFix