[getopt-sig] Yet another parser proposal

[Shane Hathaway]

s.keim wrote:
> #  quickcmd.py
> #
> # a quick and dirty implementation around Shane Hathaway idea:
> # let's use python syntax for cmd line grammar specification.

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.

My goals for an option parser are as follows.  If anyone sees the goals 
differently, please help me out.

- Keep the options, the documentation, and the functionality in sync. 
I've written a few command line utilities, and over the life of a 
project sometimes an option is added or removed (or its meaning is 
changed) without updating the documentation.  Or even worse, the program 
might start ignoring an old option even though the option is still 
accepted and documented.

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

- Generate a lot of the documentation automatically.

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

The Python getopt module by itself doesn't meet any of these goals (I 
think).  It does meet lower-level goals such as parsing options in a 
consistent way, but it makes no attempt to keep options, documentation, 
and functionality in sync.  Its interface is cryptic (it accepts a 
structure of Python types with specially formatted strings, returning a 
different structure of Python types.)  It generates no documentation. 
It's flexible, but not really extensible.

As far as I can tell, Optik meets some of these goals.  It keeps the 
options and the documentation in sync, but it doesn't make an attempt to 
bind together the functionality and the options.  It has a simpler 
interface than getopt, but a programmer would still have to refer to a 
manual.  I don't know how well it generates documentation.  It appears 
to be very extensible, both in simple and complex ways.

The prototype ObjectCLI helps keep options and functionality in sync by 
deriving option specs from the function signature.  Most programmers 
remember to remove function parameters when they are no longer needed. 
ObjectCLI uses an interface Python programmers already know and use 
every day.  It generates a lot of the documentation, and it allows both 
simple and complex extensibility.

The ObjectCLI prototype does not currently make a full effort to keep 
options and documentation in sync, however.  And of course it currently 
assumes you always call a method of a Python class rather than a 
function.  s.keim's prototype appears to make the reverse assumption.

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.

So it appears to me that the concept behind ObjectCLI (and s.keim's 
code) meets these goals better than Optik does.  I would like to hear 
some discussion regarding whether you folks have the same goals and how 
you would evaluate the implementations.

Shane