[getopt-sig] Parse arguments according to a usage message?

[Greg Ward]

On 18 February 2002, David Boddie said:
> I wonder whether there is any mileage in using part of the class that I
> mentioned in the "RFC: Option Parsing Libraries" thread in python-dev?
> 
> http://www-solar.mcs.st-and.ac.uk/~davidb/Software/Python/cmdsyntax/

Oooh, neat!  What a cool idea.  One thing to note is that you're
addressing the wider issue of *argument* parsing, whereas most people
are just interested in option parsing -- eg. Optik works by removing all
options and their arguments, and passing back a list of whatever's left
over.  This is a fairly common model, and it works for me.  But it
means every Optik-based script has code like

  [...]
  (options, args) = parser.parse_args()
  if len(args) != 3:
     parser.error("wrong number of arguments")

For a simple fixed number of positional arguments, this is not a big
deal, but it can be tiresome when you have a fairly complex syntax left
over after options have been parsed.  Your module, presumably, solves
this nicely by incorporating positional arguments into its domain.

There are also some fairly obvious limitations:

  * what about scripts with dozens of options?  the traditional
    "[-v] [-q] [-o outfile]" notation is great for 3 or 4 options,
    but loses its appeal pretty quickly.  (Try "man mpg123" for an
    example of what I mean.)

  * no strong typing -- everything's a string, and I have to explicitly
    convert numeric option arguments and catch the errors

  * how much say do I have in what happens to option arguments?  eg.
    is there an equivalent to Optik's "append" action, where each
    occurence of a particular option appends that occurence's argument
    to a list, rather than replacing previous values?

Must look at your code.  Neat idea.

        Greg
-- 
Greg Ward - geek-at-large                               gward@python.net
http://starship.python.net/~gward/
All the world's a stage and most of us are desperately unrehearsed.