You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
argparse: subparsers, argument abbreviations and ambiguous option #58573
The problem is basically that _parse_known_args calls _parse_optional to determine whether something is an optional or a positional. But _parse_optional only checks "if arg_string in self._option_string_actions", that is, if the string can be found in the main parser actions.
So either this method needs to check the subparser actions, or the "if arg_string in self._option_string_actions" stuff needs to be delayed until the subparser. Neither of these seems like a simple change, but I agree it's a bug.
jakub commented on Mar 19, 2012
jakubmannequin
MannequinAuthor
More actions
Attached quick&dirty fix I'm currently using in my project. Maybe this will help to create a valid patch.
Instead of changing _parse_optional, I've overridden _get_option_tuples to scan subparsers for matching optional arguments if option is ambiguous in the current parser.
I've only skimmed through the code, so forgive me if that fix is useless.
bethard commented on Jul 21, 2012
bethardmannequin
Mannequin
More actions
I think the real fix needs to search recursively though all subparsers. Here's a first draft of a patch that does this. I believe your sample code works after this patch.
I don't have the time to turn your bug report into proper test (and add a test for the recursive bit), but hopefully this is enough to let someone else finish up fixing this bug.
And yes, your "dirty hack" was still helpful in putting this together. ;-)
paulj3 commented on Sep 26, 2013
paulj3mannequin
Mannequin
More actions
Steven's patch (subparse_optionals.diff) run with jakub's test case (argparse_subparses_ambiguous_bug.py) works. But if the input string is
'--foo' is being parsed even though its subparser is not invoked,
and the subparser is not required.
The issue of whether subparsers are required or not is another issue. They used to be required, but the testing for 'required' was changed, and subparsers fell through the crack.
I suspect that if the missing subparser error were raised, the first issue wouldn't be apparent.
paulj3 commented on Sep 28, 2013
paulj3mannequin
Mannequin
More actions
I think the correction to the problem that I noted in the previous post is to return 'None, arg_string, None', rather than 'action, arg_string, None' in the case where the action is found in a subparser.
This is what '_parse_optional' does at the end:
# it was meant to be an optional but there is no such option# in this parser (though it might be a valid option in a subparser)returnNone, arg_string, None
An input like '--foo baz' would then produce an 'invalid choice' error. Since '--foo' is an optional that the primary parser does not recognize, 'baz' in interpreted as a positional, in this case an invalid subparser choice.
Activity
jakub commentedon Mar 18, 2012
Assuming following:
parsing fails with "error: ambiguous option: --foo could match --foo1, --foo2".
It seems like argument abbreviation mechanism described at http://docs.python.org/library/argparse.html#argument-abbreviations is not working properly when in use with subparsers...
tshepang commentedon Mar 18, 2012
More or less a duplicate of 12713?
tshepang commentedon Mar 18, 2012
Sorry, I meant bpo-12713.
bethard commentedon Mar 18, 2012
Yep. Closing as duplicate.
jakub commentedon Mar 19, 2012
I don't understand how both bugs are related. Surely, patch provided for bpo-12713 does not fix the issue I described.
bethard commentedon Mar 19, 2012
My mistake. I see that the error you're getting is a bad interaction between the option in the main parser and an ambiguous option in the subparser.
bethard commentedon Mar 19, 2012
The problem is basically that _parse_known_args calls _parse_optional to determine whether something is an optional or a positional. But _parse_optional only checks "if arg_string in self._option_string_actions", that is, if the string can be found in the main parser actions.
So either this method needs to check the subparser actions, or the "if arg_string in self._option_string_actions" stuff needs to be delayed until the subparser. Neither of these seems like a simple change, but I agree it's a bug.
jakub commentedon Mar 19, 2012
Attached quick&dirty fix I'm currently using in my project. Maybe this will help to create a valid patch.
Instead of changing _parse_optional, I've overridden _get_option_tuples to scan subparsers for matching optional arguments if option is ambiguous in the current parser.
I've only skimmed through the code, so forgive me if that fix is useless.
bethard commentedon Jul 21, 2012
I think the real fix needs to search recursively though all subparsers. Here's a first draft of a patch that does this. I believe your sample code works after this patch.
I don't have the time to turn your bug report into proper test (and add a test for the recursive bit), but hopefully this is enough to let someone else finish up fixing this bug.
And yes, your "dirty hack" was still helpful in putting this together. ;-)
paulj3 commentedon Sep 26, 2013
Steven's patch (subparse_optionals.diff) run with jakub's test case (argparse_subparses_ambiguous_bug.py) works. But if the input string is
produces
(I added the 'cmd' subparse 'dest').
Two things seem to be going on now:
'--foo' is being parsed even though its subparser is not invoked,
and the subparser is not required.
The issue of whether subparsers are required or not is another issue. They used to be required, but the testing for 'required' was changed, and subparsers fell through the crack.
I suspect that if the missing subparser error were raised, the first issue wouldn't be apparent.
paulj3 commentedon Sep 28, 2013
I think the correction to the problem that I noted in the previous post is to return 'None, arg_string, None', rather than 'action, arg_string, None' in the case where the action is found in a subparser.
This is what '_parse_optional' does at the end:
An input like '--foo baz' would then produce an 'invalid choice' error. Since '--foo' is an optional that the primary parser does not recognize, 'baz' in interpreted as a positional, in this case an invalid subparser choice.
I'm working on cleaning up a test script.
18 remaining items
[3.12] gh-58573: Fix conflicts between abbreviated long options in th…
options: adjust to behavior change in upstream _parse_optional
options: adjust to behavior change in upstream _parse_optional
options: adjust to behavior change in upstream _parse_optional
options: adjust to behavior change in upstream _parse_optional
options: adjust to behavior change in upstream _parse_optional
[3.13] gh-58573: Fix conflicts between abbreviated long options in th…
pythongh-125254: Fix error report about ambiguous option in argparse
gh-125254: Fix error report about ambiguous option in argparse (GH-12…
pythongh-125254: Fix error report about ambiguous option in argparse (p…
pythongh-125254: Fix error report about ambiguous option in argparse (p…
[3.12] gh-125254: Fix error report about ambiguous option in argparse (…
[3.13] gh-125254: Fix error report about ambiguous option in argparse (…