[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 11:31 AM 1/13/05 +0100, Alex Martelli wrote:

>On 2005 Jan 12, at 21:42, Phillip J. Eby wrote:
>    ...
>>Anyway, hopefully this post and the other one will be convincing that 
>>considering ambiguity to be an error *reinforces* the idea of I-to-I 
>>perfection, rather than undermining it.  (After all, if you've written a 
>>perfect one, and there's already one there, then either one of you is 
>>mistaken, or you are wasting your time writing one!)
>
>I'd just like to point out, as apparently conceded in your "fair enough" 
>sentence in another mail, that all of this talk of "wasting your time 
>writing" is completely unfounded.

The above refers to two I-to-I adapters between the same two points, not 
the addition of an adapter that creates an adaptation diamond.  I have 
indeed agreed that an "innocent" adapter diamond can trigger a "false 
alarm" from PyProtocols with respect to duplication.


>  Since that "fair enough" of yours was deeply buried somewhere inside 
> this huge conversation, some readers might miss the fact that your 
> numerous repetitions of the similar concept in different words are just 
> invalid, because, to recap:
>
>Given four interfaces A, B, C, D, there may be need of each of the single 
>steps A->B, A->C, B->D, C->D.  Writing each of these four adapters can IN 
>NO WAY be considered "wasting your time writing one", because there is no 
>way a set of just three out of the four can be used to produce the fourth one.

Right, I agreed to this.  However, the fact that a test can produce false 
positives does not in and of itself mean that it's "just invalid" -- the 
question is how often the result is *useful*.


>I seems to me that you do at least feel some unease at the whole 
>arrangement, given that you say "this whole debate has made me even less 
>enamored of adaptation", as

Not exactly, because my experience to date has been that false alarms are 
exceedingly rare and I have yet to experience a *useful* adapter diamond of 
the type you've described in an actual real-life interface, as opposed to a 
made up group of A,B,C,D.    So, my unease in relation to the adapter 
diamond issue is only that I can't say for absolutely certain that if PEP 
246 use became widespread, the problem of accidental I-to-I adapter 
diamonds might not become much more common than it is now.


>it's not clear to me that any _other_ aspect of "this whole debate" was 
>quite as problematic (e.g. issues such as "how to best get a special 
>method from class rather than instance" -- while needing to be resolved 
>for adaptation just as much as for copy.py etc -- hardly seem likely to 
>have been the ones prompting you to go looking for "a cleaner, more 
>intuitive way to do it" outside of the canonical, widespread approach to OOP).

No, the part that made me seek another solution is the reactions of people 
who were relatively fresh to the debate and the concepts of adaptation, 
interfaces, etc. in Python.  The fact that virtually every single one of 
them immediately reached for what developers who were more "seasoned" in 
this concept thought of as "adapter abuse", meant to me that:

1) Any solution that relied on people doing the right thing right out of 
the gate wasn't going to work

2) The true "Pythonic" solution would be one that requires the least 
learning of interfaces, covariance, contravariance, Liskov, all that other 
stuff

3) And to be Pythonic, it would have to provide only one "obvious way to do 
it", and that way should be in some sense the "right" way, making it at 
least a little harder to do something silly.

In other words, I concluded that we "seasoned" developers might be right 
about what adaptation is supposed to be, but that our mere presentation of 
the ideas wasn't going to sway real users.

So no, my goal wasn't to fix the adapter diamond problem per se, although I 
believe that the equivalent concept in duck adaptation (overlapping 
abstract methods) will *also* be able to trivially ignore adapter diamonds 
and still warn about meaningful ambiguities.

Instead, the goal was to make it so that people who try to abuse adapters 
will quickly discover that they *can't*, and second, as soon as they ask 
how, the obvious answer will be, "well, that's because you're doing a type 
conversion.  You need to create an instance of the thing you want, because 
you can't use that thing "as a" such-and-such."  And then they will go, 
"Ah, yes, I see...  that makes sense," and then go and sin no more.

With the previous PEP, people could create all sorts of subtle problems in 
their code (with or without transitivity!) and have no direct indicator of 
a problem.  Clark and Ian made me realize this with their string/file/path 
discussions -- *nobody* is safe from implicit adaptation if adaptation 
actually creates new objects with independent state!  An adapter's state 
needs to be kept with the original object, or not at all, and most of the 
time "not at all" is the correct answer.


>Anyway -- I'm pointing out that what to put in a rewrite of PEP 246 as a 
>result of all this is anything but obvious at this point, at least to me.

LOL.  Me either!