Negating options

[John A Meinel]

Martin Pool wrote:
> On  4 Feb 2006, Denys Duchier <duchier at ps.uni-sb.de> wrote:
>> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>>
>>> Now that command defaults are on the horizon, (or 'here' in my case)
>>> it's usefult to be able to negate boolean options.  I was thinking we
>>> could make '--no' be a special option that would negate the option
>>> following, like:
>>>
>>> $ bzr revert --no reprocess --merge-type weave
>> The GNU convention is that the negation of --foo is --no-foo
> 
> Yes, I'd strongly prefer that it be '--no-reprocess' rather than '--no
> reprocess'.
> 
> In many other programs, negative options only apply to options without
> arguments that are either present or not.  In that pattern, it would not
> make sense to say --no-message.  (But then, that does sound like a
> useful option.)
> 
> Rather than duplicating the options by hand it might be nice to change
> the Option class to allow inversion systematically.  There are a few
> options (as you might say):
> 
>  [a] allow --no for Options that specifically say they can be inverted
> 
>  [b] allow --no to be prefixed to just any option, even if it does nothing
> 
>  [c] allow --no to be prefixed to any boolean option whose default is 
>      True, or others where it's specifically allowed
> 
> One nice thing about [c] is that we can show the --no options in the
> help message for these cases; you could optionally give a different help
> message for the negative case.

I like [c], except I would want it available always to any boolean option.

Because with default arguments, you might end up with:

[DEFAULT]
commit = --strict

Which turns on always strict. But then you just want to commit this one
time.

bzr commit --no-strict

I really think that all boolean options should allow negation. Simply
because then users can change what they want the *default* behavior to
be, and still override them with command line arguments.

I wrote a configuration and command line parser which hooked into
optparse to allow options to be specified as a config section, as well
as a command line parser. And then it used the resolution of "global
config, local config, command line" to figure out what the actual value was.

It works pretty well, but it is a little involved for bzr. (The backend
was written in C++ (boost regexes), so that I could use it from both
pure C++ apps, and python apps).

Anyway, just to say that it is important that if you are going to have a
boolean flag settable by configuration, you really want a way to
override it. (It also works for command line arguments, because you can
alias rm='rm -i'; and then on the command line use "rm -f" to override).

John
=:->

> 
>> Yes.  I suggested it too a while ago and I remember pointing out that
>> OptionParser.allow_interspersed_args=false allows us to do option parsing in
>> several phases and thus stack command parsers, but I cannot find that email
>> anywhere in the archive.  I wanted this to stack parsers for global options and
>> command-specific options (thus allowing options to be freely mixed on the
>> command line) and I think it was you who pointed out that --no-plugins could not
>> be handled in that fashion and would need to be an exception.
>>
>> Anyway, +1 from me on using optparse, if that counts.
> 
> I quite like the way options and arguments are defined on Commands and
> it seemed to me that using optparse would require more complexity than
> just doing this ourselves.  But if that's wrong and optparse would
> either simplify the code or enable new features I'm ok to change to it.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060206/7dc587c8/attachment.pgp