Adding static typing to Python

Huaiyu Zhu huaiyu at
Tue Feb 19 20:17:35 CET 2002

On Tue, 19 Feb 2002 15:44:09 GMT, Nick Mathewson <QnickQm at>
>Making a real static type system is harder than you'd think.
>Consider this function:
>def fn(lst,item):
>   for i in lst:
>     if i == item:
>        return repr(i)
>What is the type of fn?  You could call it:
>     (list[int], int) -> str
>But then you'd lose the polymorphism of the function.  To a first
>approximation, you might say:

[snip excellent analysis of need of polymorphism]

>IMNSHO, some kind type inference is the only tractable answer.

This is an excellent point.  A static typechecking system added to Python
will be overly restrictive unless it has the power of polymorphic type
systems found in some functional programming languages (ML, Haskell).

To further expand on this point, a full typechecking system in this example
must be able to handle the following type semantics:

fn :: I(A), B -> str where:

    # These can be inferred automatically by type checker
    I in Iter
    (A, B) in Eq
    A in Repr

    # These can be imported as standard Python design interfaces
    typeclass Iter(I): I(A) => (def I(A).next() :: A) and (raises StopIteration)
    typeclass Eq(A, B): def A.__eq__(B) :: bool
    typeclass Repr(A): def A.__repr__() :: str

It is not necessary to write all these on the spot --- predefined
typeclasses can be imported.  And it is not necessary to make all of them
explicit --- much can be derived automatically using type inference as in ML
or Haskell.  But the point is that a whole new set of mechanisms must be
developed to represent and handle such type semantics.

Such a system would certainly be marvelous to have.  It is certainly doable.
It is likely to be difficult.  Sounds like a good candidate for a
challenging project.


More information about the Python-list mailing list