Negating options

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> Yes, I'd strongly prefer that it be '--no-reprocess' rather than '--no
> reprocess'.

Okay.

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

For options that take arguments, "--no-foo" might be equivalent to
"--foo ''".

> 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

Hmm.  I like [c] or maybe [b], but how about:
[d] as with [c], but also invert negative options, so that
- --no-reprocess implies --reprocess?

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

I like the way command definition works, too, and I don't mean to use
optparse there.

But optparse already supports various kinds of syntax that I want to
support, so I think it might make sense to use on the back end.

For example, the log options --short, --long, and --line really form an
enum.  That is, they're mutually exclusive and the last one should take
precedence over any others.  We could specify

    takes_options = [OptionEnum('logformat', 'line', 'long', 'short'), ...]

That would then cause the backend to do:
parser.add_option('--line', dest='logformat', action='store_const',
const='line')
parser.add_option('--long', dest='logformat', action='store_const',
const='long')
parser.add_option('--short', dest='logformat', action='store_const',
const='short')

Perhaps we should simply extend the current system, but option parsing
seems fiddly to get right, and not part of our core mission, so if we
can make optparse do our dirty work, that makes sense to me.  There are
also versions of optparse that support completion, though we'd have to
bundle them.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD52SR0F+nu1YWqI0RAnuKAJ9Bi8PFCcifJ+3tMwR8sAq0EH/7qgCffNl1
H5ao6Nu11ZYH8meqyISMFb4=
=S53m
-----END PGP SIGNATURE-----