Adding static typing to Python

[Alexander Jerusalem]

quinn at yak.ugcs.caltech.edu (Quinn Dunkan) wrote in message news:<slrna758ng.d1u.quinn at yak.ugcs.caltech.edu>...
> >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.

No I can't do that if there's an inheritance hierarchy involved and
the function uses only methods that are already included in a base
class. If I want to add some piece of code to the function that uses
the more specialized properties of the parameter class, then I have to
go look at the constructor. There's no other way in this case.

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

Sometimes I don't want to know but sometimes I have to know. That
depends on if I want to use it polymorphically or if I want to use the
specific features of some class in the hierarchy.

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

I didn't mean inheritance based dispatching.

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

In Python, I can't have two functions with the same name that are
selected on the basis of their parameter types. I don't know CLOS very
well but if you can't declare the function parameters, I wouldn't know
how a dynamic type system at runtime would choose to which of the
existing functions it should dispatch. How do you define multimethods
in CLOS?

> 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 :)

No. I think inheritance based dispatching is rather limited. It makes
systems inflexible because you have to have just one type hierarchy
and there's no complex system that can be expressed in a single class
tree. That's something the philosophers recognised a long time ago.

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

Yes I like some features in Dylan including multimethods but Dylan
isn't in very broad use and there are many features I like better in
Python. Why not add  the good features of other languages to Python if
they don't break anything?

> 
> >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 :)

Ok, I get what your opinion is. Check everything at runtime. I
disagree :-)

Alexander