[issue12713] argparse: allow abbreviation of sub commands by users

[paul j3]

paul j3 added the comment:

I haven't read the discussion in full, but it looks like this patch was added without any recent discussion or testing.

Previously if we had `choices=['a','abc']`, any exact match would be accepted, and partial matches rejected.  With this change the only choice that will work is the longest, 'abc'.  The other will be rejected as ambiguous.

In contrast with optionals flags, an exact match has priority over (possibly ambiguous) abbreviations.  See parser._parse_optional

I also noticed when testing this that for regular 'choices', the abbreviated string is put in the Namespace.  

     add_argument('--foo', choices = ['one','two'])

can produce `Namespace(foo='on')`.  I suspect most developers would want `Namespace(foo='one')`, regardless of whether it was an exact match or partial.  You don't list choices if you are ok with partial matches.

This isn't a problem with `subparsers`, since an abbreviation match still invokes the right subparser, and even puts the right name in 'subparsers' dest.  But for regular choices the behavior is highly debatable.

This needs to be reverted.  It may be fixable, but it needs more testing and discussion.  For now it's an enhancement that is causing backward compatibility problems.

ps

I missed this issue when I made an effort to find all argparse issues several years ago.  I contributed to https://bugs.python.org/issue14365, the other abbreviations issue mentioned in the recent github thread.

----------
keywords: +needs review -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________