Adding static typing to Python

[Quinn Dunkan]

On 19 Feb 2002 00:59:42 -0800, Alexander Jerusalem <ajeru at vknn.org> 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

Or you can just look and see how the 'person' is used in the function.  If the
first statement is a 'o = db.by_id[person]' then you know it's an id.  If it
takes 20 lines to get to that point, maybe the function is too long.  If the
function merely passes 'person' to someone else, then the type of 'person'
doesn't matter (and the declaration that a static language (except ones infer
types automatically) would force you to make would merely reduce the
flexibility of the function).

If it's an object, why should you care at what exact position it lives in
some class hierarchy?  Isn't the point of dynamic dispatch that you don't
have to know?

>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

Yeah, python has this too:

class A:
    def m(self): print 'm'
class B(A):
    def m(self): print 'bm'
o = B()
o.m() #  B.m is called
p = A()
p.m() # A.m is called

It's only of the first argument, but that's what mono-dispatch means.
Static typing having anything to do with multi-dispatch is incorrect,
though.  The best-known object system with multi-dispatch is CLOS, which
is certainly dynamic.  In fact, I don't know any static languages that do
what you want (I'm not counting c++-ish "overloading" because it doesn't
dispatch based on the type of the variable, but the type of the declaration
(which, since you're forced to write out the declaration, you're not
gaining any flexibility or having to type less---so that's the point?)).

When you don't have multi-methods you get by with single dispatch.

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

Yep, it's called inheritance, and OO people go on and on about it :)

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

Oh yes, and dylan, another dynamically typed multi-method language.

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

Yeah, that sort of thing is nice.  I want more though... I want
to check if the parameter has what the symbols method needs, *and* that
those symbols do what the method wants.  For that, you need contracts
or something, which work at run time.  As long as you're working at
run time, you'll have to test it, so leave the contracts out and see
if it throws an error :)