But adaptation is not transmission! It's PERFECTLY acceptable for an adapter to facade: to show LESS information in the adapted object than was in the original.
It's also true that it's acceptable for a router to choose not to forward packets, e.g. for security reasons, QoS, etc. My point was that you seem to be using this to conclude that multihop packet forwarding is a bad idea in the general case, and that's what doesn't make any sense to me.
More to the point, the error in your example isn't the filtering-out of information, it's the adding of a NULL back in. If NULLs are questionable for the target interface, this is not in general a candidate for implicit adaptation IMO -- *whether or not transitivity is involved*.
Let's look at the reverse of the float-to-int case for a better example. Should I be able to implicitly adapt a float to a Decimal? No, because I might be making up precision that isn't there. May I explicitly convert a float to a decimal, if I know what I'm doing? Yes, of course. Just don't expect Python to guess for you.
This is very much like your example; adding a NULL middle name seems to me almost exactly like going from float to Decimal with spurious precision. If you know what you're doing, it's certainly allowable to do it explicitly, but Python should not do it implicitly.
Thus, my argument is that an adapter like this should never be made part of the adapter system, even if there's no transitivity. However, if you agree that such an adapter shouldn't be implicit, then it logically follows that there is no problem with allowing transitivity, except of course that people may sometimes break the rule.
However, I think we actually have an opportunity now to actually codify sensible adaptation practices, such that the violations will be infrequent. It's also possible that we may be able to define some sort of restricted implicitness so that somebody making a noisy adapter can implicitly adapt in a limited context.
What happened here is not that either of the adapters registered is wrong: each does its job in the best way it can. The programming error, which transitivity hides (degrading the quality of information resulting from the system -- a subtle kind of degradation that will be VERY hard to unearth), is simply that the programmer forgot to register the direct adapter. Without transitivity, the programmer's mistake emerges easily and immediately; transitivity hides the mistake.
Where we differ is that I believe that if the signal degradation over a path isn't acceptable, it shouldn't be made an implicit part of the network; it should be an explicitly forced route instead.
Note by the way, that the signal degradation in your example comes from a broken adapter: it isn't valid to make up data if you want real data. It's PRAGMATIC, as you say, to make up the data when you don't have a choice, but this does not mean it should be AUTOMATIC.
So, we both believe in restricting the automatic and implicit nature of adaptation. The difference is that I'm saying you should be explicit when you do something questionable, and you are saying you should be explicit when you're doing something that is *not*. Perhaps as you previously suggested, this really is the aspect where we need the BDFL to be the tiebreaker.
At the same time, if I understand correctly, you're ALSO saying that if two other adapters exist, A -> Z and Z -> C, *THEN* it's an error, because you don't know when adapting A -> C whether to go via B or via Z. Well, if you consistently believe what I state in the previous paragraph, then this is just weird: since you're implicitly asserting that any old A->?->C transitive adaptation is just as good as a direct A->C, why should you worry about there being more than one such 2-step adaptation available?
Because such ambiguities are usually an indication of some *other* error, often in the area of interface inheritance transitivity; they rarely occur as a direct result of implementing two versions of the same adapter (at least in my experience).
I'm willing to compromise to the extent of letting any given adaptation somehow STATE, EXPLICITLY, "this adaptation is lossless and perfect, and can be used as a part of transitive chains of adaptation without any cost whatsoever". If we do that, though, the adaptation system should trust this assertion, so if there are two possibilities of equal minimal length, such as A->B->C or A->Z->C, with all the steps being declared lossless and perfect, then it SHOULD just pick one by whatever criterion, since both will be equally perfect anyway -- so maybe my reasoning by absurd wasn't totally absurd after all;-).
Here's the part I don't think you're seeing: interface inheritance transitivity has this *exact* same problem, and it's *far* easier to stumble into it, assuming you don't start out by declaring adapters that we both agree are insane (like filename-to-file). If your argument is valid for adapters, however, then the only logical conclusion is that we cannot permit an adapter for a derived interface to be returned when a base interface is requested. Is this your position as well?
_______________________________________________ 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
