On 5/14/06, Giovanni Bajo <[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
