[Python-Dev] PEP 246, redux

[Alex Martelli]

On 2005 Jan 12, at 20:51, Phillip J. Eby wrote:
    ...
> There's a very simple reason.  If one is using only non-noisy 
> adapters, there is absolutely no reason to ever define more than one 
> adapter between the *same* two points.  If you do,

...but there's no harm whatsoever done, either.  If I have four 
interfaces I use regularly, A, B, C, D, and I have the need to adapt 
A->B, A->C, B->D, C->D, with every one of these four adaptations being 
"the absolute best way" (as you stated all interface adaptations must 
be), then why should that be at all a problem?  Maybe sometimes someone 
will need to adapt A->D, fine -- again, no harm whatsoever, IF 
everything is as perfect as it MUST be for transitivity to apply 
unconditionally.

Put it another way: say I have the first three of these adaptations, 
only, so everything is hunky-dory.  Now I come upon a situation where I 
need C->D, fine, I add it: where's the error, if every one of the four 
adaptations is just perfect?

I admit I can't sharply follow your gyrations about what's in what 
package, who wrote what, and why the fact that interfaces and 
adaptation (particularly transitive adaptation) are NOT widespread at 
all so far (are only used by early adopters, on average heads and 
shoulders above the average Python coder) makes it MORE important to 
provide an error in a case that, by the premises, cannot be an error 
(would it be LESS important to provide the error if everybody and their 
cousin were interfacing and adapting with exhuberance...?).  All I can 
see is:

1. if an interface adapter must ABSOLUTELY be perfect, transitivity is 
fine, but the error makes no sense
2. if the error makes sense (or the assertion about "less likely to be 
lossy" makes any sense, etc etc), then transitivity is NOT fine -- 
adapters can be imperfect, and there is NO way to state that they are, 
one just gets an error message if one is SO DEUCEDLY LUCKY as to have 
created in the course of one's bumbling two shortest-paths of the same 
length

I suspect [2] holds.  But you're the one with experience, so if you 
stake that on [1], and the "absolute best way" unconditional assertion, 
then, fine, I guess, as per my previous message.  But the combination 
of "absolute best way" _AND_ an error when somebody adds C->D is, in my 
opinion, self-contradictory: experience or not, I can't support 
asserting something and its contrary at the same time.

> then somebody is doing something redundant, and there is a possibility 
> for error.  In

Not at all: each of the four above-listed adaptations may be needed to 
perform an unrelated adapt(...) operation.  How can you claim that set 
of four adaptations is REDUNDANT, when adding a FIFTH one (a direct 
A->D) would make it fine again per your rules?  This is the first time 
I've heard an implied claim that redundancy is something that can be 
eliminated by ADDING something, without taking anything away.



>> Personally, I disagree with having transitivity at all, unless 
>> perhaps it be restricted to adaptations specifically and explicitly 
>> stated to be "perfect and lossless"; PJE claims that ALL adaptations 
>> MUST, ALWAYS, be "perfect and lossless" -- essentially, it seems to 
>> me, he _has_ to claim that, to defend transitivity being applied 
>> automatically, relentlessly, NON-optionally, NON-selectively (but 
>> then the idea of giving an error when two or more shortest-paths have 
>> the same length becomes dubious).
>
> No, it follows directly from the premise.  If adapters are non-noisy, 
> why do you need more than one adapter chain of equal length between 
> two points?  If you have such a condition, you

I don't NEED the chain, but I may well need each step; and by the 
premise of "absolute best way" which you maintain, it must be innocuous 
if the separate steps I need end up producing more than one chain -- 
what difference can it make?!

> have a redundancy at the least, and more likely a programming error -- 
> surely BOTH of those adapters are not correct, unless you have that 
> excruciatingly-rare case I mentioned above.

Each of the FOUR adapters coded can be absolutely perfect.  Thus, the 
composite adapters which your beloved transitivity builds will also be 
perfect, and it will be absolutely harmless to pick one of them at 
random.


>> BTW, Microsoft's COM's interfaces ONLY have the "inferior" kind of 
>> inheritance.  You can say that interface ISub inherits from IBas: 
>> this means that ISub has all the same methods as IBas with the same 
>> signatures, plus it may have other methods; it does *NOT* mean that 
>> anything implementing ISub must also implement IBas, nor that a 
>> QueryInterface on an ISub asking for an IBas must succeed, or 
>> anything of that kind.  In many years of COM practice I have NEVER 
>> found this issue to be a limitation -- it works just fine.
>
> I'm actually open to at least considering dropping interface 
> inheritance transitivity, due to its actual problems in practice.  
> Fewer than half of the interfaces in PEAK do any inheritance, so 
> having to explicitly declare that one interface implies another isn't 
> a big deal.

Now that is something I'd really love, as per my previous msg.

> Such a practice might seem very strange to Java programers, however, 
> since it means that if you declare (in Python) a method to take IBas, 
> it will not accept an ISub, unless the object has explicitly declared 
> that it supports both.  (Whereas in Java it suffices for the class to 
> declare that it supports ISub.)

Often the author of ISub will be able to declare support for IBas as 
well as inheriting (widening) of it; when that is not possible, the 
Java programmer, although surprised, will most likely be better off for 
having to be a tad more explicit.


Alex