[Python-3000] Math in Python 3.0

[Paul Moore]

On 5/14/06, Giovanni Bajo <rasky at develer.com> wrote:
> So, are we totally dropping the "special-cased __ method" that worked so fine
> till now? I can "overload" abs() for my point type (to return its modulus) just
> by defining a __abs__, and it works fine. In such a world (called Python 2.x),
> I wouldn't find so strange if I had a __sqrt__.

That's one of the arguments for function overloading - you can't add a
__sqrt__ method to types (e.g., float) that don't already have them,
so special __ methods are less flexible than overloading (which *can*
be defined externally to the argument's class).

Whether it's a sufficient benefit to justify (a) adding a function
overloading mechanism to the language/stdlib, or (b) changing existing
special methods to use overloading instead, is still undecided.

> It's just a different way of dispatching, in the end.

True.

> But I think that we should use a consistent way for, eg., all the math functions.

Possibly. But I can't see that it's plausible to add all the possible
math functions as special methods - __sqrt__, __log__, __sin__,
__tanh__, __arcsin__, ... how far do you go? So if you want
consistency, you're really arguing for function overloading. And
you're back to the question of whether the benefit is sufficient to
justify the extensive change in philosophy.

(FWIW, I like function overloading, and I'd love to see language or
stdlib support. I can see the arguments for using it in place of
existing special methods, but I'm nervous of the extent of that
change. If I had to decide *right now*, I'd go for adding overloading,
but retaining special methods where they are currently in use - a
"practicality beats purity" approach, but possibly too cautious for
Py3K where the idea should be to avoid worrying about legacy
issues.......)

Paul.