[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 09:34 AM 1/13/05 -0500, Clark C. Evans wrote:
>On Thu, Jan 13, 2005 at 10:35:39AM +0000, Paul Moore wrote:
>| One thing I feel is key is the fact that adaptation is a *tool*, and
>| as such will be used in different ways by different people. That is
>| not a bad thing, even if it does mean that some people will abuse the tool.
>|
>| Now, a lot of the talk has referred to "implicit" adaptation. I'm
>| still struggling to understand how that concept applies in practice,
>| beyond the case of adaptation chains - at some level, all adaptation
>| is "explicit", insofar as it is triggered by an adapt() call.
>
>The 'implicit' adaptation refers to the automagical construction of
>composite adapters assuming that a 'transitive' property holds.

Maybe some folks are using the term that way; I use it to mean that in this 
code:

    someOb.something(aFoo)

'aFoo' may be "implicitly adapted" because the 'something' method has a 
type declaration on the parameter.

Further, 'something' might call another method with another type 
declaration, passing the adapted version of 'foo', which results in you 
possibly getting implicit transitive adaptation *anyway*, without having 
intended it.

Also, if adapters have per-adapter state, and 'someOb.something()' is 
expecting 'aFoo' to keep some state it puts there across calls to methods 
of 'someOb', then this code won't work correctly.

All of these things are "implicit adaptation" issues, IMO, and exist even 
withoutPyProtocols-style transitivity.  "Duck adaptation" solves these 
issues by prohibiting per-adapter state and by making adaptation 
order-insensitive.  (I.e. adapt(adapt(a,B),C) should always produce the 
same result as adapt(a,C).)