[issue18467] argparse - problematic 'default' behavior
paul j3
report at bugs.python.org
Wed Jul 17 05:17:51 CEST 2013
paul j3 added the comment:
I think this example illustrates your issue:
class FooAction(argparse.Action):
def __call__(self, parser, namespace, values,
option_string = None):
if values=='Q':
setattr(namespace, self.dest,
{'type':values, 'quick':True, 'slow':False})
else:
setattr(namespace, self.dest,
{'type':values, 'quick':False, 'slow':True})
def bar(string):
return string.upper()[0]
parser = argparse.ArgumentParser()
parser.add_argument('-a','--algorithm', choices=['Q','S'],
default='s', action=FooAction, type=bar)
parser.add_argument('foo', choices=['Q','S'],
default='s', action=FooAction, nargs='?', type=bar)
print(parser.parse_args([]))
# Namespace(algorithm='S',
# foo={'slow': True, 'type': 'S', 'quick': False})
For both the optional and positional, the lower case default is converted into an upper case letter.
For the positional with nargs='?', the action is called with the converted default value.
But for the optional, the converted default is assigned to the dest
algorithm='S'
but action is not called, which would have assigned
algorithm={'type': 'S', 'quick': False, 'slow': True}
That is consistent with what I remember from the code. A next function 'take_action' is called only if there is an appropriate argument string. For this optional that would be '-a' (or the likes). For the '?' positional and empty argument list enough.
There is a relatively recent change that delayed when a default was converted by type (so a filetype wouldn't be opened unnecessarily). But I can't think anyway that the action would be invoked on the default in the absence of '-a'.
In this example, would it be possible shift code from the custom action to the custom type?
----------
Added file: http://bugs.python.org/file30944/issue18467.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18467>
_______________________________________
More information about the Python-bugs-list
mailing list