[getopt-sig] some comments about Optick

[s.keim]

After a first dive into Optick documentation, I think that it seems very 
promising.

I have some questions/suggestions about the API:

  * I don't see the need for the level of indirection in the add_option 
command.
Wouldn't it be easier for the user to directly use functions objects:
for sample:
parser.add_option("-f", "--file", type=string, dest="filename",
                         help="read data from FILENAME")
or
parser.add_option("-v", "--verbose",  action=parser.store_true,  
dest="verbose")


* It would be better to define call-back as functions with one arg. This 
will allow you to change/extend the API only by appending attributes to 
the argument and then without breaking existing call-back functions.

* Parsing value policy
in the doc:
 >Let's parse another fake command-line.  This time, we'll jam the option
 >argument right up against the option -- "-n42" (one argument) is
 >equivalent to "-n 42" (two arguments).
in the second case, how the parser know that 42 is the value of the -n 
argument and not  a positional parameter? Is it because we have defined 
that action="store"?

* This is mainly a matter of taste, but I'd like to have the dest 
argument optional, if the long option is defined:
parser.add_option("-v", "--verbose",  action="store_true")
would be equivalent to:
parser.add_option("-v", "--verbose",  action="store_true",  
dest="verbose")

* required parameters
I haven't see this in documentation, so I suggest to add a field to 
options:
Option("-f", action="store", type="string", dest="filename", required=1)
Then parser will fail if the -f option doesn't exist in the command line

*groups
Sometime, you want to manage options by groups:
- the user can only supply one of the options of the group.
- the user must supply at least one option of the group.
I don't know how to express this yet, but this would be something 
interesting to have. In fact this is probably quite related to the 
"store_const" action.

* default values
I think that the command line parser shouldn't manage default values 
because quite often software provide several way to define options:
- hard coded
- site dependent configuration file
- user configuration file
- environ variables
- registry base on windows
- command line

So if default value management was left to a separate object, we could 
have something like:
file_parser  = FileOptionParser(xxxx)
env_parser = EnvironParser( xxxx )
cmd_parser = OptionParser(option_list= xxxx)

options = DefaultValues (pos1, "positional2", verbose=1, 
filename="'/tmp/usr.tmp' )
options.update(file_parser.parse('/usr/local/share/prog/defaults'))
options.update(file_parser.parse('~/.prog/defaults'))
options.update(env_parser.parse())
options.update(cmd_parser.parse(sys.argv[1:] ))

and then go to:
if options.verbose:
           print "reading %s..." % options.filename

By the way, many informations are shared between the xxxx arguments of 
the several parsers, so maybe we could look for an api that would 
permit  to avoid duplication.

seb