[Python-3000] Sane transitive adaptation

Fri Apr 7 12:52:26 CEST 2006

Phillip J. Eby wrote:
> At 02:15 PM 4/6/2006, Guido van Rossum wrote:
>> On 4/6/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>> > I don't want to discourage people from working out their own ideas,
>> > but a lot of the stuff that's being discussed here about protocol
>> > adaptation is already implemented in PyProtocols.
>>>> That's great. I believe that if we derive things from first principles
>> here and arrive at the same choices as PyProtocols, we haven't wasted
>> anybody's time;
>> I agree; that's why I said "I don't want to discourage people from 
> working out ... ideas". I just wanted to point out that for those who 
> prefer to learn from worked-out examples, there are some available. One 
> reason I like to steal designs from *built* systems is that making 
> something real forces lots of tradeoffs into the open, that don't come 
> up when you're just brainstorming.
>> That having been said, please consider this a "spoiler warning": the 
> rest of this message reveals where I think you're all going to 
> eventually end up. If it'll spoil anyone's fun and/or learning to know 
> this ahead of time, don't read the rest of this message. :)
>> Hint: premature optimization is the root of all evil. I was actually 
> trying to hint in my previous message that it would be valuable to learn 
> from PyProtocols' example by *not* repeating it! I was not suggesting 
> that PyProtocols is a model to which you should all aspire, but rather 
> consider why I wish I hadn't bothered to do it in the first place!

I've been stealing liberally from PyProtocols all along, usually trying to 
grasp ways to take *concepts* from it that I liked, and turn them into 
something that seemed *usable* (with aesthetics playing a large part in that).
That's why one of the first things I hit on in rereading PEP 246 was "hang on, 
why are we use a pair of ad hoc protocols to build an adaptation system"? And 
lo and behold, PyProtocols had a much easier to use system based on concrete 
protocol objects, where you manipulated the target protocol directly.
And my last message about adaptation, which was a (massively) simplified 
version of some of the ideas in PyProtocols, let me understand how 
transitivity would apply in a generic function context: you have function_A 
with a certain signature, and existing operations and function_B that can be 
implemented in terms of function_A. All there then needs to be is a way to 
tell function_B about it:
 @function_A.when_specialized
 def notify_function_B(signature, specialization):
 # Give function B a new specialization
 # based on the specialization in A
 # If the signatures are the same, then
 # we can just pass the info along
 function_B.specialize(signature)(specialization)
I have no idea whether providing a mechanism for that is a good idea or not, 
but the important point is that it covers the last thing that I understood how 
to do with protocols, but not with generic functions. And given that *normal* 
functions are already in the language as a fundamental building block, then it 
makes a lot of sense to explore how to make them generic.
I like being able to use 'signature' and 'specialization' as the terms, too, 
as they describe exactly what's going on. Further, if all builtin function 
objects (including C function descriptors and method wrappers) were 
potentially generic, then it would be possible to write:
@specialize(str).for_signature(SomeClass)
def str_SomeClass(obj):
 return obj.stringify()
The use of the "specialize" function (rather than invoking the method 
directly) then means that arbitrary callables can support specialization by 
defining it as something like:
def specialize(obj):
 return obj.__call__
@specialize.for_signature(type(specialize))
def specialize_function(func):
 return func
Cheers,
Nick.
-- 
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
 http://www.boredomandlaziness.org