[issue16468] argparse only supports iterable choices

[paul j3]

paul j3 added the comment:

chris.jerdonek wrote:
"Also, to answer a previous question, the three places in which the choices string is used are: in the usage string (separator=','), in the help string when expanding "%(choices)s" (separator=', '), and in the error message text (separator=', ' with repr() instead of str())."

In the usage string, the ',' is used to make a compact representation of the choices.  The ', ' separator is used in the help line, where space isn't as tight.  

This 'choices formatting' is called during 'add_argument()' simply as a side effect of checking for valid parameters, especially 'nargs' (that it, is an integer or an acceptable string).  Previously 'nargs' errors were not caught until 'parse_args' was used.   This is discussed in

http://bugs.python.org/issue9849  Argparse needs better error handling for nargs

http://bugs.python.org/issue16970  argparse: bad nargs value raises misleading message 

On the issue of what error type to raise, my understanding is that 'ArgumentError' is the preferred choice when it affects a particular argument.  parse_args() nearly always raises an ArgumentError.  Once add_argument has created an action, it too can raise an ArgumentError.  ArgumentError provides a standard way of identifying which action is giving the problem.
  
While testing 'metavar="range(0,20)"', I discovered that the usage formatter strips off parenthesis. A regex expression that removes 
excess 'mutually exclusive group' notation is responsible for this.  The simple fix is to modify the regex so it distinguishes between ' (...)' and 'range(...)'.  I intend to create a new issue for this, since it affects any metavar the includes ().

----------

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