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

On 04 July 2004, Laura Creighton said:
> One of the problems with finding out how new users see your code is
> that 'new users' have a very limited shelf-life.  They become experienced
> users, who know what to expect.  So when I try something new, I try to
> keep a record of how it goes to  report back.  With optparse, it didn't
> go all that well...

Hmmm, I hope it's not too late for you to take a look at the latest
version of the Optik docs.  I did some cleaning up and clarification a
few weeks back; you'll find the results here:

  http://optik.sourceforge.net/doc/stable/tao.html
  http://optik.sourceforge.net/doc/stable/basic.html
  http://optik.sourceforge.net/doc/stable/advanced.html

(The other docs didn't change much.)

These changes should make it into Optik 1.5 and Python 2.4.  But David's
right, there's still room for improvement.

> The examples are:
> 
> 	parser.add_option("-v", action="store_true", dest="verbose")
> 	parser.add_option("-q", action="store_false", dest="verbose")
> 
> which of course gets me excited, because I figure these examples are
> mutually exclusive, and thus this should be pretty much what I want.
> Since I have three values, not two, I figure that I will be able to
> find an action that stores something other than a Bool.

Who says these are mutually exclusive options?  Any program that barfs
if you supply both -v and -q is terminally brain-damaged (IMHO) (not
that I ever had a humble opinion in my life).  The common convention for
options that update the same variable is "last one wins".  But you're
right, that probably should be stated explicitly in the docs somewhere.

To me mutually exclusive options are like required options: a special
case that is generally best avoided.  Optik gives you no help at
implementing either one, but it doesn't really get in your way either.

However, implementing mutex options is probably a bit more awkward: you
either have to give them separate destinations, so you can do

  if options.copy_files and options.stdout:
      parser.error("-c/--copy-files and -s/--stdout options are "
                   "mutually exclusive")

or you need a callback.  Neither solution is particularly satisfactory,
but I strongly believe that options should be as independent as
possible.  It's not by coincidence that Optik's Option objects don't
know anything about other Option objects.

> Problem #1 
> ++++++++++
> is that  '6.20.2.2 Other store_* actions' is
> incomplete.  It needs to mention store_const.  A forward reference
> to 6.20.3.3 would also be helpful.

I'm pretty sure this is fixed in the updated docs.

> Problem #2
> ++++++++++
> By using mutually exclusive options in your example you create
> the false sense that you are handling mutually exclusive options.  This
> is a particular problem in  '6.20.2.2 Other store_* actions' which reads

No: by assuming that my complementary options (-v and -q) are mutually
exclusive, you've set yourself up for a world of pain.  The only
solution I can think of is more soothing words in the docs.  Patches
(relative to the *.txt files in
http://cvs.sourceforge.net/viewcvs.py/optik/optik/) are welcome.

> Problem #3
> ++++++++++
> Section 6.20.3.6 I think is very misleading.  It is not about _defining 
> options that conflict with each other_, as you might expect, but instead 
> about defining the same option multiple times.

You're confusing "option" with "option string".  This code:

  parser.add_option("-n", "--dry-run", ...)
  parser.add_option("-n", "--noisy", ...)

defines two options with two option strings each.  These are conflicting
options, because they share an option string.  (To give you the benefit
of the doubt, it's really only important to make the distinction when
reading/modifying the Optik code.)

This is a "compile-time" problem, and you're interested in run-time
mutually-exclusive options.  Totally different ball of wax.

> Ok, by this time I have read the whole manual twice, and the code once.
> I am now firmly convinced that my whole preconceptions about what I 
> ought to find here were _wrong_.  And it looks to me as if there is
> no builtin supplied way to specify 'these options are mutually exclusive',
> which surprises me a lot.

Correct, see above for my reasoning.

Anyways, as David said, you could do much worse than read the
"Philosophy" section to see the thinking behind Optik/optparse.

        Greg
-- 
Greg Ward <[email protected]>                         http://www.gerg.ca/
What the hell, go ahead and put all your eggs in one basket.


-------------------------------------------------------
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