[Python-3000] Sane transitive adaptation

[Tim Hochberg]

Guido van Rossum wrote:
> 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.

This is reason that I factored the signatures method out in my version 
of Protocol. With that factoring, it's a simple matter of replacing the 
signatures method with one that returns [type(x)] instead of 
x.__class__.__mro__. In one sense that may not gain you much over some 
custom decorators and a dictionary, but having a common interface for 
this sort of thing seems useful even if the implementation is not always 
shared.

However, it's not clear to me at the moment how the signatures thing 
fits in with the generic function implementation where the resolution 
method is more complicated. It may turn out that the correct factoring 
is just into __call__ and find_func as you have. That would mean that 
things like pickle would need to override find_func with something trivial.

> 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 thought the point of distributed protocols / generics was that each 
module could have it's own (or several should it so choose). Why would 
it be a problem for pickles registry to use a Protocol subclass as it's 
registry? The main thing you'd gain is an interface in common with other 
clients of Protocol, but that's no small thing.

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

Regards,

-tim