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

Shannon -jj Behrens jjinux at gmail.com
Fri Oct 8 18:59:42 CEST 2010


If you're on .net, check out Boo.  It's a language that has Python syntax
with static typing.

In Python, make sure your assertions aren't catching too much.  For
instance, if you're checking for float and int, you're leaving out decimal.

Letting the duck typing just do its job isn't as confusing as you might
think. It's not like you can't look at the whole stack trace to see who's to
blame (unless the value was saved in a container for later usage).

Most of my bugs come from not understanding the problem well enough--not
from type errors.  That being said, I'm still excited about Scala which has
a very rich static type system (yeah, yeah, go ahead and make fun of me ;)

Happy Hacking!

On Oct 7, 2010 7:32 PM, "Seth Friedman" <sfseth at gmail.com> wrote:

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

_______________________________________________
Baypiggies mailing list
Baypiggies at python.org
To change your subscription options or unsubscribe:
http://mail.python.org/mailman/listinfo/baypiggies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20101008/b84508a2/attachment.html>


More information about the Baypiggies mailing list