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

[Phillip J. Eby]

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.