paul j3 added the comment: allow_abbrev as added with http://bugs.python.org/issue14910
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: http://bugs.python.org/issue26967 In http://bugs.python.org/issue14910#msg204678 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. http://bugs.python.org/issue9351 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29777> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
