Adaptation and typecasting (was Re: [Python-Dev] replacing
Phillip J. Eby
pje at telecommunity.com
Tue Oct 28 13:47:06 EST 2003
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.
More information about the Python-Dev