overriding methods - two questions

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sat Nov 17 23:20:52 CET 2007

On Fri, 16 Nov 2007 18:30:28 -0800, George Sakkis wrote:

> On Nov 16, 5:03 pm, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> On Fri, 16 Nov 2007 18:28:59 +0100, Bruno Desthuilliers wrote:
>> >> Question 1:
>> >> Given that the user of the API can choose to override foo() or not,
>> >> how can I control the signature that they use?
>> > While technically possible (using inspect.getargspec), trying to make
>> > your code idiot-proof is a lost fight and a pure waste of time.
>> Worse: it's actually counter-productive!
>> The whole idea of being able to subclass a class means that the user
>> should be able to override foo() *including* the signature. Why do you
>> want to stop them?
> Primarily because of this:
> http://en.wikipedia.org/wiki/Liskov_substitution_principle.

"In object-oriented programming, the Liskov substitution principle is a 
PARTICULAR definition of subtype..." [emphasis added] 

There are other definitions possible. Also be careful of confusing 
subclasses with subtypes:


Python doesn't have types in the sense of the Liskov substitution 
principle, because Python's subclass relationship need not imply 
substitutability. In fact, the requirement for substitutability is quite 
restrictive. (Whether it is a good thing or a bad thing is open for 

With duck typing and/or delegation, one might create a new class which is 
substitutable for the original class, without it being a subclass. And 
contrariwise, one might create a subclass which isn't substitutable for 
the original class. Inheritance is a *mechanism* for getting identical or 
similar behaviour without the anti-pattern of copy-and-paste programming 
(code duplication). There's no logical requirement that two objects with 
identical behaviour in one aspect must necessarily be substitutable for 
each other:

shark.lay_egg()  # some sharks lay eggs

I don't see this as a bad thing (unless of course they are *supposed* to 
be substitutable, in which case the failure to be so is a bug).


More information about the Python-list mailing list