Function override?

[Eric Jacobs]

In article <38E4D7A4.4C83CFF7 at math.okstate.edu>,
"David C. Ullrich" <ullrich at math.okstate.edu> wrote:
>     I was surprised to see the other two replies didn't say what
> I would have said, so maybe what I would have said is "wrong":
> 
>     One thing that makes Python more fun than C is that the
> variables are typeless (their values have types). So you can
> use just one function:

Well, C is not a very good example of a type system to begin
with.

The argument to be had is that the variables are typed, just
not explicity so. They're typed implictly by the way the
program uses them. For instance, if a program invokes
abs(x), it doesn't make sense for x to contain any object
that does not implement number protocol. So, a variable is
typed, informally.


> class over:
>     def somefun(self, bakeThing):
>         if type(bakeThing) == type(1):
>             #do the int thing
>         elif type(bakeThing) == type(''):
>             #do the string thing
> 
>     This is certainly one of the things that _I_ find keen,
> amyway - I hope the people who are talking about adding
> stricter typing to Python make it optional somehow. There
> are obvious advantages to stricter typing but you lose
> something as well. (For example, I get a big kick out of
> the fact that exactly the  same euclidean-algorithm code
> works to find the GCD of two integers or the GCD of
> two polynomials. Etc.)

The ability to deal with objects at different levels of
abstraction is one of the cornerstones of object-oriented
programming, and a very important part of Python. It's
interesting that you mention that, though, because the
example method you just gave provides a perfect example of
how the current typing system can cause problems. After all,
could somefun() take a polynomial object? Not without its
author knowing about it beforehand; which limits the power
of allowing multiple types in.

Maybe someday we'll have something like:

           if bakeThing.as(types.Number):

Until then, be very careful when thinking about doing manual
dispatch on types, and especially "overloading". I would
prefer to code the above as two different methods. It could
end up saving some trouble, and preserving flexibility.