[RFC] use optparse for option handling

Aaron Bentley aaron.bentley at utoronto.ca
Thu Jul 13 04:19:24 BST 2006


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

Martin Pool wrote:
> 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?

Well, I think the details of command-option parsing is a problem space
not really worthy of our attention.  Optparse handles '-' properly, so
it's better than we were a week ago, and there may be other subtleties
we're missing, too.

There may also be network effects, e.g. for option completion.

> I don't think it's urgent enough for 0.9.
> 
> I would like to check that the import cost is not too significant.

Both reasonable.

When I submit it as a merge, I'll
1. have some test cases
2. have data on import costs
3. make sure 0.9 is already out

>> way.  It might also be nice to have -v increase the verbosity level.
> 
> Also, we want --no-foo to set the inverse of --foo.

That's pretty easily done.  Should we just generate those options
automatically?  Should they be hidden options?

I've determined that having {foo:False} is not equivalent to having {},
so we'll need to track down why, in order for negative booleans to work
properly.

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

That's no problem.  This is just the default behaviour.

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

NULL_REVISION should probably do that too.  Though it looks like John's
solution of constructing the string from two pieces is used in optparse
itself.

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

iD8DBQFEtbu80F+nu1YWqI0RAqGvAJ0SCV05Ybf0iNFAbyaZiWrAAq877ACfQ8Tr
Q7Lg7mP8Q7EigTF+bXrVecQ=
=QCuG
-----END PGP SIGNATURE-----




More information about the bazaar mailing list