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.
Two friends of mine were pretty enthusiastic about the Go language, so I tried writing a program in it yesterday. It is frustrating because despite…
I actually was toying with making something like Vala back in college. It's pretty cute. Much like using the sane subset of C++, as you write code…
This weekend I wrote some Emacs Lisp to write some utility functions I find useful for hacking on Chromium. It's fun to have a reason to use Lisp!…