[PEAK] options.txt

[R. David Murray]

Just finished reading the options.txt file.  I think this style
works very well.  There were a couple of places where I got slightly
confused and needed to go back and reread things, but that is
inevitable for a technical document and doesn't seem to have been
in any way a structural result of the use of doctest.

I also love the option parsing facility itself, especially
the automatic help text generation.

A metacomment on command parsing:  I have noticed over the years
that in unix a lot of attention gets paid to automated parsing of
options and very little to parsing arguments.  Coming from a VM/CMS
and more lately Cisco IOS background I have a tendency to write
commands that use structured arguments (subcommands, keywords)
rather than options.  I'd love to have a facility like the option
parser for laying out and parsing argument strings.  It doesn't
seem to me that it would be very complicated to do, at least for
straightforward arguments (and one shouldn't really have any other
kind), so I've often wondered why it is neglected.

Finally, a typo correction:


Index: src/peak/running/options.txt
===================================================================
RCS file: /cvsroot/PEAK/src/peak/running/options.txt,v
retrieving revision 1.7
diff -u -r1.7 options.txt
--- src/peak/running/options.txt	28 Nov 2004 19:31:57 -0000	1.7
+++ src/peak/running/options.txt	30 Nov 2004 21:05:40 -0000
@@ -178,8 +178,8 @@

 Note also that more than one option can be specified for a given attribute,
 although in that case they will usually all be ``Set(value=someval)`` options.
-For example, the For example, the ``-v`` and ``-q`` options shown above would
-most likely be used with the same attribute, e.g.::
+For example, the ``-v`` and ``-q`` options shown above would most likely
+be used with the same attribute, e.g.::

     >>> class Foo:
     ...     binding.metadata(verbose = [opt_v, opt_q])


--David