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

[Steven D'Aprano]

On Thu, 25 Nov 2010 15:38:36 -0800, John Nagle wrote:

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

Why is that a problem? I would expect it to be a problem if it showed up 
twice.


> So if you inherit from two
> classes, both of which inherit from "dict", there will be only one
> "dict" at the bottom.  (I think.)  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.

Why do you assume it is "wrong"? The whole point of the "complex 
semantics" that you are complaining about is to ensure that multiple 
inheritance does the right thing, rather than the wrong thing.

You simply can't safely inherit from arbitrary classes without 
understanding them. This is equally true for single and multiple 
inheritance, but in multiple inheritance there are more places for things 
to go wrong. That is simply because the semantics of "inherit from 
classes A and B" are more complex than the semantics of "inherit from 
class A".

The problem is that people expect multiple inheritance to "just work" 
mechanically, without giving any thought to the process. That it does 
often just work is a credit to the "complex semantics" that you are 
complaining about, but this lulls people into a false sense of security 
and makes it more surprising when it doesn't work.


>     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.

If that's the case, you would have to prohibit ALL multiple inheritance 
from new-style classes, because all new-style classes inherit from object.


-- 
Steven