[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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
