[Python-Dev] PEP 246, redux

[Alex Martelli]

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!

Say I have an SQL DB with a table such as:

CREATE TABLE fullname (
     first VARCHAR(50) NOT NULL,
     middle VARCHAR(50),
     last VARCHAR(50) NOT NULL,
     -- snipped other information fields
)

Now, I need to record a lot of names of people, which I get from a vast 
variety of sources, so they come in as different types.  No problem: 
I'll just adapt each person-holding type to an interface which offers 
first, middle and last names (as well as other information fields, here 
snipped), using None to mean I don't know the middle name for a given 
person (that's what NULL means, after all: "information unknown" or the 
like; the fact that fullname.middle is allowed to be NULL indicates 
that, while it's of course BETTER to have that information, it's not a 
semantic violation if that information just can't be obtained nohow).

All of my types which hold info on people can at least supply first and 
last names; some but not all can supply middle names.  Fine, no 
problem: I can adapt them all with suitable adapters anyway, 
noninvasively, without having to typecheck, typeswitch, or any other 
horror.  Ah, the magic of adaptation!  So, I define an interface -- say 
with arbitrary syntax:

interface IFullname:
     first: str
     middle: str or None
     last: str
     # snipped other information fields

and my function to write a data record is just:

def writeFullname(person: IFullname):
     # do the writing


So, I have another interface in a similar vein, perhaps to map to/from 
some LDAP and similar servers which provide a slightly different set of 
info fields:

interface IPerson:
     firstName: str
     lastName: str
     userid: str
     # snipped other 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.


If the datatypes are immutable, conversion is as good as adaptation 
here, as I mentioned ever since the first mail in which I sketched this 
case, many megabytes back.  But adaptation I can get automatically 
WITHOUT typechecking on what exactly is the concrete type I'm having to 
write (send to LDAP, whatver) this time -- a crucial advantage of 
adaptation, as you mention in the PyProtocols docs.  Besides, maybe in 
some cases some of those attributes are in fact properties that get 
computed at runtime, fetched from a slow link if and only if they're 
first required, whatever, or even, very simply, some datatype is 
mutable and I need to ensure I'm dealing with the current state of the 
object/record.  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.


Alex