type-inferencing python

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
> Ex:
> def f(a): a.append(1)
> def g(a): a=a+1; f(a)
> g('coucou')
>
> => 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.