Adding static typing to Python

[gbreed at cix.compulink.co.uk]

Quinn Dunkan wrote:

> >But you can do that in Python:
> >
> >>>> def area(shape):
> >...   if isinstance(shape, Circle):
> >...     return math.pi*shape.radius**2
> >...   if isinstance(shape, Rectangle):
> >...     return shape.width*shape.height
> >...   if isinstance(shape, Square):
> >...     return shape.width**2
> >...   raise TypeError, "unknown shape"
> >...
> 
> This kind of giant typecase is exactly the sort of thing that OO is 
> supposed
> replace.

Yes, but then are overloaded functions "OO" either?

> >                                                     As for strict, 
> >strong, static, explicit typing (which may be a straw man) it looks 
> *less* >suitable for this example.

Note I did say "explicit" there.

> >You could make them all subclasses of Shape.  In which case, you have 
> >functions defined to use a polymorphic object that depend on function 
> >overloading by the real type.  Not all statically typed languages will 
> >allow that.
> 
> C++ requires special keywords for it, but all statically typed OO 
> languages I
> know of do dynamic dispatch.  I certainly don't know every static 
> language out
> there, but just because there's a limited implementation somewhere 
> doesn't
> mean the concept is unworkable :)

In Java, you need the same kind of "giant typecase" as in the Python 
example you objected to.  I think C++ works the same way, unless you use 
templates.  If I understand "dynamic dispatch" correctly, that's dynamic 
typing by the back door, so not much of an argument for static typing.

> >             If they do, you have the problem that you might have 
> > added >triangles for some other reason, and forgotten to cater for 
> them in >area().  You aren't getting static type checking at all.
> 
> Sure you are.  area will reject objects that don't have the proper 
> methods
> defined for them.  How it works in haskell is that each class has a 
> minimum
> interface that you must implement.  If you don't implement all the 
> methods
> of the Shape class, Shape-accepting functions won't accept your objects.
> This is less flexible than having to implement *only* the methods the
> function actually uses, as in python, but c++ templates are sorta like 
> that.

If the types have to be resolved at runtime, you aren't getting static 
type checking.  What you describe is called "genericity" right?  I wasn't 
thinking of that, and I did specify "explicit" above to exclude it.  AIUI, 
Haskell does static, implicit typing and so long as everything's 
statically compiled that gets you the same convenience as dynamic typing.

The proposed language changes for "optional static typing" all specify 
types explicitly.  A more productive approach may well be "how do we alter 
the language so that type inference can work?"  That may be why slots got 
added.

> >Wouldn't it be better to make area a method of the shapes?  And for 
> static >typing, make it abstract in the Shape class?
> 
> In your above example, that's what it is.  You're just spelling 
> 'circle.area()'
> as 'area(circle)'.

No, circle.area() and area(circle) mean very different things in Python, 
so none of your comments on circle.area() really apply to area(circle).

> I actually like the second better, because lets you do things like
> 'map(area, shapes)' instead of 'map(lambda o: o.area(), shapes)', as 
> well
> as multi-dispatch, and eliminates the 'len(o)' vs 'o.len()' thing.  It 
> also
> has other benefits like letting you define a method anywhere you want 
> which
> obeys the usual scoping rules (so you can add a 'frobbify' method to the
> string class, but not have to worry about it making a global change for
> everyone in all modules).

That's a matter of taste, but you can get area() to work much the same way 
Python implements len(), as

def area(shape):
  return shape.__area__()

which still uses polymorphism rather than operator overloading.  (Time for 
a definition of "polymorphism"?)

> I'm not even sure why the smalltalk style 'object followed by method' 
> notation
> caught on, especially since 'function followed by args' has always been
> firmly entrenched.

It happens to match the usual English word order: "the class's method" 
rather than "the method of the class".  If the field had been dominated by 
French speakers, perhaps it would have been the other way round.



                     Graham

         <http://www.microtonal.co.uk/>