Chris Jerdonek added the comment:
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):
----
16.4.3.7. 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())
Namespace(foo='c')
>>> parser.parse_args('X'.split())
usage: PROG [-h] {a,b,c}
PROG: error: argument foo: invalid choice: 'X' (choose from 'a', 'b', 'c')
(from
http://hg.python.org/cpython/file/c0ddae67f4df/Doc/library/argparse.rst#l1021 )
----
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
'abcd'
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16977>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
