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 -- http://mail.python.org/mailman/listinfo/python-list
