[issue16468] argparse only supports iterable choices

Raymond Hettinger added the comment: New changeset 0d45d50e421b46b56195821580c3760b43813106 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-16468: Clarify which objects can be passed to "choices" in argparse (GH-15566) (GH-15587)

[issue16468] argparse only supports iterable choices

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 ___ Python tracker ___

[issue16468] argparse only supports iterable choices

Change by miss-islington : -- pull_requests: +15263 pull_request: https://github.com/python/cpython/pull/15587 ___ Python tracker ___

[issue16468] argparse only supports iterable choices

Raymond Hettinger added the comment: New changeset 84125fed2a45a9e454d7e870d8bbaf6ece3d41e8 by Raymond Hettinger in branch 'master': bpo-16468: Clarify which objects can be passed to "choices" in argparse (GH-15566)

[issue16468] argparse only supports iterable choices

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +15242 pull_request: https://github.com/python/cpython/pull/15566 ___ Python tracker ___

[issue16468] argparse only supports iterable choices

Change by Raymond Hettinger : -- keywords: +newcomer friendly -patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue16468] argparse only supports iterable choices

Raymond Hettinger added the comment: Okay, that makes sense. Go ahead with the edit. -- ___ Python tracker ___ ___

[issue16468] argparse only supports iterable choices

Brendan Barnwell added the comment: Here is an example of someone who cares about the behavior and/or the documentation (and still cares enough to check up on their StackOverflow question six years later):

[issue16468] argparse only supports iterable choices

Raymond Hettinger added the comment: I think this should be dropped. IMO it is a pedantic nit. There is the everyday usage of the word "container" which has a reasonable plain meaning. There is also an ABC that was unfortunately called Container (with a capital C) that means anything the

[issue16468] argparse only supports iterable choices

paul j3 added the comment: But see https://bugs.python.org/issue37793 for a discussion of whether 'container' is as good a descriptor as 'iterable'. -- ___ Python tracker

[issue16468] argparse only supports iterable choices

Change by Joannah Nanjekye : -- nosy: +nanjekyejoannah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16468] argparse only supports iterable choices

Brendan Barnwell added the comment: This issue has sat idle for six years. Meanwhile, the docs are still incorrect, giving every user wrong information about how the module works. Can we consider just changing the documentation instead of worrying about what the behavior should be or what

[issue16468] argparse only supports iterable choices

Brendan Barnwell added the comment: https://bugs.python.org/issue16468 -- nosy: +BrenBarn versions: +Python 3.7 ___ Python tracker ___

[issue16468] argparse only supports iterable choices

Change by sebix : -- nosy: +sebix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16468] argparse only supports iterable choices

Changes by Berker Peksag : -- nosy: +berker.peksag versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4 ___ Python tracker

[issue16468] argparse only supports iterable choices

Changes by Masato HASHIMOTO cabezon.hashim...@gmail.com: -- nosy: +hashimo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___

[issue16468] argparse only supports iterable choices

paul j3 added the comment: I just submitted a patch to http://bugs.python.org/issue11874 which rewrites _format_actions_usage(). It now formats the groups and actions directly, keeping a list of these parts. It no longer has to cleanup or split a usage line into parts. So it is not

[issue16468] argparse only supports iterable choices

paul j3 added the comment: This patch generally deals with the choices option, and specifically the problems with formatting long lists, or objects that have __contains__ but not __iter__. But it also incorporates issues 9849 (better add_argument testing) and 9625 (choices with *). It may be

[issue16468] argparse only supports iterable choices

paul j3 added the comment: I'd suggest not worrying about the default metavar in the _expand_help() method. The formatted choice string created in that method is only used if the help line includes a '%(choices)s' string. The programmer can easily omit that if he isn't happy with the

[issue16468] argparse only supports iterable choices

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=', '

[issue16468] argparse only supports iterable choices

Changes by paul j3 ajipa...@gmail.com: -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list mailing list

[issue16468] argparse only supports iterable choices

Changes by Radu Ciorba raducio...@gmail.com: -- nosy: +Radu.Ciorba ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list

[issue16468] argparse only supports iterable choices

Terry J. Reedy added the comment: I think we have converged on the right solution. The patch looks good as far as it goes, assuming that it passes the current + unwritten new tests. It will also be a good basis for reconsidering what to do with long/infinite iterables in #16418. I think the

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: the choice part of the error message (passed to ArgumentError) will just be 'invalid choice: value'. That's right. With the patch it looks like this: p = argparse.ArgumentParser(prog='test.py') p.add_argument('--foo', choices=c) p.parse_args(['--foo',

[issue16468] argparse only supports iterable choices

Terry J. Reedy added the comment: If you can somewhat solve the problem by better using the existing api, good. I am not 'stuck' on reusing str/repr*. If metavar is non-optional for non-iterable choices, the doc should say so in the entry for choices. (Does the test suite already have a

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Here is a patch for discussion that allows non-iterable choices with or without metavar. It refactors as suggested. However, the patch does not yet have tests. Does the test suite already have a testcase already for non-iterable choices + metavar? No,

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: I have a new suggestion that I hope will satisfy Terry. After looking at the code more, I noticed that add_argument() does currently work for non-iterable choices provided that metavar is passed. This was also noted in the report for the duplicate issue

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Actually, let me relax (1). We can just use what the argparse code calls the default_metavar in that case (which it constructs from the argument name). The important thing for me is not displaying the str/repr when it might not be intended. --

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Adding a failing test. I will supply a patch shortly. -- keywords: +patch stage: - needs patch Added file: http://bugs.python.org/file28731/issue-16468-1.patch ___ Python tracker rep...@bugs.python.org

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Attaching patch. With this patch, passing a non-iterable choices argument to parser.add_argument() raises (for example): Traceback (most recent call last): ... File .../Lib/argparse.py, line 558, in _metavar_formatter choice_strs = [str(choice) for

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Slight doc tweak: s/container/sequence/. -- Added file: http://bugs.python.org/file28735/issue-16468-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468

[issue16468] argparse only supports iterable choices

R. David Murray added the comment: Since the line between a type error and a value error is fuzzy anyway, I'd be in favor of maintaining the backward compatibility here. We don't consider exception message content part of the API (though we do occasionally work to preserve it when we know

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Sounds fine. Does that mean a test should still be added for the message? I was never clear on this because on the one hand we want to be sure we use the right message (and that we're actually fixing the issue), but on the other hand we don't want the

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: I guess another option would be to mark the test CPython-only. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___

[issue16468] argparse only supports iterable choices

R. David Murray added the comment: CPython only would not be appropriate, as it is not. What I usually do in such cases is use AssertRaisesRegex looking for some critical part of the message that represents the functionality we are looking for rather than the exact text. In this case, it

[issue16468] argparse only supports iterable choices

Terry J. Reedy added the comment: The exception question is messy, but I think it is the wrong question. The doc is correct in that it says what the code should be doing. To test whether an argument is in a collection of choices, the code should just say that: 'arg in choices' (as far as I

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: I don't disagree that this feature could be useful. I'm just not sure it should go into a maintenance release. It feels like an enhancement to me because to use this feature, the user will have to use the API in a way they haven't before, and we will

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: Note that we would also have to deal with not just the error text but also the usage string. From the docs: parser.parse_args('11'.split()) usage: PROG [-h] {5,6,7,8,9} PROG: error: argument foo: invalid choice: 11 (choose from 5, 6, 7, 8, 9) --

[issue16468] argparse only supports iterable choices

Terry J. Reedy added the comment: I took a good look at the 3.3 code. With respect to the main purpose of choices -- checking user input -- argparse does not require that choices be iterable, as it *does* use 'in', as it should. Line 2274: if action.choices is not None and value not

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: argparse does not require that choices be iterable, as it *does* use 'in', as it should. Line 2274: if action.choices is not None and value not in action.choices: There are cases where it's incorrect for argparse to being using in instead of

[issue16468] argparse only supports iterable choices

Terry J. Reedy added the comment: _Actions_container(object) [1198 in 3.3.0 code] .add_argument() [1281] does not directly check for choices.__iter__ ('__iter__' is not in the file). Nor does it use the 3.x-only alternative isinstance(choices, collections) ('Iterable' is also not in the

[issue16468] argparse only supports iterable choices

Changes by wim glenn wim.gl...@gmail.com: -- nosy: -wim.glenn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list

[issue16468] argparse only supports iterable choices

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +wim.glenn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list

[issue16468] argparse only supports iterable choices

Chris Jerdonek added the comment: For the record, choices types implementing only __contains__ never worked in any cases. (I should have said ArgumentParser.add_argument() raises a ValueError in the above.) So I wonder if we should classify this as an enhancement and simply document the

[issue16468] argparse only supports iterable choices

Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +bethard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list mailing

[issue16468] argparse only supports iterable choices

Terry J. Reedy added the comment: If the assumption of iterability is in more than just the help and error messages, then I can see the point of calling this an enhancement. I suspect that now, if a custom subset of ints or strings is the actual domain, people just skip choices and add custom

[issue16468] argparse only supports iterable choices

New submission from Chris Jerdonek: This issue is to ensure that argparse.ArgumentParser() accepts objects that support the in operator for the choices argument to ArgumentParser.add_argument(). As observed by Terry in the comments to issue 16418: http://bugs.python.org/issue16418#msg175520