Python specs weren't written by someone knowing about languages and standardisation. By far the worst problem was exceptions. In many cases errors are specified to throw exceptions... which means the behaviour is well defined.
This alone make static type analysis almost impossible. To do static typing you need a specification that says the result of a wrong typing is undefined. Otherwise the program can *rely* on catching an exception, and a type error isn't an error (since the behaviour is well defined). Trying to explain that to Pythonistas and van Rossum in particular proved difficult.. although they seemed to understand the problem which dynamic mutations to modules caused and considered 'freezing' modules after they'd been imported. This may have been done in later versions of Python: some changes to 'eval' and friends were made for his reason (you have to specify the dictionary to use for an eval now).
> 1. analyse all the constraints of the code
> def f(a): a.append(1)
> def g(a): a=a+1; f(a)
> => a must support append
No, you cannot assume that due to the 'exception' problem mentioned above.
> => a must also be an int
And you can't assume that either. A could be a class with an __add__ method. Alternatively, it could be anything, and the called of g() is again relying on a type error to throw an exception.
As described elsewhere, I've quit LiveJournal. If you're interested in my continuing posts, you should look at one of these (each contains feed…
They published a paper on Dremel, my favorite previously-unpublished tool from the Google toolchest. Greg Linden discusses it: "[...] it is capable…
I finally wrote up my recent adventures in treemapping, complete with nifty clickable visualizations.