On Tuesday 28 October 2003 02:57 pm, Phillip J. Eby wrote:
At 09:56 AM 10/28/03 +0100, Alex Martelli wrote:
AND, adaptation is not typecasting: e.g y=adapt("23", int) should NOT succeed.
Obviously, it wouldn't succeed today, since int doesn't have __adapt__ and str doesn't have __conform__. But why would you intend that they not have them in future?
I'd be delighted to have the int type sprout __adapt__ and the str type sprout __conform__ -- but neither should accept this case, see below.
And, why do you consider adaptation *not* to be typecasting? I always think of it as "give me X, rendered as a Y", which certainly sounds like a description of typecasting to me.
typecasting (in Python) makes a NEW object whose value is somehow "built" (possibly in a very loose sense) from the supplied argument[s], but need not have any more than a somewhat tangential relation with them. adaptation returns "the same object" passed as the argument, or a wrapper to it that makes it comply with the protocol. To give a specific example: x = file("foo.txt") now (assuming this succeeds) x is a readonly object which is an instance of file. The argument string "foo.txt" has "indicated", quite indirectly, how to construct the file object, but there's really no true connection between the value of the argument string and what will happen as that object x is read. Thinking of what should happen upon: x = adapt("foo.txt", file) what I envision is DEFINITELY the equivalent of: x = cStringIO.StringIO("foo.txt") i.e., the value (aka object) "foo.txt", wrapped appropriately so as to conform to the (readonly) "file protocol" (I can call x.read(3) and get "foo", then x.seek(0) then x.read(2) and get "fo", etc). Hmmm, that PEP definitely needs updating (including mentions of PyProtocol as well as of this issue...)...! I've been rather remiss about it so far -- sorry. Alex