[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 07:04 PM 1/12/05 +0100, Alex Martelli wrote:

>On 2005 Jan 12, at 18:58, Phillip J. Eby wrote:
>    ...
>>>I have some data about people coming in from LDAP and the like, which I 
>>>want to record in that SQL DB -- the incoming data is held in types that 
>>>implement IPerson, so I write an adapter IPerson -> IFullname for the purpose.
>>
>>This doesn't answer my question.  Obviously it makes sense to adapt in 
>>this fashion, but not IMPLICITLY and AUTOMATICALLY.  That's the 
>>distinction I'm trying to make.  I have no issue with writing an adapter 
>>like 'PersonAsFullName' for this use case; I just don't think you should 
>>*register* it for automatic use any time you pass a Person to something 
>>that takes a FullName.
>
>I'm adapting incoming data that can be of any of a huge variety of 
>concrete types with different interfaces.  *** I DO NOT WANT TO TYPECHECK 
>THE INCOMING DATA *** to know what adapter or converter to apply -- *** 
>THAT'S THE WHOLE POINT *** of PEP 246.  I can't believe we're 
>misunderstanding each other about this -- there MUST be miscommunication 
>going on!

Indeed!

Let me try and be more specific about my assumptions.  What *I* would do in 
your described scenario is *not* register a general-purpose IPerson -> 
IFullName adapter, because in the general case this is a lossy adaptation.

However, for some *concrete* types an adaptation to IFullName must 
necessarily have a NULL middle name; therefore, I would define a *concrete 
adaptation* from those types to IFullName, *not* an adaptation from IPerson 
-> IFullName.  This still allows for transitive adapter composition from 
IFullName on to other interfaces, if need be.

IOW, the standard for "purity" in adapting from a concrete type to an 
interface can be much lower than for adapting from interface to 
interface.  An interface-to-interface adapter is promising that it can 
adapt any possible implementation of the first interface to the second 
interface, and that it's always suitable for doing so.  IMO, if you're not 
willing to make that commitment, you shouldn't define an 
interface-to-interface adapter.

Hm.  Maybe we actually *agree*, and are effectively only arguing 
terminology?  That would be funny, yet sad.  :)


>>>   So, I'm not sure why you appear to argue for conversion against 
>>> adaptation, or explicit typechecking against the avoidance thereof 
>>> which is such a big part of adapt's role in life.
>>
>>Okay, I see where we are not communicating; where I've been saying 
>>"conversion", you are taking this to mean, "don't write an adapter", but 
>>what I mean is "don't *register* the adapter for implicit adaptation; 
>>explicitly use it in the place where you need it.
>
>"Adaptation is not conversion" is how I THOUGHT we had agreed to rephrase 
>my unfortunate "adaptation is not casting" -- so if you're using 
>conversion to mean adaptation, I'm nonplussed.

Sorry; I think of "noisy adaptation" as being "conversion" -- i.e. I have 
one mental bucket for all conversion/adaptation scenarios that aren't "pure 
as-a" relationships.


>Needing to be explicit and therefore to typechecking/typeswitching to pick 
>which adapter to apply is just what I don't *WANT* to do, what I don't 
>want *ANYBODY* to have to do EVER, and the very reason I'm spending time 
>and energy on PEP 246.  So, how would you propose I know which adapter I 
>need, without spreading typechecks all over my bedraggled *CODE*?!?!

See above.  I thought this was obvious; sorry for the confusion.

I think we may be getting close to a breakthrough, though; so let's hang in 
there a bit longer.