[RFC] use optparse for option handling

[Martin Pool]

On 12 Jul 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Here's a bundle that uses optparse as a backend.

Well, it certainly has a nice diffstat ratio :-)

Aside from being smaller do you think it's cleaner this way?

I don't think it's urgent enough for 0.9.

I would like to check that the import cost is not too significant.

> This gets us out of the option-parsing business, and it also clears the
> way for using advanced optparse features.
> 
> We need enumerations-- that is, flags that set the same variable to
> different values.  Log formats and merge types should be handled that
> way.  It might also be nice to have -v increase the verbosity level.

Also, we want --no-foo to set the inverse of --foo.  I think having
repeated options generally just take the last value, but have the
option to do other things would work well with aliases.  Erroring out is
not so useful.

> I really like our frontend-- I find it much nicer to use than doing
> optparse directly.  (Bugs Everywhere does that, and it's a PITA.  I
> guess optparse is fine if you don't have lots of subcommands.)

Yes, I agree.

> There is one behaviour change: it's now legal to specify the same option
> multiple times (the last value is used).

+1 - though I think particular options will want to override that, e.g.
-v

> 
> Optparse wants to determine the 'final value' of options by filling in
> defaults, but we want to let command defaults determine that, so we use
> a unique default value, and filter out options assigned to that value.
> 
> (btw, is there a way to prevent that string from being interned?  I
> don't want false negatives from
> "if v is not OptionParser.DEFAULT_VALUE")

Not reliaably.  The typical thing would be to make it an instance of
some non-string class -- just an instance of object() would do.  (I
thought that symbol_versioning did this, but apparently not.)

-- 
Martin