Custom types and default values

Greg Ward <[email protected]> Fri, 28 May 2004 22:27:04 -0400
Newsgroups gmane.comp.python.optik.user
Message-ID <[email protected]>
It's time to revisit a nice little bug that John Belmonte discovered and
brought up here a few weeks back: default values are not subject to the
same type conversions as user-supplied values from the command-line.
Eg. if I define a custom "duration" type, then users can put values like
"2m" or "3.5h" on the command-line, yet I cannot use those values as
defaults -- I must specify whatever the output value is, eg. 120 or 4800
(presuming the human-friendly strings are converted to seconds).

I've filed a bug on SourceForge to keep track of this:

  https://sourceforge.net/tracker/index.php?func=detail&aid=955889&group_id=38019&atid=421097

...but I'd rather keep discussion on the mailing list, since SF's
tracker is such an awful tool for discussing things.  ;-(

This was a *very* minor annoyance back in the good old days, when
default values were strictly between Optik and the developer.  But now
that Optik can expand default values in help text, this may be a
full-blown minor annoyance.  ;-)

My initial proposal was simply to subject option defaults to the same
type-conversion as user-supplied values.  Eg. if the user's "2m" is
passed through a custom convert_duration() to get the output value of
300, then let the developer specify

   parser.add_option("--duration", type="duration", default="5m")

and have that "5m" passed through convert_duration() too.  Nice and
consistent.

John rightly pointed out a problem: anyone already using custom types
who has been bitten by this problem is most likely working around it by
specifying "default=300".  If their convert_duration() does not accept
int values and return them as-is, it'll bomb.

I think this is very easy to fix with a minor tweak to my original
proposal: if a default value is a string, pass it to the type conversion
function; otherwise, leave it alone.  This presumes that the output of
most type conversions are not strings, which seems reasonable to me --
why would you go to the trouble of writing a custom type if not to
convert a string from the command-line to something more usable?  (But
then, I haven't written any custom types, except for example code, so I
really don't know how [or if] they are used in the real world.)

Under this scheme, these two options

   parser.add_option("--duration", type="duration", default="5m")

   parser.add_option("--duration", type="duration", default=300)

would be exactly equivalent -- except the first one would have nicer
help under Optik 1.5 (with appropriate use of %default), and the second
one would work under both 1.4.1 and 1.5.

I'll see if I can't whip up a patch now.

        Greg
-- 
Greg Ward <[email protected]>                         http://www.gerg.ca/
Gee, I feel kind of LIGHT in the head now, knowing I can't make my
satellite dish PAYMENTS!


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click