Re: Custom types and default values

Greg Ward <[email protected]> Mon, 31 May 2004 22:11:07 -0400
Newsgroups gmane.comp.python.optik.user
Message-ID <[email protected]>
On 31 May 2004, John Belmonte said:
> My question wasn't if strings would be required, but rather if you would 
> still be promoting the use of non-strings.  Anyway, I think I've got the 
> answer :-).

Sorry, forgot to answer that explicitly.  To me,

  add_option("-n", type="int", default=37)

is far preferable to

  add_option("-n", type="int", default="37")

.  So for built-in types, *my* preferred way of working will continue to
be "supply a post-type-conversion value".  But you're free to supply a
string if you like.

For custom types, it's up to the developer, but there are at least two
clear advantages to providing a pre-type-conversion string:

  * better help ("%default" expands to "5m", not "300")
  * some sanity-checking of the developer's default

> I can't argue that it's not an application bug.  Having everything come 
> to a halt when you've got some inconsistency in your program is 
> considered a desirable trait by many programmers.

I totally agree.  If you want that trait with Optik 1.5, then you are
quite free to write

  add_option("-n", type="constrained_int", default="51")

and then watch things blow up when your type-checker for constrained_int
rejects "51" as out of range.  With Optik 1.4.1, you don't have that
option.

        Greg
-- 
Greg Ward <[email protected]>                         http://www.gerg.ca/
Never try to outstubborn a cat.


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