[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

paul j3 added the comment: Another issue dealing with abbreviations is close to being committed. http://bugs.python.org/issue14910 argparse: disable abbreviation -- ___ Python tracker _

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

paul j3 added the comment: This the argparse patch as described in the previous post, along with test_argparse tests. For now the tests handle both subparser required cases and not required ones ( http://bugs.python.org/issue9253 ). While error messages can differ based on this requirement

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Changes by paul j3 : Removed file: http://bugs.python.org/file31888/subparser_patch.diff ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

paul j3 added the comment: In the last patch, 'parser.scan = True' is needed to activate this fix. I left that switch in for testing convenience. -- ___ Python tracker ___

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

paul j3 added the comment: 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 w

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

paul j3 added the comment: Steven's patch (subparse_optionals.diff) run with jakub's test case (argparse_subparses_ambiguous_bug.py) works. But if the input string is print(parser.parse_args('--foo baz'.split())) produces Namespace(cmd=None, foo='baz', foo1=None, foo2=None) (I adde

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Changes by paul j3 : -- nosy: +paul.j3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Steven Bethard added the comment: 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

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Changes by Éric Araujo : -- nosy: +eric.araujo stage: -> test needed versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-lis

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Jakub Warmuz added the comment: 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 c

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Steven Bethard added the comment: 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 mai

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Steven Bethard added the comment: 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. -- resolution: duplicate -> status: closed -> open superseder: argparse: allow abbreviation of sub com

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Jakub Warmuz added the comment: I don't understand how both bugs are related. Surely, patch provided for #12713 does not fix the issue I described. -- ___ Python tracker ___ __

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Steven Bethard added the comment: Yep. Closing as duplicate. -- resolution: -> duplicate status: open -> closed superseder: -> argparse: allow abbreviation of sub commands by users ___ Python tracker ___

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Tshepang Lekhonkhobe added the comment: Sorry, I meant #12713. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Tshepang Lekhonkhobe added the comment: More or less a duplicate of 12713? -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

Changes by Tshepang Lekhonkhobe : -- nosy: +tshepang ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue14365] argparse: subparsers, argument abbreviations and ambiguous option

New submission from Jakub Warmuz : Assuming following: 1. optional argument, say "--foo", in a subparser; 2. at least two different optional arguments in the main parser prefixed with "--foo", say "--foo1" and "--foo2"; parsing fails with "error: ambiguous option: --foo could match --foo1, --fo