Needed: Real-world examples for Python's Cooperative Multiple Inheritance
steve+comp.lang.python at pearwood.info
Fri Nov 26 02:30:23 CET 2010
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
> 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
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
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.
More information about the Python-list