[getopt-sig] Random thoughts

dittmar@snafu.de dittmar@snafu.de
Fri, 15 Feb 2002 11:20:03 GMT


Thought 1

+1 for Optik vs. Iterator
- less typing for the simple cases
- it's easier to combine options (application: multiple
    scripts connecting to a database can share option 
    definitions related to connections and add their own
    options)
- all the information for one option is in one place
    * name (s)
    * initialization/default
    * argument processing
    * check at end of processing (not yet in Optik)

There is the occasional use for an iterator 
(e.g. -o <outfile> <infile> -o <outfile> <infile> ...)
but as I don't care much for combined options (-cfd instead of -c -f -d),
I simply don't support them and then writing an iterator is trivial.

Thought 2

Would the following be a violation of 
"explicit is better than implicit" or an application of
"don't repeat yourself"?
Optik:
the default for "dest" is the value of the 
long option without '--'
the default for "type" is deduced from the type of the "default" value

Thought 3

Should there be support for more sources of arguments?
* @filename in argument list => will expand contents of
    filename into argument list
* Optik (env = varname) will prepend additional options from
    os.environ.get (varname, ''), it's the name of a 
    environment variable and not a string because
    that name should be generated into the documentation

Thought 4

I'm not sure that adding new actions through subclassing
is the way to go as this makes it a bit cumbersome to add
actions from different sources.

Thought 5

My own option lib can be called as main and produces then a 
skeleton script:
#!/usr/bin/env pythhon
# dummy.py

def main (options, args):
    for arg in args:
        pass

def _options ():
    return [
        # (optstring, varname, typechar, default, help)
        ]

if __name__ == '__main__':
    import optlib
    optlib.optMain2 (main, _options ())

The important part is the comment in _options, as it gives
a template how to fill in the various fields.

This could be extended by using additional arguments to transform
'--output=xyz -v --count=0'
to
parser.add_option ("??", "--output", action="store", dest="output",
    default="xyz")
parser.add_option ("-v", action="store_true", dest="v")
parser.add_option ("??", "--count", action="store", type="int",
    dest="count", default=0)

Thought 6

One application of 'optional argument to option':
script --log=x.log   writes to x.log
script --log         writes to default-file-name
script               writes no log

Not that I use this often enough to require it in a standard lib.

Daniel