[Python-Dev] PEP 246, redux
Phillip J. Eby
pje at telecommunity.com
Tue Jan 11 21:30:19 CET 2005
At 09:10 PM 1/11/05 +0100, Alex Martelli wrote:
>On 2005 Jan 11, at 20:48, Phillip J. Eby wrote:
> ...
>>>I'd rather not assume that class inheritance implies substitutability,
>>
>>Hm, you should take that up with Alex then, since that is what his
>>current PEP 246 draft does. :) Actually, the earlier drafts did that
>>too, so I'm not sure why you want to change this now.
>>
>>What I've actually suggested here actually allows for
>>inheritance=substitutability as the default, but also makes it trivially
>>changeable for any given inheritance hierarchy by overriding __conform__
>>at the base of that hierarchy, and without introducing a special
>>exception class to do it.
>
>The base of the hierarchy has no idea of which subclasses follow or break
>Liskov subtitutability. It's just silly to site the check
>there. Moreover, having to change the base class is more invasive than
>being able to do it in the derived class: typically the author of the
>derived class is taking the base class from some library and does not want
>to change that library -- changing the derived class is not ideal, but
>still way better.
Stop; you're responding to something I didn't propose! (Maybe you're
reading these posts in reverse order, and haven't seen the actual proposal
yet?)
Clark said he didn't want to assume substitutability; I was pointing out
that he could choose to not assume that, if he wished, by implementing an
appropriate __conform__ at the base of his hierarchy. This is entirely
unrelated to deliberate Liskov violation, and is in any case not possible
with your original proposal. I don't agree with Clark's use case, but my
proposal supports it as a possibility, and yours does not.
To implement a Liskov violation with my proposal, you do exactly the same
as with your proposal, *except* that you can simply return None instead of
raising an exception, and the logic for adapt() is more straightforward.
More information about the Python-Dev
mailing list