[Python-Dev] PEP 246, redux

[Alex Martelli]

On 2005 Jan 12, at 16:12, Phillip J. Eby wrote:

> At 02:27 PM 1/12/05 +0000, Mark Russell wrote:
>> I strongly prefer *not* to have A->B and B->C automatically used to
>> construct A->C.  Explicit is better than implicit, if in doubt don't
>> guess, etc etc.
>>
>> So I'd support:
>>
>>     - As a first cut, no automatic transitive adaptation
>>
>>     - Later, and only if experience shows there's a need for it,
>
> Well, by the experience of the people who use it, there is a need, so 
> it's already "later".  :)  And at least my experience *also* shows 
> that transitive interface inheritance with adaptation is much easier 
> to accidentally screw up than transitive adapter composition -- 
> despite the fact that nobody objects to the former.

A-hem -- I *grumble* about the former (and more generally the fact that 
inheritance is taken as so deucedly *committal*:-).  If it doesn't 
really count as a "complaint" it's only because I doubt I can do 
anything about it and I don't like tilting at windmills.  But, I _DO_ 
remember Microsoft's COM, with inheritance of interface *NOT* implying 
anything whatsoever (except the fact that the inheriting one has all 
the methods of the inherited one with the same signature, w/o having to 
copy and paste, plus of course you can add more) -- I remember that 
idea with fondness, as I do many other features of a components-system 
that, while definitely not without defects, was in many respects a 
definite improvement over the same respects in its successors.

> The other thing that really blows my mind is that the people who 
> object to the idea don't get that transitive interface inheritance can 
> produce the exact same problem, and it's more likely to happen in 
> actual *practice*, than it is in theory.

Believe me, I'm perfectly glad to believe that [a] implied transitivity 
in any form, and [b] hypercommittal inheritance, cause HUGE lots of 
problems; and to take your word that the combination is PARTICULARLY 
bug-prone in practice.  It's just that I doubt I can do anything much 
to help the world avoid that particular blight.

> As for the issue of what should and shouldn't exist in Python, it 
> doesn't really matter; PEP 246 doesn't (and can't!) *prohibit* 
> transitive adaptation.  However, I do strongly object to the spreading 
> of theoretical FUD about a practical, useful technique, much as I 
> would object to people saying that "using significant whitespace is 
> braindead" who had never tried actually using Python.  The theoretical 
> problems with transitive adapter composition are in my experience just 
> as rare as whitespace-eating nanoviruses from outer space.

Well, I'm not going to start real-life work on a big and complicated 
system (the kind where such problems would emerge) relying on a 
technique I'm already dubious about, if I have any say in the matter, 
so of course I'm unlikely to gain much real-life experience -- I'm 
quite content, unless somebody should be willing to pay me adequately 
for my work yet choose to ignore my advice in the matter;-), to rely on 
imperfect analogies with other experiences based on other kinds of 
unwanted and unwarranted but uncontrollable and unstoppable 
applications of transitivity by underlying systems and frameworks.

I already know -- you told us so -- that if I had transitivity as you 
wish it (uncontrollable, unstoppable, always-on) I could not any more 
write and register a perfectly reasonable adapter which fills in with a 
NULL an optional field in the adapted-to interface, without facing 
undetected degradation of information quality by that adapter being 
invisibly, uncontrollably chained up with another -- no error message, 
no nothing, no way to stop this -- just because a direct adapter wasn't 
correctly written and registered.  Just this "detail", for me, is 
reason enough to avoid using any framework that imposes such 
noncontrollable transitivity, if I possibly can.


Alex