[Python-Dev] PEP 246, redux

Alex Martelli aleax at aleax.it
Wed Jan 12 20:31:25 CET 2005


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



More information about the Python-Dev mailing list