Function override?

[David C. Ullrich]

Tim Peters wrote:

> [David C. Ullrich]
> > ...
> > 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.
>
> Yup, not to worry.  All proposals to date make static typing declarations
> optional, and by default not needed.

    Fine, I can sleep tonight.

    Or I could if I hadn't just read the bit about how in 1.6 strings
have a split method, and if s1 and s2 are strings then

s1.split(s2)

either splits s1 using s2 as the delimiter or the other way around,
depending on which occurs more frequently in the other. I mean
surely it will happen that we want to split a bunch of strings
using 'delimiter' as a delimiter, and then it just happens that
the routine that does that gets passed 'lim' as an argument and
does the opposite of what we want?

> [...]
>
> > 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.)
>
> This isn't a problem with static typing per se, provided the system is rich
> enough to let you define a suitable EuclideanDomain type.  The system is not
> rich enough today,

    Not all that important, but I'm missing something here. Why can't
we make a EuclideanDomain type? I've made a VectorSpace type,
for example.
    Oh. You meant a EuclideanDomain type instances of which
would be euclidean domains? In the sort of thing I've done
a _subclass_ of EuclideanDomain would be a euclidean domain,
instances of which are the elements.

> but people throughout this industry hold a charming faith
> that tomorrow's solutions won't suffer today's problems <wink>.
>
> just-a-fan-of-the-illusion-of-progress-ly y'rs  - tim