Python as an Object Oriented Programming Language

[Stuart D. Gathman]

On Tue, 17 Dec 2002 15:21:43 -0500, Michele Simionato wrote:

> I have read this citation by Zack Urlocker "Multiple Inheritance is the
> goto of the 90's" and various recommendation against it. On top of that,
> various languages forbid it by design, because it is a Bad Thing.
> Nevertheless, it doesn't seem so evil to me in Python, I also have seen
> a paper by Chuck Esterbrook about Multiple Inheritance and mixins as a
> very useful technique. I think the original quotation referred to C++
> where multiple inheritance is such a mess. OTOH, it doesn't seems very
> difficult or very dangerous in Python once you have understood the
> Method Resolution Order. Am I correct ? 

There is nothing wrong with C++ MI.  It provides very nice mixins just
like python or whatever.  It allows you to keep interface and
implementation separate.  Therein lies the problem.  Problems with C++ MI
spaghetti are really caused by mixing interface and implementation in the
same type.  C++ is not wrong to allow this: it is handy to have an
interface with default implementations for some items, and even test
methods that check global contracts for the interface.  But there is no
language keyword that says "this is an interface", and so naive
programers forget which they are doing.

The second problem some people have with C++ MI is that adding another
method to a virtual base class requires recompiling everything that uses
that virtual base, and virtual base methods are often part of "mixin"
implementation modules rather than part of the public interface.  C++ is
not wrong to allow this: static compilation for direct access to objects
is the only way to get maximum speed from ahead of time compilation.  It
is perfectly feasible to use handles for C++ objects to avoid recompiling
the world just because an implementation detail changes.  It is even
feasible to dynamically load the implementation - and by the time you do
all that indirection, the performance is about as good as Java.  You want
the advantages of statically compiled code - you have to recompile the
world when an implementation changes.  You can even judiciously partition
things for a compromise between the two extremes.

Python will never give you any recompile the world headaches.  However,
like C++, Python does not explicitly distinguish between interface and
implementation - giving you the flexibility of default implementations
and runtime checks for your interfaces.  You must keep track of which is
which, and document the result.  I recommend keeping interface methods
textually together in a public class.  There is some mention in the
Python docs of prepending implementation methods with '_', but this is
not consistently done.

Notice that interface vs. implementation is a different issue than public
vs. private.

-- 
	      Stuart D. Gathman <stuart at bmsi.com>
Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.