A line like this:

    parser.add_argument('--hello', action="store_true", type=bool)

causes a TypeError in 2.7 and 3.4:

   File "/usr/lib/python3.4/argparse.py", line 1344, in add_argument
     action = action_class(**kwargs)

     TypeError: __init__() got an unexpected keyword argument 'type'

It shouldn't really.

Looking at the source it appears that there are many actions for which it is not legal to also specify type.  That is, this looks like a design decision rather than a bug.

Right, the only arguments that a `store_true` Action class accepts are:

     option_strings, dest, default=False,required=False, help=None

parser.add_argument() massages its parameters a bit, and then uses the 'action' parameter to construct an Action subclass object with the other parameters.  Depending on their needs the subclasses may set various defaults or omit certain parameters. And without a catchall '**kwargs', the result of providing an omitted parameter is this error message.

For 'store_true', a 'type' parameter is superfluous.  It doesn't take any arguments (it sets 'nargs=0'), so there aren't any arguments to convert with the 'type' function.  It's the Action's own 'default' and 'const' that provide the required False and True values.

Also 'bool' is not a meaningful 'type' - for any Action class.  There isn't a function in Python converts a string to a boolean.  'bool()' does not do this.  Or rather, `bool(astr)' converts every string to True except the empty one.

I've seen this mistake before, assuming that 'type=bool' means 'I want the result to be a boolean'.  But the docs do say 

    type= can take any callable that takes a single string argument and returns the converted value:

'type=float' means 'use float(astr) to convert astr', not 'the argument should be a float'.

The documentation is not clear about what parameters are valid for each Action type.  It indicates, in bits and pieces, that some parameters are meaningful for certain actions, and not useful for others.  One (version) even takes a parameter that others don't.  But I haven't seen many bugs - here or on StackOverflow - where this is an issue.

Thanks paul.j3 and r.david.murray,

I see your points.

What led me to this was automatically generating command line options from a Gstreamer element, mapping
the Gstreamer property types to Python types. Then I special-cased the action="store_true" for the boolean ones and was surprised by the somewhat unclear error message.

As you suggest, paul.j3, "type" is in some ways an unfortunate choice of keyword for this, but it too late to change that.

Although I agree that specifying type with store_true or store_false is unnecessary, this shouldn't really be an error like this. Why not just ignore type if it can't be utilized?

The error message implies the usage of add_argument is erroneous, however it is fully compatible with the spec give in the docs.

Alternatively, the docs should be updated.

See issue25299 also.