[Python-Dev] PEP 246, redux

[Paul Moore]

On Thu, 13 Jan 2005 10:26:54 -0500, Phillip J. Eby
<pje at telecommunity.com> wrote:
> At 09:34 AM 1/13/05 -0500, Clark C. Evans wrote:
> >On Thu, Jan 13, 2005 at 10:35:39AM +0000, Paul Moore wrote:
> >| One thing I feel is key is the fact that adaptation is a *tool*, and
> >| as such will be used in different ways by different people. That is
> >| not a bad thing, even if it does mean that some people will abuse the tool.
> >|
> >| Now, a lot of the talk has referred to "implicit" adaptation. I'm
> >| still struggling to understand how that concept applies in practice,
> >| beyond the case of adaptation chains - at some level, all adaptation
> >| is "explicit", insofar as it is triggered by an adapt() call.
> >
> >The 'implicit' adaptation refers to the automagical construction of
> >composite adapters assuming that a 'transitive' property holds.
> 
> Maybe some folks are using the term that way; I use it to mean that in this
> code:
> 
>     someOb.something(aFoo)
> 
> 'aFoo' may be "implicitly adapted" because the 'something' method has a
> type declaration on the parameter.

Whoa! At this point in time, parameters do not have type declarations,
and PEP 246 does NOTHING to change that.

In terms of Python *now* you are saying that if someOb.something is
defined like so:

    def someOb.something(f):
        adapted_f = adapt(f, ISomethingOrOther)

then aFoo is being "implicitly adapted". I'm sorry, but this seems to
me to be a completely bogus argument. The caller of someOb.something
has no right to know what goes on internal to the method. I would
assume that the documented interface of someOb.something would state
that its parameter "must be adaptable to ISomethingOrOther" - but
there's nothing implicit going on here, beyond the entirely sensible
presumption that if a method requires an argument to be adaptable,
it's because it plans on adapting it!

And as a user of someOb.something, I would be *entirely* comfortable
with being given the responsibility of ensuring that relevant
adaptations exist.

> Further, 'something' might call another method with another type
> declaration, passing the adapted version of 'foo', which results in you
> possibly getting implicit transitive adaptation *anyway*, without having
> intended it.

So you think it's reasonable for someOb.something to pass adapted_f on
to another function? I don't - it should pass f on. OK, that's a major
disadvantage of Guido's type declaration proposal - the loss of the
original object - but raise that with Guido, not with PEP 246. I'd
suspect that one answer from the POV of Guido's proposal would be a
way of introspecting the original object - but even that would be
horribly dangerous because of the significant change in semantics of
an argument when a type declaration is added. (This may kill
type-declaration-as-adaptation, so it's certainly serious, but *not*
in terms of PEP 246).

> Also, if adapters have per-adapter state, and 'someOb.something()' is
> expecting 'aFoo' to keep some state it puts there across calls to methods
> of 'someOb', then this code won't work correctly.

That one makes my brain hurt. But you've already said that per-adapter
state is bad, so maybe the pain is good for me :-)

> All of these things are "implicit adaptation" issues, IMO, and exist even
> withoutPyProtocols-style transitivity.

I'd certainly not characterise them as "implicit adaptation" issues
(except for the type declaration one, which doesn't apply to Python as
it is now), and personally (as I hope I've explained above) I don't
see them as PEP 246 issues, either.

> ... "Duck adaptation" solves these issues ...

... and may indeed be a better way of using Guido's type declarations
than making them define implicit adaptation. So I do support a
separate PEP for this. But I suspect its implementation timescale will
be longer than that of PEP 246...

Paul.