[Python-3000] Sane transitive adaptation

[Guido van Rossum]

On 4/8/06, Talin <talin at acm.org> wrote:
> You know, on the one hand, I've been reading this thread, and I'm
> excited about the possibility of generic functions (dynamic dispatch,
> duckaplex-typing, whatever you want to call it), but at the same time
> I kind of wonder about the eventual effect on the language.
>
> For example, it seems to me that most of the various magic methods,
> such as __cmp__, __add__, etc. would be better done with generics,
> especially since it gives you much finer control over the type of
> the other argument. So instead of having to write:
>
> class X:
>    def __cmp__( self, other ):
>       if isinstance( other, X ):
>          return cmp( self.something, other.something )
>       return NotImplemented   # or raise TypeError or whatever
>
> Instead you can just write:
>
> @generic( X, X )
> cmp( a, b ):
>    return cmp( a.something, b.something )
>
> Similarly, if you add an integer to a string, the overloading machinery
> will report the error, instead of having to check it manually in the __add__
> method.
>
> The addition of a funamentally new method of control flow - especially
> one that is a superset of an existing control flow method - is
> something that could potentially ripple through all of the standard
> libraries, transforming them beyond recognition. Given the obvious
> advantages, it would be hard to justify sticking with the older methods
> of doing things.
>
> While that's cool and I would look forward to working with them, I
> recognize that there are some downsides.
>
> For one thing, if generic functions are used in a way that truly leverages
> their potential, the structure of the code is going to be so different from
> 2.x that there won't be any possibility of automated migration - unless
> you decide up front that the use of generics is going to be restrained and
> controlled, at least initially.
>
> Personally I'm fine with breaking from the past. But I wanted to point
> out what some of the potential consequences would be.

Right. I don't want to overdo it; I was thinking of making overloading
available to frameworks that need it, by importing it from some
library module, but not trying to use it for all those things for
which we already have working solutions (like binary operators).

Last night I looked into using overloading to replace the mess that is
pickle. Unfortunately, an immediate problem is that overloading (at
least my current implementation, and also e.g. Phillip Eby's dynamic
dispatch code; and I believe also adaptation) is based on subclassing.
However, pickle is very careful not to use the same code for pickling
subclasses -- because (at least for primitive types like int) the
pickled representation is so efficient that it has no way to represent
the subclass information (even if it's only a class name). The pickle
module could use a style overhaul to use decorators, but I don't think
it should giveup its own registry mapping types to methods.

I suspect many other current uses of dispatch dictionaries (copy_reg,
for example) will have similar issues.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)