[getopt-sig] Yet another parser proposal

[Shane Hathaway]

s.keim wrote:
>> - 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.

Right.  Reuse of user interfaces, if done properly, has numerous benefits.

> 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 ?

Personally I'm confident with this approach, since I'm very familiar 
with it from the Zope world, and because I've actually used it in a 
project.  Maintaining the option signature as part of the code is very 
programmer-friendly.

In Zope the class/function concept certainly wasn't corrupted IMHO. 
(Zope currently does have trouble with excessively large class 
hierarchies, but that is unrelated to this issue, and besides, the Zope 
3 project is seeking to solve the class hierarchy problem.)

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

True.  Does pydoc let you describe each function parameter in a 
machine-recognizable way?  That's one of the main features of javadoc. 
Parameter descriptions in docstrings would help us solve the issue of 
keeping the documentation in sync.

>> - 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 ;-)

Right.  I was thinking one might want to subclass the option parser to 
override the automatic documentation, and perhaps that's enough.

> 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.

Sounds right to me.

> - 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.

Well, I don't think we have to invent a "protocol", we just have to make 
the code modular and flexible.

I hope we'll see some comments from the rest of the group.  It feels as 
if you and I are in a different SIG entirely. ;-)

Maybe everyone needs to see a more concrete example of ObjectCLI.  Here 
is the code at the bottom of objectcli.py:


  class Program:
         "objectcli test program"

         def cmd1(self, alpha, b=0, *args):
             """
             Executes a command.

             --alpha=value  First argument
             -b             Enable second argument
             (Followed with arguments.)
             """
             print 'cmd1 got', alpha, b, args

         def cmd2(self, cat, d=0):
             """
             Executes a different command.

             --cat=value  First argument
             -d           Enable second argument
             """
             print 'cmd2 got', cat, d

     cli = ObjectCLI(Program())
     res = cli()
     sys.exit(res)


The only thing the programmer has to remember is to make an instance of 
the ObjectCLI class and call it.  The rest is simple Python.  Although 
ObjectCLI currently requires a class instance and a method name as the 
first argument, I now realize it should also allow you to pass a Python 
function, which would give you the equivalent of most command-line programs.

Shane