[Python-Dev] PEP 246, redux

Phillip J. Eby pje at telecommunity.com
Wed Jan 12 20:06:51 CET 2005


At 10:16 AM 1/12/05 -0800, Guido van Rossum wrote:
>For example, inteface B (or perhaps this should be a property of the
>adapter for B->C?) might be marked so as to allow or disallow its
>consideration when looking for multi-step adaptations. We could even
>make the default "don't consider", so only people who have to deal
>with the multiple A's and/or multiple C's all adaptable via the same B
>could save themselves some typing by turning it on.

Another possibility; I've realized from Alex's last mail that there's a 
piece of my reasoning that I haven't been including, and now I can actually 
explain it clearly (I hope).  In my view, there are at least two kinds of 
adapters, with different fidelity requirements/difficulty:

    class     -> interface  ("lo-fi" is okay)
    interface -> interface  (It better be perfect!)

If you cannot guarantee that your interface-to-interface adapter is the 
absolute best way to adapt *any* implementation of the source interface, 
you should *not* treat it as an interface-to-interface adapter, but rather 
as a class-to-interface adapter for the specific classes that need 
it.  And, if transitivity exists, it is now restricted to a sensible subset 
of the possible paths.

I believe that this difference is why I don't run into Alex's problems in 
practice; when I encounter a use case like his, I may write the same 
adapter, but I'll usually register it as an adapter from 
class-to-interface, if I need to register it for implicit adaptation at all.

Also note that the fact that it's harder to write a solid 
interface-to-interface adapter naturally leads to my experience that 
transitivity problems occur more often via interface inheritance.  This is 
because interface inheritance as implemented by both Zope and PyProtocols 
is equivalent to defining an interface-to-interface adapter, but with no 
implementation!  Obviously, if it is already hard to write a good 
interface-to-interface adapter, then it must be even harder when you have 
to do it with no actual code!  :)

I think maybe this gets us a little bit closer to having a unified (or at 
least unifiable) view on the problem area.  If Alex agrees that 
class-to-interface adaptation is an acceptable solution for limiting the 
transitivity of noisy adaptation while still allowing some degree of 
implicitness, then maybe we have a winner.

(Btw, the fact that Zope and Twisted's interface systems initially 
implemented *only* interface-to-interface adaptation may have also led to 
their conceptualizing transitivity as unsafe, since they didn't have the 
option of using class-to-interface adapters as a way to deal with more 
narrowly-applicable adaptations.)



More information about the Python-Dev mailing list