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 <rep...@bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
