Mailman 3 argparse ambiguity handling - Python-Dev

argparse ambiguity handling

older
Small suggestion re help(Exception)

Neal Becker

20 Apr 2010 20 Apr '10

6:55 p.m.

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.

Show replies by date

Steven Bethard

20 Apr 20 Apr

7:10 p.m.

On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker 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 -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

Neal Becker

7:27 p.m.

Steven Bethard wrote:

...

On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker 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.

P.J. Eby

7:48 p.m.

At 03:27 PM 4/20/2010 -0400, Neal Becker wrote:

...

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.

How about throwing an error the moment you define a set of options that create this potential ambiguity? ;-) (i.e. force you to define --string1 and --string2 instead of --string and --string2) (Either that, or have an option to turn off ambiguous guessing, and throw the error unless you've turned it off.)

Jon Ribbens

7:54 p.m.

On Tue, Apr 20, 2010 at 03:27:53PM -0400, Neal Becker wrote:

...

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.

Surely an exact match *is* a special case - it's an exact match!

Cameron Simpson

21 Apr 21 Apr

2:11 a.m.

On 20Apr2010 15:27, Neal Becker wrote: | Steven Bethard wrote: | | > On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker 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. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ If it wasn't for lawyers, we wouldn't need them.

Eric Smith

7:53 a.m.

Cameron Simpson wrote:

...

On 20Apr2010 15:27, Neal Becker wrote: | Steven Bethard wrote: | | > On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker 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.

Jon Ribbens

9:14 a.m.

On Wed, Apr 21, 2010 at 03:53:16AM -0400, Eric Smith wrote:

...

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.

+1 to all of that

Steven Bethard

4:33 p.m.

On Wed, Apr 21, 2010 at 2:14 AM, Jon Ribbens wrote:

...

On Wed, Apr 21, 2010 at 03:53:16AM -0400, Eric Smith wrote:

...
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.

+1 to all of that

Turns out I actually fixed this on purpose in r79 of argparse, and even added a test (TestOptionalsDoubleDashPrefixMatch) to test this behavior. So also +1 from me as well since I've already done it. ;-) Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

5118

Age (days ago)

5119

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Cameron Simpson
Eric Smith
Jon Ribbens
Neal Becker
P.J. Eby
Steven Bethard

argparse ambiguity handling

Neal Becker

Steven Bethard

Neal Becker

P.J. Eby

Jon Ribbens

Cameron Simpson

Eric Smith

Jon Ribbens

Steven Bethard

tags

participants (6)