[Python-Dev] PEP 246, redux

[Alex Martelli]

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

> At 10:16 AM 1/12/05 -0800, Guido van Rossum wrote:
>> For example, inteface B (or perhaps this should be a property of the
>> adapter for B->C?) might be marked so as to allow or disallow its
>> consideration when looking for multi-step adaptations. We could even
>> make the default "don't consider", so only people who have to deal
>> with the multiple A's and/or multiple C's all adaptable via the same B
>> could save themselves some typing by turning it on.
>
> Another possibility; I've realized from Alex's last mail that there's 
> a piece of my reasoning that I haven't been including, and now I can 
> actually explain it clearly (I hope).  In my view, there are at least 
> two kinds of adapters, with different fidelity 
> requirements/difficulty:
>
>    class     -> interface  ("lo-fi" is okay)
>    interface -> interface  (It better be perfect!)
>
> If you cannot guarantee that your interface-to-interface adapter is 
> the absolute best way to adapt *any* implementation of the source 
> interface, you should *not* treat it as an interface-to-interface 
> adapter, but rather as a class-to-interface adapter for the specific 
> classes that need it.  And, if transitivity exists, it is now 
> restricted to a sensible subset of the possible paths.

Even though Guido claimed I have been belaboring the following point, I 
do think it's crucial and I still haven't seen you answer it.  If *any* 
I1->I2 adapter, by the very fact of its existence, asserts it's the 
*absolute best way* to adapt ANY implementation of I1 into I2; then why 
should the existence of two equal-length shortest paths A->I1->I2 and 
A->I3->I2 be considered a problem in any sense?  Pick either, at random 
or by whatever rule: you trust that they're BOTH the absolute best, so 
they must be absolutely identical anyway.

If you agree that this is the only sensible behavior, and PyProtocols' 
current behavior (TypeError for two paths of equal length save in a few 
special cases), then I guess can accept your stance that providing 
adaptation between interfaces implies the strongest possible degree of 
commitment to perfection, and that this new conception of *absolute 
best way* entirely and totally replaces previous weaker and more 
sensible descriptions, such as for example in 
<http://peak.telecommunity.com/protocol_ref/proto-implication.html> 
that shorter chains "are less likely to be a ``lossy'' conversion".  
``less likely'' and ``absolute best way'' just can't coexist.  Two 
"absolute best ways" to do the same thing are exactly equally likely to 
be ``lossy'': that likelihood is ZERO, if "absolute" means anything.
((Preferring shorter chains as a heuristic for faster ones may be very 
reasonable approach if performance is a secondary consideration, as 
I've already mentioned; if performance were more important than that, 
then other ``costs'' besides the extreme NO_ADAPTER_NEEDED [[0 cost]] 
and DOES_NOT_SUPPORT [[infinite cost]] should be accepted, and the 
minimal-cost path ensured -- I do not think any such complication is 
warranted)).

> I think maybe this gets us a little bit closer to having a unified (or 
> at least unifiable) view on the problem area.  If Alex agrees that 
> class-to-interface adaptation is an acceptable solution for limiting 
> the transitivity of noisy adaptation while still allowing some degree 
> of implicitness, then maybe we have a winner.

If you agree that it cannot be an error to have two separate paths of 
"absolute best ways" (thus equally perfect) of equal length, then I can 
accept your stance that one must ensure the "absolute best way" each 
time one codes and registers an I -> I adapter (and each time one 
interface inherits another interface, apparently); I can then do half 
the rewrite of the PEP 246 draft (the changes already mentioned and 
roughly agreed) and turn it over to you as new first author to complete 
with the transitivity details &c.

If there is any doubt whatsoever marring that perfection, that 
"absolute best way", then I fear we're back at square one.


Alex