[Python-Dev] argparse ambiguity handling

Eric Smith eric at trueblade.com
Wed Apr 21 09:53:16 CEST 2010


Cameron Simpson wrote:
> On 20Apr2010 15:27, Neal Becker <ndbecker2 at gmail.com> wrote:
> | Steven Bethard wrote:
> | 
> | > On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
> | >> I've noticed argparse ambiguity handling has changed a bit over last few
> | >> revisions.
> | >>
> | >> I have cases where 1 valid input is a prefix of another:
> | >>
> | >> e.g.:
> | >> '--string'
> | >> '--string2'
> | >>
> | >> With the most recent 1.1, the behavior is:
> | >>
> | >> --string=hello
> | >>
> | >> is accepted, while:
> | >>
> | >> --strin=hello
> | >>
> | >> is marked as ambiguous.
> | >>
> | >> I'm OK with this, but just want to know if there is agreement that this
> | >> is the behavior we want.
> | > 
> | > I don't have a strong feeling about this. What was the behavior before?
> | > Steve
> | 
> | At least 1 earlier version said that even exact match was ambiguous.
> | 
> | I have a preference to allow at least exact matches to succeed even in the 
> | case of ambiguity - mainly because I accidentally created this already once, 
> | and I feel it's better to at least work somewhat.  Not sure if there is any 
> | more elegant solution.  OTOH, I feel this is somewhat inelegant, as it 
> | appears to treat exact match as a special case.
> 
> I think the new behaviour is desirable. Plenty of commands have both
> --foo and --foo-tweak. Usually because --foo came first and --foo-tweak
> came later, or simply because --foo is the simple and obvious and
> commonly wanted mode and --foo-tweak is a special case.
> 
> Real world example: rsync and the --delete* options. I'm sure plenty of
> others can be found.
> 
> The new behaviour makes this doable. The old behaviour made it
> unimplementable. Maybe it is desirable to be _able_ to forbid this
> arguably-ambiguous option set, but I definitely feel that the current
> behaviour should be available.

I agree the new behavior is desirable. And I also think it should be the 
default, although I feel less strongly about that.

But since this behavior seems to be an accident of the implementation 
(based on Steve's comment above), I think a test should be added for it 
if it's accepted as a Good Thing (tm). Otherwise it's possible that it 
will vanish as the implementation changes.

Eric.


More information about the Python-Dev mailing list