Adaptation and typecasting (was Re: [Python-Dev] replacing 'global')

Phillip J. Eby pje at
Tue Oct 28 16:36:42 EST 2003

At 09:55 PM 10/28/03 +0100, Alex Martelli wrote:
>On Tuesday 28 October 2003 07:47 pm, Phillip J. Eby wrote:
>    ...
> > You didn't actually give any example of why 'adapt("23",int)' shouldn't
> > return 23, just why adapt("foo",file) shouldn't return a file.
>Which is sufficient to show that, IN GENERAL, adapt(x, sometype)
>should not just be the equivalent of sometype(x), as you seemed (and,
>below, still seem) to argue.

I'm not arguing that, nor have I ever intended to.  I merely questioned 
your appearing to argue that adapt(x,sometype) should NEVER equal sometype(x).

>It borders, I think, on the absurd, to maintain that, for example,
>"<open file '/goo/bag', mode 'r' at 0x402cbae0>" *IS* my open file
>object "adapted to" the string protocol.  It's clearly a mere human
>readable representation, a vague phantom of the object itself.  It
>should be obvious that, just as "adapting a string to the (R/O) file
>protocol" means wrapping it in cStringIO.StringIO, so the reverse
>adaptation, "adapting a file to the string protocol", should utilize
>a wrapper object that presents the file's data with all string object
>methods, for example via mmap.

Great, so now you know what you'd like file.__conform__(str) to do.

This has nothing to do with what I was asking about.  You said, in the post 
I originally replied to:

"y=adapt("23", int) should NOT succeed."

And I said, "why not?"

This is not the same as me saying that adapt(x,y) for all y should equal 
y(x).  Such an idea is patently absurd.  I might, however, argue that 
adapt(x,int) should equal int(x) for any x whose __conform__ returns 
None.  Or more precisely, that int.__adapt__(x) should return int(x).

And that is why I'm asking why you appear to disagree.  However, you keep 
talking about *other* values of y and x than 'int' and "23", so I'm no 
closer to understanding your original statement than before.

>Adaptation should NOT work that way: adapt(x, list) would, rather,
>return a wrapper, providing listlike methods (some, like pop or remove,
>would delegate to x's own methods -- others, like sort, would require
>more work) and _eventually performing actual operations on x_, NOT
>on a separate thing that once, a long time ago, was constructed by
>copying it.

For protocols whose contract includes immutability (such as 'int') this 
distinction is irrelevant, since a snapshot is required.  Or are you saying 
that adaptation cannot be used to adapt a mutable object to a protocol that 
includes immutability?

>Thus, I see foo(x) and adapt(x, foo) -- even in cases where foo is a
>type -- as GENERALLY very different.  If you have SPECIFIC use cases
>in mind where it would be clever to make the two operations coincide,
>you still haven't made them; I only heard vague generalities about how
>adapt(x, y) "should" work without ANY real support for them.

It's you who has proposed how they work, and I who asked a question about 
your statement.

>In Python, we think EIBNI, and therefore typecasts are explicit.
>We do NOT "adapt" a float f to int when an int is required, as
>in somelist[f]: we raise a TypeError -- if you want COERCION,
>aka CONVERSION, to an int, with possible loss of information
>etc, you EXPLICITLY code somelist[int(f)].  Your proposal that
>adaptation be, when possible, implemented by conversion, goes

I'm not aware that I made such a proposal.  I asked why you thought that 
adapt('23',int) should *not* return 23.

 >[lots more snipped]

We seem to be having two different conversations.  I haven't proposed 
*anything*, only asked questions.  Meanwhile, you keep debating my supposed 
proposal, and not answering my questions!

Specifically, you still have not answered my question:

Why do you think that 'adapt("23",int)' should not return 23?

That is all I am asking, and trying to understand.  It is a question, not a 
proposal for anything, of any kind.

Now, it is possible I misunderstood your original statement, and you were 
not in fact proposing that it should not.  If so, then that clarification 
would be helpful.

All the rest of this about why adapt(x,y) may have nothing to do with y(x) 
isn't meaningful to me.  The fact that 2+2==4 and 2*2 ==4 doesn't mean that 
multiplication is the same as addition!  So why would adapt(x,y) and y(x) 
being equal for some values of x and y mean that adaptation is 
conversion?  You seem to be arguing, however, that that's what I'm saying.

Further, you seem to me to be saying that "Because addition is not 
multiplication, adding 2 and 2 should not equal 4.  That's what 
multiplication is for, so you should always multiply 2 and 2 to get 4, 
never add them."  And that seems so wrong to me, that I have to ask, "Why 
would you say a thing like that?"

Then, you answer me by saying, "But addition is not multiplication, so why 
are you proposing that adding two numbers should always produce the same 
result as multiplying them?"  When in fact I have not proposed any such 
thing, nor would I!

More information about the Python-Dev mailing list