Adding static typing to Python

[kosh at aesaeion.com]

On 19 Feb 2002, Alexander Jerusalem wrote:

> 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.
>

Overall I have found that the longer I use python the less I care about
types overall. I have been writing stuff that cares more about the
capability of an object to act in a certain way. For example I don't care
if something is actually a list object I might just need to check if it
can be sliced. Or in other cases I have a function that will call a method
of an object passed in if it has that method. Overall I find myself doing
a fair bit of

if hasattr(self, 'methodname'):
 self.methodname()

This makes the code easy to extend and I think it makes the intent more
clear. Since in the function you see what feature is being used and no
longer care about what kind of object it is. I also use refactoring pretty
heavily and my functions tend to be about 3-5 lines on average. The
functions encapsulate a purpose. I name the function for the purpose,
provide a docstring to further cover that purpose then implement just
that. If I find I have several purposes in one function I break it into
more functions even if some of the functions are only one line since it
makes the intent far more clear.

Overall I find this style makes debugging far cleaner and easier to do. I
also use a simple logging function so that at any time I can stick it in
somewhere and get the state of what is going on which works very well.
This also eliminates most temporary variables which tend to be the items
that are mistyped the most. Overall I think static typing is good for one
style of programming however other styles work very well aso. Dynamic type
checking works very well with refactoring and using items based on
capabilities.

> 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.
>

Overall I used to think that was useful when I first started using python
from a fair bit of C++ experience. However as time went on I found that
less and less useful until I just don't write things that need that
anymore. I think you feel a need for a feature not because the feature is
a good one or needed but because that is what you are used to. Same way
that many python newbies make large strings by adding up lots of little
strings. Depending on how many items you are adding together this can be
thousands of times slower then putting the strings in a list and doing a
join when you have all of them.

> 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...

It seems to me that the ammount of time you spend debugging a language is
directly related to how much you fight it compared to how much you work
with it. When you treat every tool like a hammer then you notice that some
tools are better hammers then others. Overall a wrench might make a decent
hammer but that does not make it a hammer. What I see a fair bit of is
your interest in using python like a hammer becuase you know hammers from
java and C++ instead of using it like a screwdriver. Not to say that one
is different from the other just that they are different and need to be
used differently. The part where this analogy breaks down is that they can
both do the same things just in a different way.