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!