Tuesday, December 28, 2004

Optional Static Typing in Python

Guido van Rossum talks about Adding Optional Static Typing to Python. Here is my take on it.

about "Compile Time vs. Run Time".

I 'd be completely happy if the type check would be performed at run-time, not on compile time or import time. After all, that's how a Python developer expects the things to be.

You may argue that's this doesnt buy you much but I disagree. ;-)

Firstly, it's a first and logical evolution from the current state of affairs. Secondly, it does provide some tangible benefits.

Currently, many developers are used to write something like this:

def foo(g,a):
assert isinstance(a, str), a
assert callable(g)

Strictly speaking, these assertions are not required, but they do help to detect errors as early as possible which is a sound engineering practice.

With the help of type interferencing or manifest typing we could free programmer from this tedious work, if he wants to.

Duck typing

What I really wanted to see in Python is an explicit support of DuckTyping, which is an integral part of type system anyway. The problem is IMO with a reasonable and helpfule implementation.

For some, a type interferencing (a sketch from the Haskell type system) may help. For instance if the foo() takes parameter a and then invokes method bar() on that parameter, compiler (or VM) could check (at least, at run-time) that the argument passed to foo() does have a callable bar attribute.

This also can be extended on operator overloading, such as __add__ or __lshift__.

And my point is, even with such a limited form (run-time checking of automatically derived type information), it could be a big step forward.

Optional type annotation (embedded in the source code) could be a next step.


Post a Comment

<< Home