Is it ok to type check a boolean argument?

Carl Banks pavlovevidence at gmail.com
Thu Jan 8 19:49:03 CET 2009


On Jan 7, 6:21 pm, Scott David Daniels <Scott.Dani... at Acm.Org> wrote:
> Adal Chiriliuc wrote:
> > On Jan 7, 10:15 pm, Bruno Desthuilliers
> > <bdesth.quelquech... at free.quelquepart.fr> wrote:
> >> ... I'd either keep the argument as a boolean but rename it "ascending" ...
>
> > Well, I lied a bit :-p  ....
> > But what if we can't solve it as elegantly, and we need to ...
>
> > Should we typecheck in this case to ensure that if we pass a string
> > for "fast_mode" we will raise an exception?
>
> Why are you concerned only with type errors on inputs?
> Even if you could do exhaustive checking of input parameters to
> make sure they are the only acceptable values, what prevents your
> user from providing the wrong valid value?  What made you pick on
> type errors in the first place?  If it turns out that an argument
> of 422 is a typo for 42, why is that less of a problem?  Just because
> you are used to systems where one kind of error is always caught does
> not really make you invulnerable.  You'll have no problem telling
> your users that the 422 is their fault.  Why do you have such
> certainty that passing in "nonsense" as a boolean is a failure
> you need to deal with?


I'm going to play Devil's Advocate here.

The motivation here is not "we want type safety" but "our unit tests
can't register this deliberate error because it passes silently".
Presumably if they had a function that accepted integers, and 442 was
an invalid value, and the function failed silently in a unit test,
they would also consider whether it should instead fail loudly.

It's always a judgment call how much to screen for bad input, but type
errors aren't different from any other error in this regard.
Sometimes it's appropriate (note: not, IMHO, in this case), just like
it's sometimes appropriate to check for 442.


Carl Banks



More information about the Python-list mailing list