[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 12:33 AM 1/12/05 +0100, Alex Martelli wrote:
>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?