[Python-Dev] argparse ugliness

Xavier Morel python-dev at masklinn.net
Mon Mar 8 17:49:42 CET 2010

On 8 Mar 2010, at 16:53 , David Stanek wrote:
> On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>> In argparse, unlike optparse, actions are actually defined by objects
>> with a particular API, and the string is just a shorthand for
>> referring to that. So:
>>  parser.add_argument ('--plot', action='store_true')
>> is equivalent to:
>>  parser.add_argument('--plot', argparse._StoreTrueAction)
>> Because the names are so long and you'd have to import them, I've left
>> them as private attributes of the module, but if there's really
>> demand, we could rename them to argparse.StoreTrueAction, etc.
> Any reason not to do something like:
>  from argparse import actions
>  ...
>  parser.add_argument('--plot', actions.store_true)
> Basically a small namespace for the constants.

action is taken from **kwargs, not from a positional argument as *args
is a sequence of option strings (so you can write
 add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.

An option would be 


but I'm not sure this makes any sense API-wise, and it would probably make
the code a lot messier as the parser would have to reach into the action
to get the information it needs. Either that, or the action would be an *arg
and argparse would have to walk all of its *args type-testing each one to find
if there's an action anywhere.

More information about the Python-Dev mailing list