Needed: Real-world examples for Python's Cooperative Multiple Inheritance

[Mark Wooding]

John Nagle <nagle at animats.com> writes:

>    Multiple inheritance in Python is basically what fell out of
> CPython's internals, not a design.  It's one of those areas where
> order of execution matters, and that wasn't well worked out.

I'm not sure about the history, but this doesn't sound right to me.

> Allowing classes to form a directed acyclic graph isn't very
> useful.

This is simply wrong.

> It just fell out of the semantics of a naive interpreter.

No: there's some essential work needed to make it happen.

> Originally, the semantics were just wrong.

Agreed.

> Now the awful cases have well-defined semantics, but aren't very
> useful.

Disagree strongly.  I think linearization is the only coherent approach
to multiple inheritance, and the C3 linearization seems to have almost
all of the necessary properties.  I'm not quite sure what you mean by
`awful' here: the old Python linearization rules were wrong even for
very simple graphs (they failed to respect the superclass ordering
properly).  The CLOS, Dylan and C3 linearizations agree on most commonly
occurring class graphs, including many graphs for which the old Python
orderings disagreed; the exceptions are where CLOS or Dylan failed to be
monotonic or to obey the extended precedence graph.  The semantics are
extremely useful in the hands of a careful designer.

>    Part of the problem is the notion that if a base class is duplicated
> in the hierarchy, there's only one copy.

This is a problem?  No!  Duplicating superclass state (as is done in C++
and, I believe, Eiffel) is incoherent.

> So if you inherit from two classes, both of which inherit from "dict",
> there will be only one "dict" at the bottom.  (I think.)

Yes.  You end up (probably) with an enhanced dictionary which supports
both protocols.  This happens frequently, and is very useful.

> This probably won't do what the authors of any of the classes involved
> expected.  The author of the class which does the multiple inheritance
> might not even be aware that there's a clash further up in the
> hierarchy.  This is one of those areas where all the code looks right
> locally, but it's wrong globally.

This is only likely if there's a misdesign -- probably using inheritance
where containership is required.

>    Best practice for this is "don't do it."  Some name clashes ought
> to simply be detected as errors, rather than being given such
> complex semantics.

It sounds like you've been scarred by experiences with C++'s dementedly
inadequate object system, with its bizarre `repeated inheritance' rules
and hopelessly primitive manual (static!) method combination -- possibly
even to the extent of believing that they're in some way `right' or
`necessary'.  I'm sorry.  You have my pity.

Python's object system is different, and doesn't have those problems.
You probably need a viewpoint shift to be able to think about it
properly, but that won't happen if you continue to cling to the idea
that C++'s approach is anything like a model of how to do it right.

-- [mdw]