[Python-3000] Adaption & generic functions [was Generic functions]

[Ron Adam]

Paul Moore wrote:
> On 4/7/06, Eli Stevens (WG.c) <listsub at wickedgrey.com> wrote:
>> It seems to me that now to get a duck-typed list, not only do you have
>> to implement all of special methods that define "listy-ness," you also
>> have to find the overloaded functions that are specialized for lists,
>> and register your own implementation (or an implementation specialized
>> for lists, if appropriate).
> 
> Thanks for raising this - I have similar concerns, but I hadn't
> managed to focus them well enough to explain. This is exactly what has
> been bugging me.
> 
> Paul.

I haven't looked at the actual posted examples yet so this is more an 
overview of issues as I see them.  I tend to lag in these more technical 
threads, but here's the way I understand it so far.

In the sane transitive adaption thread I made the comment that there may 
be a relationship between identifying "logical equivalence" and 
adaptation, although I didn't explain what I meant by that.

First of all, weather your source object and your destination object 
have all the same methods or not isn't an issue.  In fact if they did, 
you wouldn't need to adapt anything as duct typing would just work.

What is an issue is that the data they contain is translatable.  Using 
tuples and lists as an example:

     (1,2,3) == [1,2,3]  ->  False;   They are not equivalent.

But the data they contain is the same, and you can convert from one to 
the other without any loss.  So you can say they are logically equivalent.

     A to B; B to C; and A == C

     (1,2,3) <=> [1,2,3]  -> True;  They can be translated.

Python already treats tuples and lists as interchangeable in many cases. 
They have one to one data mapping and they share methods that have the 
same names and function.  So duck typing works in many cases as is.

But what if they didn't map to each others data one for one, and/or had 
different methods?  They could still be "logically equivalent", but 
simple duck typing wouldn't work, so you would need something more than 
duck typing, ie.. an adapter, or a library factory functions, or have 
each type be able to read every other type.

The first option adaptation could be just be a wrapper that substitutes 
matching method names and/or acted as a go between to allow an object to 
temporarily gain matching methods so duck typing would work on it.

The second option actually creates object B from object A.

Both of these need some sort of interface to choose the correct adapter 
or converter.

The last one, having every object know how to read every other 
"logically equivalent" object just isn't practical.  But that doesn't 
mean it can't act as if it can by calling a some common framework.

The "logically equivalent" requirement only applies to implicit 
adaptation.  With explicit (on request) adaptation, it could be assumed 
that it is understood the result may not be reversible or may loose some 
data as in converting floats to ints.

The real difficulty is in how to implement these concepts in a way that 
can be extended and be useful in a broader range.  An adapter need not 
implement every method, but only needs to provide mappings to methods 
that are missing and/or are different between two objects.  Those 
methods could reside in a common library and be identified dynamically 
as they are needed or they could be pre-identified and registered as 
sets for known objects.

Ideally once a library of adapter mappings is in place, creating and 
adding new adapters wouldn't be that hard as many of the preexisting 
methods could be reused.

This is about as far as I've gotten so far, so I'll have to leave 
anything I missed or misunderstood to the experts and keep trying to 
follow along as they try out the different ideas.  :-)

Cheers,
    Ron