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