This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author chris.jerdonek
Recipients chris.jerdonek, eric.smith
Date 2013-01-17.20:48:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
This wasn't just in the documentation.  It was the *first* example of how to use the choices argument out of the two examples in that section (from the time Python first adopted argparse and before):

---- choices
Some command-line arguments should be selected from a restricted set of values. These can be handled by passing a container object as the choices keyword argument to add_argument(). When the command line is parsed, argument values will be checked, and an error message will be displayed if the argument was not one of the acceptable values:

>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('foo', choices='abc')
>>> parser.parse_args('c'.split())
>>> parser.parse_args('X'.split())
usage: PROG [-h] {a,b,c}
PROG: error: argument foo: invalid choice: 'X' (choose from 'a', 'b', 'c')

(from )

So I think it's a bit late to say it's an inappropriate usage or bad practice.

To preserve backwards compatibility, I think we should use sequence iteration for strings, or equivalently apply "in" to iter(choices), set(choices), etc. when choices is a string.  I don't think, however, that we should alter the choices attribute because that could break things for people:

>>> p = argparse.ArgumentParser()
>>> a = p.add_argument("letter", choices='abcd')
>>> a.choices
Date User Action Args
2013-01-17 20:48:46chris.jerdoneksetrecipients: + chris.jerdonek, eric.smith
2013-01-17 20:48:46chris.jerdoneksetmessageid: <>
2013-01-17 20:48:46chris.jerdoneklinkissue16977 messages
2013-01-17 20:48:46chris.jerdonekcreate