[getopt-sig] my current argument parser

[Russ Cox]

Thanks for the comments.

> It might be nicer to be able instead to go a,b = arg.get(2),
> if you know there are two values.  What about values = arg.consume() or
> arg.getall() to consume all parameters to the next "argument" ?
> 
> ie given -I its iterative not optional -b wibble
> 
> you can go if o == 'I': words = args.consume() ??

args.consume() bothers me for the same reason that
optional arguments bother me.

Since having more than one argument to an option
is such a rare case, I'm not convinced that arg.get(2)
is really worthwhile.  If it was really common in a program,
I might subclass the parser.

> If we remove the optionality of long arguments then you can support
> --long bar also.  Some people like this as it is at least consistent with
> arguments to short options as well.  Personally I don't.

What do other tools do here?  I never use long options
so I don't really know what the standard behavior is.

In response to another message, I can understand the
desire to have mandatory options when configuration
is really a sequence of key-value pairs.  But I'm not convinced
the parser has any business checking such things.  I'd rather
it be a parser and add a check in the program.

Russ