Adding static typing to Python

Alexander Jerusalem ajeru at vknn.org
Tue Feb 19 03:59:42 EST 2002


The argument that exhaustive testing should be done anyway is
certainly true. I nevertheless tend to think that it's better to let
the compiler do as much as possible in terms of error checking and
then use testing to find the true runtime errors. It just takes much
less time than starting a test run every time just to find all my
typos. I don't know if there are test suites that let you run all the
branches of all your methods and show you all typos at a time. I
suspect that I'd have to start the test suite for each and every typo
but I'm not knowledgable enough when it comes to Python test suites to
be sure of that claim. I'm gonna look at what PyChecker can do for me.
Thanks for the tip.

There's another thing that bugs me with the missing static typing and
that is that it makes code less readable. I don't know what I can do
with a function parameter when I see it. For example, when I see a
function like def computeSalary(person)... I don't know at first sight
if person is the id of person, a person object and if it's an object
what its exact class in a Person class hierarchy is. I have to find
the place where the constructor is called to find that out. That's not
a big problem for small programs but if I have many classes that use
inheritance, it's really not easy to figure out what interface a
parameter actually supports. This is, however, a minor problem if
everyone on the team agrees to document parameter types in the doc
string. The language doesn't enforce it though.

And the final argument I have for static type checking is that it
enables method dispatching based on parameter types. In a statically
typed language you can create two methods that have the same name but
differ on the parameter types. The correct method will be called for
you depending on the type of the argument you pass in your call. That
makes for a quite flexible way of extending a program. You can just
add another method with the same name and another type to handle a
special case without touching the existing methods.

I think type checking could be added as an optional feature, like in
Dylan, without hurting the character of Python.

I'm currently using Python to write generators that produce Java code
from an XML representation. So the runtime system is type checked by
the Java compiler anyway. I tried to do the generator in Java first
but the text processing capabilities of Java are just terrible, so I
came to use Python and I like it for many reasons. It's just that I'm
using much more time on debugging than I used to in Java where I
didn't have to care too much about typos because the compiler
complained anyway...

I'm not, however, completely satisfied with static type checking as
well because I don't see why the compiler forces me to have a
parameter comply with a static interface that has 10 methods when the
method that uses the parameter acutally only uses one of those
methods. I want the compiler to check if the parameter type I'm
passing has what the method needs but nothing more.

Actually languages that support templates or generics or however
parameterized types are called in different languages, do just that.
They generate a method for the type that's actually used in a method
call if they see that the type has everything the method needs. I
liked C++ templates (and some other features in C++) but I don't use
C++ anymore because its lack of garbage collection makes it much less
productive than other languages.

Regards,
Alexander Jerusalem



More information about the Python-list mailing list