Home Original page

Adding static typing to Python

Alexander Jerusalem ajeru at vknn.org
Tue Feb 19 19:42:43 EST 2002 
Jeff Shannon <jeff at ccvcorp.com> wrote in message news:<3C72AB39.28618CC3 at ccvcorp.com>...
> Alexander Jerusalem wrote:
> 
> > 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.
> 
> In Python, you'd simply try to use the object in one way.  If that doesn't
> work, catch the exception and try the next.  Then you can clearly see what
> happens to different types of objects when you're applying the "same"
> operation to them.  You don't need to use multiple methods to have
> different behaviors, and at the same time, you don't have to add more
> methods when you add a new type that you want to behave the same as an old
> type...

Yes, IF I want it to behave the same as the old. And that's really a
good feature of dynamically typed languages. But if you want the new
method do something else for a different type then you're stuck. You
have to change the one existing method an add a new case.

> 
> 
> > 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.
> 
> This is exactly what Python does, except that it does it at runtime
> instead of compile time; and really, it is *not* any slower to test this
> than it is to try a couple of compile cycles.

>From my experience I can say it is much slower but maybe one has to
get used to this style of programming.

>  Plus, as has been
> previously noted, PyChecker will scan for most such errors if it's used...

Yes that was a very valuable hint. I have already downloaded PyChecker
and it's very useful.

Alexander
More information about the Python-list mailing list