MRO problems with diamond inheritance?

John Perks and Sarah Mount johnandsarah at estragon.freeserve.co.uk
Mon May 2 17:41:25 EDT 2005


"Michele Simionato" <michele.simionato at gmail.com> wrote in message
news:1115025031.721431.76320 at o13g2000cwo.googlegroups.com...
> BTW, what it your use case? I have yet to see a single compelling use
> case for multiple inheritance, so I am
> curious of what your design is.

Before I start, I should mention that my workaround I listed previously
is bogus, but I think this:

listOfBases.sort(reverse=True, key=lambda b:len(b.__mro__))

has the effect of pulling the most derived classes to the front of the
bases list, which at any rate stops the exception being thrown.

My compelling use case for MI in Python is... better to model MI in Java
:)

Well, I'll come back to that. In the "real" world,  I have found
single-implementation-multiple-interface inheritance (as presented by
Java and .NET) to be highly expressive while avoiding some of the issues
of multiple-implementation inheritance as presented by C++. (Though I
don't agree with Java's FUD that multpile-implementation iheritance is a
bad design choice simply because Java doesn't support it.) In one
application, we had a simple (tree-like, non-MI) hierarchy of abstract
interfaces which would be used by the API's clients:

class Thing { } // abstract
class SpecialThing : virtual public Thing { } // abstract

and the concrete subclasses (that were not exposed via the API) mirrored
it:
class ThingImpl : virtual public Thing { }
class SpecialThingImpl : virtual public SpecialThing, virtual public
ThingImpl { }

(That said, that same job sent me on a training course to learn not to
use inheritance *at* *all*, but rather cut'n'paste multiple copies of
the same code and maintain them in parallel. I got laid off when it
transpired that the entire project was just a figment of somebody's
imagination.)

I'm currently writing a package to embed Java in Python (another one,
just what the world needs), and I use Python's dynamic type creation to
"grow" a Python type hierarchy mirroring that of the underlying Java
object, which is where I'd been running into the MRO problems that
kicked off this whole thread. The Java classes are represented by Python
types, where the one for class Class is also the metaclass of all the
Java objects. Aside from those though, I've now had to model Java's MI
in both C++ and Python and found it to be surprisingly painless on both
occasions.

(In cas you're interested, it all works via:

[Python client code] --> pyJav(Python) --> Boost.Python -->
pyJav._core(C++) --> MyJNI++ --> JNI --> [Java code]

where all the stuff you've never heard of is mine. I'm aiming to keep
the pyJav C++ layer as thin as possible, and do everything I can in
Python.)

John.





More information about the Python-list mailing list