[Python-3000] Adaptation vs. Generic Functions

[Alex Martelli]

On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
    [excellent example, mostly snipped]

Just for when this will be published/blogged (as it deserves to be!),  
tiny nit:

>     if hasattr(obj, "__iter__"):
>         return obj.__iter__()
>     raise TypeError("Can't iterate over a %s object" %  
> obj.__class__.__name__)

I think we should check/get __iter__ from obj.__class__, not from obj  
itself (new style classes only take special methods from the type,  
not from the instance). This applies to other occurrences of this  
pattern later, too.

>     def register(self, T, A):
>         self.registry[T] = A

Why not accept more than one type (for the same adapter) at one gulp?

   def register(self, A, *Ts):
     for T in Ts:
       self.registry[T] = A

>     def __call__(self, T):
>         # This is invoked when a Protocol instance is used as a  
> decorator.
>         def helper(A):
>             self.register(T, A)
>             return A
>         return helper

And similarly here, take *Ts in the __call__ and pass it on to  
self.register.

> @AdaptingIterProtocol(list)
> def _AdaptingSequenceIter(obj):
>     return SequenceIter(obj)
>
> AdaptingIterProtocol.register(str, _AdaptingSequenceIter)
> AdaptingIterProtocol.register(unicode, _AdaptingSequenceIter)

So this could become

AdaptingIterProtocol.register(SequenceIter, list, str, unicode)

((no real need for the extra layer represented by  
_AdaptingSequenceIter, though you could use it, if you insisted, with  
all the types at one gulp.

> def AdaptingIter(obj):
>     return AdaptingIterProtocol.adapt(obj)

Similarly, in the name of cutting down useless layers,

AdaptingIter = AdaptingIterProtocol.adapt

seems preferable to me.


There seems to be an asymmetry in the functionality of adaptation and  
generics as presented: adaptation as presented supports a search on  
the mro but for one argument only, generics support N arguments but  
no mro search.  To enable closer comparison, we might have generics  
support 1 argument and mro search, too, just as to ensure the feature  
set is identical (they both can be extended, with different degree of  
difficulty no doubt, but 1 argument each, with or w/o mro search,  
seems to allow more direct comparison).


Alex