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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4