[RFC] use optparse for option handling
mbp at canonical.com
Fri Jul 14 02:35:45 BST 2006
On 12 Jul 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> 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.
Yes. I just hadn't worked out if there was a good way to e.g. do
negative options, or options which accumulate a value, etc. If there is
and the other issues about cost as settled then it's good with me.
> > 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 would say we want something like
it's probably good to show both in the help.
> > 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
Relying on ("a" + "b") to not intern to "ab"? It seems possible some
other or future Python implementation might eval it at compile time and
then do the wrong thing... maybe this is paranoid.
More information about the bazaar