[From python-dev: http://mail.python.org/pipermail/python-dev/2012-September/121683.html ]

> I've tried the various suggestions out, and I think from a practical point of
view, a fix for the regression in the 2.7, 3.2 and 3.3 branches should be to
apply the one line check for action being a _StoreAction instance.  This seems
to be the easiest way to preserve the current behavior (the fix for issues
#12776 and #11839) and fix issue #15906.  I'll update the issue and apply this change to the three branches.

This change doesn't seem right to me.  It also seems like it may cause other regressions.

The argparse documentation makes it pretty clear that 'type' is meant to be applied only to strings.

Also, the parse_args() documentation says, "Convert argument strings to objects and assign them as attributes of the namespace," but it doesn't say anything about also converting non-string defaults.

Thirdly, the documentation for the "default" keyword argument says, "The default keyword argument of add_argument(), whose value defaults to None, specifies what value should be used if the command-line argument is not present."  It doesn't say that the value should be converted before being used.

Also, here is what the change does from a behavior perspective for a couple test cases (compared to some other points in time):

parser = ArgumentParser()
parser.add_argument("--test", dest="test", action='store', type=str, default=False)
args = parser.parse_args()
print(repr(args.test))

to_str = lambda s: s.lower()

parser = ArgumentParser()
parser.add_argument("--test", dest="test", action='store', type=to_str, default=False)
args = parser.parse_args()
print(repr(args.test))

2.7.3: 
False
False

Python 3.3 (815b88454e3e; before issue 12776 patch):
False
False

Python 3.3.0rc2+:
'False'
Traceback (most recent call last):
  ...
AttributeError: 'bool' object has no attribute 'lower'

Python 3.3.0rc2+15906-1.diff:
'False'
Traceback (most recent call last):
  ...
AttributeError: 'bool' object has no attribute 'lower'

So with the change, code that previously didn't raise an error will now raise an AttributeError.  In other words, it seems like the change imposes restrictions on what default values are allowed relative to the 'type' callable where such restrictions didn't exist before.