On Thu, 13 Jan 2005 10:26:54 -0500, Phillip J. Eby <[EMAIL PROTECTED]> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com