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.
I've been hacking on some Haskell stuff lately that's all managed in darcs and it's reminded me of an observation I made over two years ago now (see…
I was tickled to discover another IBM developerworks article on one of my abandoned hacks and that both it and its predecessor have been translated…