[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 07:26 AM 1/12/05 -0800, Guido van Rossum wrote:
>[Alex]
> > I'm saying that if, by mistake, the programmer has NOT
> > registered the A->C adapter (which would be easily coded and work
> > perfectly), then thanks to transitivity, instead of a clear and simple
> > error message leading to immediate diagnosis of the error, they'll get
> > a subtle unnecessary degradation of information and resulting reduction
> > in information quality.
>
>I understand, but I would think that there are just as many examples
>of cases where having to register a trivial A->C adapter is much more
>of a pain than it's worth; especially if there are a number of A->B
>pairs and a number of B->C pairs, the number of additional A->C pairs
>needed could be bewildering.

Alex has suggested that there be a way to indicate that an adapter is 
noiseless and therefore suitable for transitivity.

I, on the other hand, would prefer having a way to declare that an adapter 
is *unsuitable* for transitivity, in the event that you feel the need to 
introduce an "imperfect" implicit adapter (versus using an explicit 
conversion).

So, in principle we agree, but we differ regarding what's a better 
*default*, and this is probably where you will be asked to Pronounce, 
because as Alex says, this *is* controversial.

However, I think there is another way to look at it, in which *both* can be 
the default...

Look at it this way.  If you create an adapter class or function to do some 
kind of adaptation, it is not inherently transitive, and you have to 
explicitly invoke it.  (This is certainly the case today!)

Now, let us say that you then register that adapter to perform implicit 
adaptation -- and by default, such a registration says that you are happy 
with it being used implicitly, so it will be used whenever you ask for its 
target interface or some further adaptation thereof.

So, here we have a situation where in some sense, BOTH approaches are the 
"default", so in theory, both sides should be happy.

However, as I understand it, Alex is *not* happy with this, because he 
wants to be able to register a noisy adapter for *implicit* use, but only 
in the case where it is used directly.

The real question, then, is "What is that use case good for?"  And I don't 
have an answer to that question, because it's Alex's use case.

I'm proposing an approach that has two useful extremes: be noisy and 
explicit, or clean and implicit.  Alex seems to want to also add the middle 
ground of "noisy but implicit", and I think this is a bad idea because it 
will lead to precisely to the same problems as it does in C++!

Python as it exists today tends to support the proposition that noisy 
adaptation or conversion should not be implicit, since trying to do 
'someList[1.2]' raises a TypeError, rather than silently truncating.  The 
number of steps between 'float' and 'int' in some adaptation graph has 
absolutely nothing to do with it; even if there is only one step, doing 
this kind of conversion or adaptation implicitly is just a bad idea.