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

Greg Ward wrote:
> On 04 July 2004, Laura Creighton said:
> 
>>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.
> 
Rationale: ``alias foo='foo -v'`` or any other thing that makes one of
the options always present.  You should allow to override it.
This is also the reason to always have an option for enforcing the
default behavior.  This grows much more important the moment your
program grows multiple setting sources (config files, env. vars, etc.).

>>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 terminology *is* confusing.  To many people, the natural meaning of
"option" is an option string.  This is ambiguous because there is no
good term for an Option.  I see no better solution than the current 
"option"/"option string" terminology but the difference should be 
explained clearly in the docs.  In particular, this matter is badly
confused by the Terminology_ subsetion of the Tao - it only mentions
"option" as a -x/--foo argument (which is closer to "option string" but
would be more precisely named an "option argument" if this didn't
already mean the argument following the option string argument :-)).

.. _Terminology:
    http://optik.sourceforge.net/doc/stable/tao.html#terminology

Quite a mess.  The terminology section should be improved and the
occurances in the docs should follow it carefully.  In particular, it
might be better to rename the conflicts section to "Conflicts between 
option strings" or "Conflicts over option strings".  I agree with Laura
that "collision" would be a better term (but changing the docs now
would only be more confusing unless you also rename the apperances of
"conflict" in the API, which is hardly worth the trouble).

> This is a "compile-time" problem, and you're interested in run-time
> mutually-exclusive options.  Totally different ball of wax.
> 
Should be mentioned at the head of the section.


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285