On 2005 Jan 12, at 19:16, Guido van Rossum wrote: ...
[Alex]Hm?
I meant if there were multiple A's. For every Ai that has an Ai->B you would also have to register a trivial Ai->C. And if there were multiple C's (B->C1, B->C2, ...) then the number of extra adaptors to register would be the number of A's *times* the number of C's, in addition to the sum of those numbers for the "atomic" adaptors (Ai->B, B->Cj).
Ah, OK, I get it now, thanks.
But now, since I am still in favor of automatic "combined" adaptation *as a last resort*, I ask you to consider that Python is not C++, and that perhaps we can make the experience in Python better than it was in C++. Perhaps allowing more control over when automatic adaptation is acceptable?
Yes, that would be necessary to achieve parity with C++, which does now have the 'explicit' keyword (to state that a conversion must not be used as a step in a chain automatically constructed) -- defaults to "acceptable in automatic chains" for historical and backwards compatibility reasons.
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.
Yes, this idea you propose seems to me to be a very reasonable compromise: one can get the convenience of automatic chains of adaptations but only when the adaptations involved are explicitly asserted to be OK for that. I think that the property (of being OK for automatic/implicit/chained/transitive use) should definitely be one of the adaptation rather than of an interface, btw.
Alex
_______________________________________________ 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
