[Python-3000] Adaptation [was:Re: Iterators for dict keys, values, and items == annoying :)]

[Alex Martelli]

On Apr 1, 2006, at 10:52 AM, Tim Hochberg wrote:
    ...
> overengineered examples that make my brain lock up. Someone who knows
> something about adapters needs to go off and come up with the worlds
> simplest, most light weight, dumb as a post, adapter proposal. It may

Heh, funny -- that's basically what I tried to do in my post,  
composed no doubt at the same time you were composing this; and my  
"proposal" (more of an "explanation", really) shares many aspect with  
yours, such as the concept of protocol/descriptions being somewhat  
arbitrary (but hashable) "tags" relying entirely on conventions  
(human readable descriptions of constraints) without enforcement.

> I'm assuming that sticking the above six lines in a file somewhere
> wouldn't be sufficient for some reason, but if not, why not? And  
> what's
> the simplest possible proposal that would work?

The simplest possible proposal that would do some good would look  
very similar to yours, and mine, net of minor factoring issues.  If  
adaptation was available in Python's standard library and used  
reasonably widely within it, that would kickstart its wide adoption.

I'm quite ready to discuss the various reasons which make these  
levels of proposals/explanatioms not really optimal for real-world  
adoption; I mentioned such reasons repeatedly in my post.

For example, we could start with a fundamental inheritance issue: if  
there's an adapter registered from type T to protocol P, should I  
really register it again if I subclass T into S -- shouldn't S just  
inherit the adaptation from T (since that's what's wanted most often,  
when inheritance is used in a properly Liskovian way to assert that  
each S is-a T), at least as the default behavior, perhaps with the  
possibility to override when needed -- by registering a different  
adapter specifically from S to P, of course -- perhaps a cannot_adapt  
one, such as:

def cannot_adapt(*whocares):
     raise CannotAdaptError

If "inheritance of adaptation" is desired, it can be done in at least  
two ways: by having adapt loop on the MRO and checking each, or by  
having the metaclass look for all adapters of bases and registering  
what it finds.  The first strategy might be augmented by caching/ 
memoizing: if an adapter is found for some type that's in the MRO but  
not in first place, before returning it, adapt could explicitly  
register that so that future lookups will be much faster.  But then  
we need to decide what happens to this 'cache' when some different  
adapter gets registered for a base type...

Such need to dwell on practical details is not special to adaptation,  
of course: if Python didn't have the concept of a mapping and we were  
trying to develop one, the development from "cool abstract idea with  
a simple-as-dirt reference implementation" to "real-world precious  
tool" would be even more torturous;-).  We could start with "a list  
of key/value pairs" (a ``property list'' kind of thing), then have to  
deal with performance issues, uniqueness, handy auxiliary  
methods, ...;-).


But the usefulness of adaptation doesn't entirely depend on the ways  
all such issues are brought up and resolved... even a dirt-simple  
approach would be better than nothing (except perhaps for standing in  
the way of future improvements along the various axes -- error- 
checking, performance, handiness, ... -- so, the detailed behavior of  
such a first-cut, extra-simple approach should probably be carefully  
left underspecified, if it were to be adopted, to allow for future  
improvements;-).


Alex