[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