Title: argparse arguments in main parser hide an argument in subparser
Type: enhancement Stage: needs patch
Components: Library (Lib) Versions: Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Alan Evangelista, eric.smith, paul.j3
Priority: normal Keywords:

Created on 2017-03-09 20:35 by Alan Evangelista, last changed 2017-03-16 21:00 by Alan Evangelista.

Messages (6)
msg289327 - (view) Author: Alan Evangelista (Alan Evangelista) Date: 2017-03-09 20:35
If you have a argument named --<prefix> in a subparser and two arguments named --<prefix><any_suffix)> in the main parser and call the Python executable with

python <> --<prefix>

argparse fails with:

error: ambiguous option: --<prefix> could match --<prefix><suffix1>, --<prefix><suffix2>

This probably happens due to how the argument abbreviation parsing is implemented. Is it possible to support disabling argument abbreviation in Python 2.7, as it is done in Python 3?
msg289328 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2017-03-09 21:34
No, we won't be adding new features to 2.7. Sorry.
msg289358 - (view) Author: Alan Evangelista (Alan Evangelista) Date: 2017-03-10 12:37
Adding the feature was just a workaround suggestion, but this is a bug. Arguments in the main parser should not "hide" an argument in a subparser in argument abbreviation.
msg289430 - (view) Author: paul j3 (paul.j3) * Date: 2017-03-11 02:50
allow_abbrev as added with

I contributed to the patch, but my memory isn't fresh.  The fact that this works across the subparser boundary is, in a sense, accidental.  We didn't think about how abbreviations are handled across this boundary.

The loop that matches flag strings with Action options ignores the subparser command.  It's just another positional argument.  So items that will later be parsed by the subparser are still being matched with the main parser's optionals.  If they don't trigger this abbreviation they will just be put in the unidentified category.

The patch is big enough that I hesitate to add it to Py2.  There's doesn't seem to be enough manpower to properly test this obscure corner of code.  Technically it was a feature addition, not a bug fix in 3.5.

'allow_abbrev=False' messes with the handling of short options:

In I suggest a subclassing patch that might work with Py2.

All the logic for handing subparsers is in the _SubParsersAction class.  'parse_args' really doesn't know anything about the concept. As a result, similarly named Actions in the main and subparsers is inherently a confusing issue. for example, changes how defaults are handled when there are matching Actions at both levels.

The simplest fix is to use different flags in the main parser and subparsers.
msg289732 - (view) Author: Alan Evangelista (Alan Evangelista) Date: 2017-03-16 20:59
PA> In I suggest a subclassing patch that might work with Py2.

This solves my particular case. I do not use any argument with action='count', so the regression introduced by the new option does not affect me. Thanks!

PA> The patch is big enough that I hesitate to add it to Py2.  

I see 2 solutions:
- keep this issue opened until the bug with short options is fixed and we are more confident in fixing this in Py2
- close the issue with "won't fix" resolution and add the known issue to argparse documentation in Python 2.6 doc
msg289734 - (view) Author: Alan Evangelista (Alan Evangelista) Date: 2017-03-16 21:00
s/Python 2.6/Python 2/ in last comment
Date User Action Args
2017-03-16 21:00:50Alan Evangelistasetmessages: + msg289734
2017-03-16 20:59:56Alan Evangelistasetmessages: + msg289732
2017-03-11 02:50:09paul.j3setmessages: + msg289430
2017-03-11 01:36:06paul.j3setnosy: + paul.j3
2017-03-10 13:16:59eric.smithsetresolution: rejected ->
stage: resolved -> needs patch
2017-03-10 12:37:20Alan Evangelistasetmessages: + msg289358
2017-03-09 21:34:55eric.smithsetnosy: + eric.smith
messages: + msg289328
resolution: rejected

type: enhancement
stage: resolved
2017-03-09 20:35:40Alan Evangelistacreate