[RFC] use optparse for option handling

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Martin Pool wrote:
>>> On 12 Jul 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>>>> 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.
> 
> Those are both well-supported.  I've actually got support for negative
> options in the latest version of that branch:
> 

I think you want 'store_false' not 'store_const'. I think by doing
'store_const' it is using the default 'const=None', so you get None
back, not False.

>         if optargfn is None:
>             parser.add_option(action='store_true', dest=self.name,
>                               help=self.help,
>                               default=OptionParser.DEFAULT_VALUE,
>                               *option_strings)
>             negation_strings = ['--%s' % self.get_negation_name()]
>             parser.add_option(action='store_const', dest=self.name,
					^^^^^^^^^^^- 'store_false'
>                               help=optparse.SUPPRESS_HELP,
>                               const=OptionParser.DEFAULT_VALUE,
>                               *negation_strings)


>>> 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
>>>
>>>   Option('remember', negatable=True)
> 
> I was assuming all booleans should be negatable.  Is that wrong?

Having it consistent is reasonable. It does mean we will have some weird
coupling, but it makes it easier for scripting front ends.

> 
>>> it's probably good to show both in the help.
> 
> Okay, so that means we won't want to use optparse to generate our option
> help, because it wants help for every flag name, and we don't provide
> text for the inverted help.

Actually, just add the inverted option first. Then you get:

- --other-option	help on other-option
- --no-foo
- --foo 		help on foo

I do that all the time.

> 
>>> 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.
> 
> I've switched to using an object instance, just to be on the safe side.
> 
> Aaron

Seems reasonable.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtwGwJdeBCYSNAAMRAnJmAKCwm6MXvy7xjfsUn+1HDHLBxFSAJgCgtqfR
RhRXrJ1DhrtttJCjpCp+jkM=
=3PHP
-----END PGP SIGNATURE-----