I have a few issues with Python. One of which is the unit-testing mantra. I’m a big fan of unit testing, however I don’t see how it can take the place of static type checking. It can supplement static type checking, but not replace it. For example:
File “/home/balor/tmp/revisor/revisor/base.py”, line 1410, in buildInstallationMedia
self.mode.BuildMedia.extend_task_list()
AttributeError: RevisorBase instance has no attribute ‘mode’
The above would never occur in a statically typed languages such as Java. The Java compiler would simply tell the developer at compile time that RevisorBase has no mode attribute. Unfortunately, this application takes about 20 minutes before it hits the offending line. So what would be a quick spin in a compiler in a staticly typed language is a 20 minute run in Python. It’s also a 20 minute delta between testing patches 
If I write a change it takes 20 minutes before I see if the change is effective.
I understand that one can get similar runtime bugs in statically typed language, however I’ve seen several instances of this type of issue in Python which would be solved by the simple application of a statically typed language.
Anyway, why should I, the user, see this issue.
Well, if you really like static type checking, you should checking out the very strongly statically type checked languages like O’Caml and Haskell. Good Haskellers (unlike myself) don’t just take their type checking lying down. Oh no; they specifically *invent* types to catch themselves making mistakes. It’s a beautiful thing to watch.
Or even more intense are people who use automated proof assistants like Coq, where you get to express and manipulate types like “int array of size 3″. No more bounds checking code; overflows just don’t compile.
Try these: http://wiki.python.org/moin/static_source_analysis
They may help.
Dynamic languages are not as amenable to static checking, for example methods may be added to classes at run time. If you use Python in a static manner then it is a waste to not have static type checking too but many find the trade-off’s involved still worth the effort in coding in Python.
Python 3K is making changes to allow optional type annotations in the language syntax but is not going the whole way and adding static type analysis. The community may produce static type checkers for it in the future.
- Paddy
Similarly I’ve seen one Python method handle input that would require epic levels of Java method overloading thanks to dynamic typing. Whatever typing you go with is a double edged sword.
I ‘m far from a python expert, but I believe the ‘python way’ is to develop most of your app in small increments interactively using a shell and doctests.
Also the python way seems to be “simple is better than complex” i.e., don’t use maze-like nested data structures with super-complex lifetime and locking rules. Do these parts in C/C++ instead and expose it via simple APIs to python code.
If you stick to these principles it is highly unlikely that you will get hit by the lack of the static type checking crutch.
Cool Thanks for this blog. I am starting python and this got me straight.