[getopt-sig] ObjectCLI

[Shane Hathaway]

On Tue, 19 Feb 2002, Greg Ward wrote:

> Initially, this looks promising/interesting.  But what about programs
> that don't have the "sub-command" paradigm?  How do you handle the
> simple
>
>    program --port=3128
>
> case?

It doesn't work in the current prototype, but instead of passing an
instance, you just pass a function.

>  Also, what if I want to make -p and --port synonomous?  How do I
> express that?

I'm sure we differ on this, but for me (and perhaps others), that is not a
goal.  You can still do it in a roundabout way, of course:

def program(p=0, port=0):
  if port == 0:
    port = p

>  How would you handle standard, simple command-line
> structures like
>
>   ls -Fa /home/greg
>   ls -l *.py

def ls(F=None, a=None, l=None, *filenames):
  ...

>   cp -pr /tmp/foo /tmp/bar

def cp(p=None, r=None, *filenames):
  ...

> > You can also get the documentation of ServerControl, primarily derived
> > from the docstrings:
> >
> > python server_control.py --help
>
> Interesting idea, but I worry about the overloading of docstrings.
> IMHO, method/function docstrings are most useful for someone reading the
> code: if I want to call function f, what arguments do I pass in, what
> types must they be, what do they mean, how do they interact, what
> happens to them, and what are the return values?  Those are very
> different goals from the user of a program who wants to know what the
> "start" sub-command does.

If you wrap a Python function rather than a Python instance (not possible
right now, but easy to add), I think the goals are quite similar.

> Also, where does the help for, eg., "--port" come from?  Are your method
> docstrings structured so that help for individual options (method
> arguments) can be pulled out?

No.  That is, admittedly, something I don't know how to solve yet.

> > Major benefits:
> >
> > - You almost never have to look up any library documentation to write
> > new command line utilities.  You just write a regular Python class.
>
> I'm skeptical of that.  *You* almost never have to look up any
> documentation, but you wrote it.  Likewise, I hardly ever have to look
> at the Optik docs.  It's always obvious to the person who designed and
> wrote it, and rarely to the poor schmo trying to use it.

The difference is there is only one entry point.  You only have to call
the framework.  The rest of the work is writing normal Python code.

> > - The command line arguments and the implementation are less likely to
> > fall out of sync.
>
> I'm not sure what you mean by "implementation".

I mean the code of the program.  With the code and the option signature
tightly bound, the code and the options are less likely to fall out of
sync.

> > - The documentation comes directly from the docstrings.
>
> Again, I'm not convinced this is a benefit.
>
> Finally, you have alluded to a prototype implementation of ObjectCLI --
> where?

In the "pma" subproject of the zodbex project at SourceForge.  See
zodbex.sf.net.

I'm pretty sure you and I have different goals.  I think your main goal is
to create a featureful option parser that does a better job than getopt.
My main goal is to eliminate the work of parsing options altogether,
possibly sacrificing some flexibility.  The differing goals result in very
different mindsets.  I'd like to know what other people's goals are.

Shane