PyChecker
Mark Côté, Thursday, October 15th, 2009
Present Python to a group of coders used to C/C++, and the objections are pretty familiar. They almost all revolve around Python’s typing, specifically that it is dynamic and thusly only evaluated at run time. “You’ll be delivering products with all sorts of potential bugs!” My knee-jerk reactions when put on the defensive like this also follow standard patterns, such as “a compiler isn’t a substitution for thorough testing” and “so you never type cast?” But those reactions never seem to win the argument on their own because there really is no denying that Python introduces a source of errors that are caught very quickly in statically/normatively typed languages. One friend of mine objected to using Python for a weekend programming event because he didn’t want to be searching for errors like this at 2:00 am:
broken = False
...
try:
thingy.configure()
except:
borken = True
...
return broken
He pictured himself debugging thingy.configure(), trying to figure out why it wasn’t generating an exception while it was obviously failing, never noticing that he wasn’t setting the correct variable in the exception handler. I’m sure that many Python programmers would loudly suggest that the potential of such errors is minimal if one is careful, and indeed is an acceptable price given the speed of development conferred by Python, but would secretly be thinking of times they were burned by exactly such a mistake.
If you can, however, find these errors by carefully scanning your code, why can’t this be automated? And indeed it already has been! PyChecker “finds problems that are typically caught by a compiler for less dynamic languages, like C and C++.” And it does a pretty bang-up job too. I just found a few silly mistakes in my app, down code paths that (apparently) aren’t used very often. Hey maybe inadvertently it’s also a good tool to determine how much effort I’ve wasted coding features and error handlers that are never used…