[getopt-sig] Yet another parser proposal

[s.keim]

> This looks useful, but I'm surprised you went to so much work when a 
> prototype was already in existence.  I thought we should first discuss 
> whether this approach is a good one or not.
You are absolutely true! In fact I started saturday morning by writing 
some few lines just to see how it could look like... and discovered that 
the night had fallen down and that  I had spent all the day on this...
Not really reasonable ;-)

> - Keep the options, the documentation, and the functionality in sync.
+1

> - Use a natural interface that doesn't have to be memorized or printed 
> on a reference card.  Ideally, you only have to write a Python function 
> or class.
I believe that Python rock because it respects something that Frederick 
P. Brooks, in the Mythical Man-Month, call "conceptual integrity". For 
me that mean that the UI of a system should look for the minimal number 
of concepts and, probably more important avoid subtle variations  around 
theses concepts.
What I like in your proposal is that it reuse an existing protocol 
instead of creating a new one. The important points to check now are:
- is there better protocol to use?
- aren't we corrupting the class/function concept ?

> - Generate a lot of the documentation automatically.
I'm just thinking that maybe the parser documentation generation is 
quite related to the pydoc module.

> - Allow simple extensibility (groups of options, like "cvs -q up -dP") 
> as well as complex extensibility (subclassing the option parser or the 
> classes it uses).
We should be careful to not go to far in that way: in my opinion ease of 
use and reliability is far more important than extensibility. Because, 
it seems not really hard to parse the cmd line by hand, developers won't 
use the parser if they find it complex. So we should focus on the common 
needs and let exotic needs  be solved by externals tools.
If we don't take care, the danger is to fall in the hell of "there is 
more than one way to do it",  both for the UI of the script  and for the 
use of the parser ;-)

> I'd also like to list some non-goals.  One non-goal is the level of 
> complexity required to make a "tar" replacement without extending the 
> parser.  I think we should assume if you're going to that extreme, you 
> should have to extend the parser.  Another non-goal is a large number 
> of options in a group.  Large numbers of options are hard for 
> programmers to maintain and for users to understand.
+1

There is also two other points that need to be  discussed:

- the values storage: ObjectCli make it really elegant by using method 
arguments for value storage. I didn't made this choice because I planned 
that the function should only be used for analysis and not for 
processing. For Optik my feeling is that it do a little to much in this 
area by providing the action method, I think that only the default 
'store' action should be used and that it is the application job to 
decide what to do with the values.

- the type checking-conversion:  I find this feature interesting, but I 
wonder how far we should go on that way. And I definitively think that 
the type checking-conversion code should be reusable in other parts of 
the applications (because cmd line parsing is far to be the only place 
where you need to do this kind of job).
I'd like to militate for a simple protocol, that will allow to reuse 
theses objects for interactive text input checking for sample.



seb