[Python-Dev] PEP 246, redux (original) (raw)

Phillip J. Eby pje at telecommunity.com
Wed Jan 12 18:58:38 CET 2005

At 06:18 PM 1/12/05 +0100, Alex Martelli wrote:

On 2005 Jan 12, at 17:40, Phillip J. Eby wrote:

At 04:36 PM 1/12/05 +0100, Alex Martelli wrote: I already know -- you told us so -- that if I had transitivity as you wish it (uncontrollable, unstoppable, always-on) I could not any more write and register a perfectly reasonable adapter which fills in with a NULL an optional field in the adapted-to interface, without facing undetected degradation of information quality by that adapter being invisibly, uncontrollably chained up with another -- no error message, no nothing, no way to stop this -- just because a direct adapter wasn't correctly written and registered.

But why would you want to do this, instead of just explicitly converting? That's what I don't understand. If I were writing such a converter, I wouldn't want to register it for ANY implicit conversion, even if it was non-transitive! [snip lots of stuff] 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.

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.

More information about the Python-Dev mailing list