[Baypiggies] Type checking - argument for it being bad practice?

[Seth Friedman]

Hi Baypiggies,

I've encountered, a couple of times now, a sort of categorical "dont do
typechecking" attitude on various blog posts and I haven't seen rationale to
back it up.   Enough that I'm now curious: what's the deal?

So I put the question to you all, typechecking: good or bad thing?  Or
pointless philosophical debate?

The best argument I can think of for typechecking=bad is that if underlying
functions can take more types than obvious, let it try to do the right
thing, and if it fails, another exception will be likely anyway.   I mean
the TypeError raised with '1'+1 is pretty clear ("cannot concatenate 'str'
and 'int' objects"), but if it were more complex logic say with home-built
exceptions expected to highlight the error, I am skeptical.

I guess a second-best argument I can imagine is about false-negatives ..
what if I am overly restrictive in my type check and it fails when the (my)
logic would have succeeded.   Well, ok, as with anything gotta be careful
with typechecking as with the rest of the code.  But what if code around my
function is expecting ints and not floats even if my function can deal with
both.

If I'm writing the function and I know I only wrote it to accept single
numbers and not, for example lists or strings, isn't it cleaner to have at
the top of my function something like:

numbersoaccept=(int,float)
assert(isinstance(inputvar,numberstoaccept))
?

If I don't do this easy check it seems like failures down the road are
likely to be more convoluted and require more debugging time.   And is there
a better/more pythonic form of typechecking than this assert?  If I need to
extend my function to convert a string '1' to an int or to handle lists, it
seems better to have an assert that prompts me to remember that there's a
decision to be made about where to put that logic.  It's kind of like
executable documentation, what's the downside?

Best
seth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101007/75508b24/attachment-0001.html>