Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> (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.......)
>
> I don't think I've ever said it explicitly, but this is pretty much
> where I'm sitting at the moment on the function overloading front -
> support it, but have default implementations for various operations
> that fall back on the existing magic methods.
>
> After all, Py3k's informal motto is "get rid of the accumulated
> cruft" rather than "break the world". Getting rid of the magic
> methods is a bit too much of the latter for my liking :)
Well, but there's really no reason why I should use __abs__ to do one thing,
and an overloaded sqrt to do another. Py3k is where we can fix these things to
give consistencies. If we want a better numeric model for Python, __ special
reserved methods just don't scale. Under this point of view, __abs__ is a
design mistake which ought to be fixed.
Another issue I would like to bring up is that of performance. Using __ special
methods, dispatching can be done in constant time, since it's basically a
lookup on the operand's class. The various implementations of overloaded
functions I have seen require a linear-time lookup among overloaded functions.
I remember that OO programming was initially ignored (in the 70's) because it
was deemed to be too slow -- then somebody came up with the idea of the virtual
tables. It would be too bad to go backwards in this regard.
Thus another solution would be to use a dispatch similar of that of the magic
methods, but without the namespace issue ("__methods__ " are reserved of the
implementaiton IIRC). If it was "legal" to add a __sqrt__ (or similarly named
method), I wouldn't have problem with this approach.
Giovanni Bajo
_______________________________________________
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
