[getopt-sig] some comments about Optik

[s.keim]

I'll try to give a follow up to your response and about a private mail 
Russ Cox sent to me:

>> Wouldn't it be easier for the user to directly use functions objects:
>> for sample:
> Or did you mean to put a type object there, like StringType or 'str'
> (same thing in Python 2.2)?  Two problems with that:
Yes that was what I was thinking about ( 'string' was a typo and I meant 
'str' actually)

>   * tricky to make it work the same way < 2.2 and >= 2.2:
>     if you want either 'str' or StringType to work in all versions
>     of Python (seems desirable to me)
This an important point for an independent package, not so true for a 
standard module which must enforce IMO the use of the language (and 
Python 2.2 is the language now).

>   * what about extensibility?  one of the major features of Optik's
>     type system is that its extensible: you could add a "file" or
>     "dir" or "outfile" type; some of those things correspond to
>     Python types or builtins, and some don't
Here we  only check string validity and generate value. I don't see  the 
extensibility problem: you can supply an user defined function instead 
of a type. For sample if you want to read a file key=value and convert 
it as a list of pairs:
def open_file(path):
	try:
		f = open(path,'r')
	except IOError:
		raise OptionError, "file "+path+" not found"
	return [ l.split'=' for l in f.readlines() ]   # well this would 
need more work in real life

> ...and that presupposes a name 'store_true' in each OptionParser
> instance, which means that adding an action requires subclassing both
> Option and OptionParser.
I haven't taken a look at the actual implementation, so ...

> Using strings to represent types and actions might be slightly more
> verbose, but I think it makes it easier to extend Optik: all you need to
> do is recognize one more string.
In fact, verbosity wasn't a matter for me, It was extension that I found 
quite complex.

I would give another example about the consequences of my proposals:
Suppose you provide to the 'action' method a subclass of the object 
returned by the 'type' method (with for instance an additional attribute 
_parse_info that contain ..surprisingly .. the extra informations from 
parser)
Then things start to become obvious:

For sample, you have defined an "append"  as appending data in a list. 
Now you have it for free:
L = []
Option("-f", action=L.append, type=str)

>> * required parameters
>> *groups
I agree that 'required option' is a non-sens. Later posts in the list 
have clarified the terminology so I won't say more about this, simply 
that my proposal wasn't very good.

My last feeling is that Optik is the union of 3 tools:
- a command line parser
- a grammar checker / doc generator
- a data processor (the 'action' stuff)
Maybe that the famous two groups  would be happier if we had this 3 
tools split and made to cooperate well.

And this could give us a lot of flexibility:
- one could replace the command line parser by a configuration file 
parser for instance
- or a unix cmd line grammar checker by a dos cmd line grammar checker
- or maybe it's just a dream ;-)


seb