At 10:03 AM 10/29/03 +1100, Delaney, Timothy C (Timothy) wrote:
> > From: Phillip J. Eby [mailto:pje at telecommunity.com]
>
> >
> > 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.
> >
> > 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.
>
>Because (IMO anyway) adaption is *not* "give me X, rendered as Y".
>Adaption is "here is an X, can it be used as a Y?".
>
>They are two distinct concepts, although obviously there are crossover
>points.
Yes, just like 2+2==4 and 2*2==4.
>A string cannot be used as an int, although an int can be created from the
>string representation of an int.
I'd often like to "use a string as an integer", or use some arbitrary
object as an integer. Of course, there's a perfectly valid way to express
this now (i.e. 'int()'), and I think that's fine and in my code I will
personally prefer to use int() to mean I want an int, because that's clearer.
But, if for some reason I have code that is referencing some protocol as a
*parameter*, say 'p', and I have no way to know in advance that p==int,
then the most sensible thing to do is 'adapt(x,p)', rather than
'p(x)'. (Assuming 'p' is expected to be a protocol, rather than a
conversion function.)
Now, given that 'p' *might* be 'int' in some cases, it seems reasonable to
me that adapt("23",p) should return 23 in such a case. Since 23 satisfies
the desired contract (int) on behalf of "23", this seems to be a correct
adaptation. For a protocol p that has immutability as part of its
contract, adapt(x,p) is well within its rights to return an object that is
a "copy" of x in some sense. The immutability requirement means that the
"adapted" value can never change, so really it's a *requirement* that the
"adaptation" be a snapshot.
>Adaption should not involve any change to the underlying data - mutating
>operations on the adapted object should (attempt to) mutate the original
>object (assuming the adapted object and original object are not one and
>the same).
I agree 100% -- for a protocol whose contract doesn't require immutability,
the way 'int' does.
I think now that I understand, however, why you and Alex think I'm saying
something different than I've been saying. To both of you, "typecasting"
means "convert to a different type" at an *implementation* level (as it is
in other languages), and I mean at a *logical* level. Thus, to me, "I
would like to use X as a Y" includes whatever contracts Y supplies *as
applied to X*. Not, "give me an instance of Y that's a copy of X".
It just so happens, however, that for a protocol whose contract includes
immutability, these two concepts overlap, just as multiplication and
addition overlap for the case of 2+2==2*2. So, IMO, for immutable types
such as tuple, str, int, and float, I believe that it's reasonable for
adapt(x,p)==p(x) iff x is not an instance of p already, and does not have a
__conform__ method that overrides this interpretation.
That such a default interpretation is redundant with p(x), I also
agree. However, for code that uses protocols dynamically, that redundancy
would eliminate the need to make a dummy protocol (e.g. 'IInteger') to use
in place of 'int'.
OTOH, if Guido decides that Python's eventual interface objects shouldn't
be types, then there will be an IInteger anyway, and the point becomes moot.
Anyway, I can only understand Alex's objection to such adaptation if he is
saying that there is no such thing as adapting to an immutable
protocol! In that case, there could never exist such a thing as IInteger,
because you could never adapt anything to it that wasn't already an
IInteger. Somehow, this seems wrong to me.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4