[getopt-sig] A simple remark for the next Python command line option standard parser
Russ Cox
rsc@plan9.bell-labs.com
Thu, 14 Feb 2002 14:47:11 -0500
> That was one of the motivating factors behind Optik. The way it works
> is this:
>
> * you define your own OptionParser subclass with its own
> STANDARD_OPTIONS class attribute; this is a list of Option
> instances
>
> * applications instantiate your OptionParser subclass, and then
> add_option() any of their own options
>
> With an iterative model, things would be different: the "base" module
> would probably provide a function that you call on each iteration of the
> option-parsing loop, which just looks for the base module's own options.
> Russ, does this make sense?
I don't fully understand this approach. What if I have two
modules I want to allow to take options from the command
line? There's no multiple inheritance, so how do I let them
both do this?
I'd be much happier with modules providing an installoptions
function that adds to the option list somehow.
In the dict framework I threw out here before, you could do
dict = {}
module.installoptions(dict)
module2.installoptions(dict)
...
add your own options to dict
parseoptions(dict)
Or it could be implicit during module loading -- I can't decide
if that's a good thing. In general, letting modules install
their own options is only going to be okay if it's used sparingly.
Russ