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!
_______________________________________________ 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
