[New-bugs-announce] [issue18467] argparse - problematic 'default' behavior

[Matěj Týč]

New submission from Matěj Týč:

I have an issue with passing default values to arguments.
Basically, I would like to have a 'choices' argument (indicating something using capital letters) and perform custom action (adding boolean values to the args namespace).
See the bottom of this post for rationale.

According to the documentation ( http://docs.python.org/2.7/library/argparse.html#default ),
...
If the default value is a string, the parser parses the value as if it were a command-line argument.
...

If this was true, I could implement a custom action. However, even if the default value is a string (as the documentation suggests), the action is bypassed.

My goal is simple - I want to allow short choice-type argument (such as something.py --algorithm Q, the help would say --algorithhm Q|S, Q is quick, S is slow). Since the implementation shouldn't know about the mean one is communicating with the user, I would like to have the 'args' namespace either like (type='Q', quick=True, slow=False) or (type='quick') without giving up usage of the 'choices' pattern.

If I change my mind and add a 'type' function that would expand capital letters abbreviations to full names, I will be OK with default values.
However, if I pass the argument on the command-line, the type() call is performed first and the query whether the result is in the choices list fails.

I consider the current behavior as a bug, IMO the action shouldn't be bypassed if the "default" is string.

----------
components: Library (Lib)
messages: 193135
nosy: matej.tyc
priority: normal
severity: normal
status: open
title: argparse - problematic 'default' behavior
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18467>
_______________________________________