Negating options

[Martin Pool]

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.

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

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060206/3741b291/attachment.pgp