At 05:55 PM 10/28/03 +0100, Alex Martelli wrote:
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.
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. Currently, Python objects may possess an __int__ method for conversion to integers, and a __str__ method for conversion to string. So, it seems to me that for such objects, 'adapt(x,int)' should be equivalent to x.__int__() and 'adapt(x,str)' should be equivalent to x.__str__(). So, there is already a defined protocol within Python for conversion to specific types, with well-defined meaning. One might argue that since it's already possible to call the special method or invoke the type constructor, that it's not necessary for there to be an adapt() synonym for them. However, it's also possible to get an object's attribute or call an arbitrary function by exec'ing a dynamically constructed string instead of using getattr() or having functions as first class objects. So, I don't see any problem with "convert to integer" being 'int(x)' and yet still being able to spell it 'adapt(x,int)' in the circumstance where 'int' is actually a variable or parameter, just as one may use 'getattr(x,y)' when the attribute to be gotten is a variable.
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.
I don't understand the dividing line here. Perhaps that's because Python doesn't really *have* an existing notion of typecasting as such, there are just constructors (e.g. int) and conversion methods (e.g. __int__). However, conversion methods and even constructors of immutable types are allowed to be idempotent. 'int(x) is x' can be true, for example. So, how is that different?
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).
I don't see how any of this impacts the question of whether adapt(x,int) == int(x). Certainly, I agree with you that adapt("foo",file) should not equal file("foo"), but I don't understand what one of these things has to do with the other.