Re: Difficulties in using optparse for the very first time.

David Goodger wrote:
 >> I suspect that you really want this usage:
 >>
 >>     usage: %prog [-s | -i | -c] [input_filename ...]

Laura Creighton wrote:
 > No, I don't want this, because this implies that input_filename(s)
 > are optional.  That is only the case with the -s option, or if you
 > pass it no options at all.  input_filenames(s) are required with the
 > -i and the -c option.

I see.  Looking back at your original usage string, it makes sense now
(the presence/absence of []'s was easy to miss).  I needed that bit of
explanation.  It may have been clearer to express the usage as two
variants:

     usage 1: %prog [-s] [input_filename ...]

     usage 2: %prog (-i | -c) input_filename ...

Or explain in the description, that "at least one input_filename is
required with the -i and -c options".

 > And this is the heart of the disagreement.
...
 > So what you are not supporting is something that I consider
 > essential.

Not a disagreement, just a misunderstanding.  The way you were
specifying the usage, and writing the implementation, the input
filenames seemed to be attached to the options, but options don't work
that way.  Instead, the presence of certain options (-i/-c) influence
the positional arguments.

 > The odd thing is that I was unaware of the controversy.  I knew that
 > some people, especially people who program for windows and have
 > never used a pipe, were _unaware_ that they should write their
 > programs to take file name arguments if they are there, or stdin if
 > they are not, but I was unaware that some people were actually
 > opposed to this.

There's no stdin/stdout controversy.  I've never heard of anyone
opposed to required filename arguments.  At worst, there's a tendency
among Unix programmers to write their tools as filters.

The only controversy is with "optional option arguments" (which, due
to their ambiguity, are impossible to parse reliably and simply) and
"required options" (a contradiction in terms).

 > I suppose I should get out more.

No, just better explanation of the specification, to prevent
misinterpretations.  But all's well that ends well, and the code I
posted last time is still applicable, with changes to the usage
and/or description strings.

-- 
David Goodger <http://python.net/~goodger>


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com