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

[Alex Martelli]

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