[Python-3000] Adaptation: T->P vs P->P

[Michael Chermside]

Tim Hochberg writes:
> In this thread, Alex has been advocating adaption where types are
> adapted to protocols: T->P adaption for short. By contrast, my two
> sample implementations have involved Protocol->Protocol adaption
> [...] P->P adaption for short.

> However, there is a huge difference in scale here. A class will
> typically only satisfy a few protocols, whereas it could potentially be
> associated with many adapters. Similarly an adapter will typically be
> associated with only a single source protocol, but it may be associated
> with many, many types. Just to make this concrete, I imagine there will
> be many adapters that work on every sequence type

I may be misinterpreting what Tim is saying here, but it sounds like
this touches on the idea of *transitivity* in adaptation. That is, Tim
is proposing that there are a small number of "protocols", but I can't
tell the difference between a protocol and an adaption target so I am
taking them to be synonomous. I am (and have been for nearly 2 years...
Alex: your previous efforts at evangalism have not been *totally* useless)
a fan of adaption. But I am *deeply* concerned about introducing
transitive adaption where it is assumed that registering ((A B) f) and
((B C) g) implies ((A C) lambda x: f(g(x))

I have heard it argued previously (I apologize, but I forget who said this)
that if f *really* adapts A to B and g *really* adapts B to C, then their
composition must really adapt A to C, and I understand the mathematical
inevitability behind this statement. But I fear that in the real world
there are often subtle distinctions and corner cases that are ignored
for the sake of practicality which make such transitive adaption dangerous.
After all, a substantial portion of Python classes fail true to achieve
true Liskov substitutability despite this being a widely-understood
concept.

Okay... time for me to stop attacking a position (pro transitivity) that
no one has explicitly taken in this discussion and return to what Tim was
saying. He claims:
> let's define A=>B to
> mean "A needs to know about B". For T->P adaption:
>     T=>A or A=>T or P=>(A and T) or U=>(A and T and P)
> For P->P adaption:
>     T=>Psrc or P=>Psrc or U=>Psrc
>   Generally A can be assumed to know about Psrc, so I've left that out.

Tim's proposal (if I understand it correctly) depends on transitivity --
his idea is to have the class authors register as satisfying a small
number of widely-known protocols (Psrc in his case), then use transitivity
to infer ways to satisfy less well-known protocols. This is a tempting
game... it avoids having to have even a third party know about both the
type and the protocol to be satisfied. But I would rather FORCE someone
(even a third party) to at least glance at the specific case and
reassure us that it works. If the individual wants to do a quick and
sloppy job rather than a careful one, then it is reduced to a question
of whose libraries I trust, which I a problem I understand how to handle.

To return to the example that we used previously in this thread, it seems
that creating an __index__ special method would not be necessary if
adaption were in place... we could instead ask classes to register an
adapter to the "python.as_index" protocol. But if we were to infer that
anything satisfying "python.as_int" necessarily satisfied "python.as_index",
then we would have defeated the purpose of the feature.

One last point: it is entirely possible that I have misunderstood
completely. If so, please gently explain why.

-- Michael Chermside