Home Original page

[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