Brendan Barnwell writes:
You seem to be envisioning a system in which multiple inheritance gives a subclass a "menu" of behaviors from which it may explicitly choose, but does not actually combine the superclasses' behaviors into a single, definite behavior of the subclass. In that scheme, order of multiple inheritance would not matter, because the superclasses don't need to be "integrated" into the subclass; they just sit there waiting for the subclass to explicitly decide which superclass it wants to delegate to. not sure i had time to answer this one yet, so here we are.
I do not want any change in case of simple inheritance, nor do i want any change in case of MI where there's no name collision. The integration of parent class would be the exact same in those cases. And if you doubt it, my proposal, about method resolution, is that if there's only one candidate for resolution, we select it, if there's none, we raise the standard attribute error, and if there's multiple, we raise an explicitness required error. In case of MI where there's no name collision, aka, there's never more than one candidate for resolution, the behavior would be the exact same. Expliciteness is required only in case there's multiple candidates for resolution. Also, super, or the equivalent i named __as_parent__ in my poc, would be able to target the parent class it's given as an argument, as well as implicitely chose the only parent, when there's only one parent. Order of the parent doesn't matter, because we just don't need it anymore. Not because we're not integrating the parents.
they just sit there waiting for the subclass to explicitly decide which superclass it wants to delegate to. Implicitness would still be the overall norm.
When a subclass inherits from multiple superclasses, the superclass behaviors are *combined* into a *single* set of behaviors for the subclass. They're not "held separate" somehow as alternative inheritance hierarchies; they are joined into one. Demonstrably false:
class Dad:
age = 65
class Mom:
age = 61
class Son(Dad, Mom):
pass
Son.age is definitely not a combination of Dad's and Mom's age Same apply for methods, they only "combine" assuming Dad's method calls super. Which it's likely not to if it's meant to run independant instances, as it doesn't have parent itself. But it is possible to have those behavior combine, yeah.
They're not "held separate" somehow as alternative inheritance hierarchies; they are joined into one. All but one are ignored, and that one has the responsibility to care about the others. The design i propose would make the responsibility of "caring" about all its parent to the class inheriting from them. Which localises the responsibility a bit better i think, and definitely allows for actual integration of multiple class into one, at least as well as today's solution.
There's probably a joke about parents ignoring conflict so much it leads to divorce somewhere in there.
I don't want to sound harsh, but if `class A(B, C)` doesn't "feel" different to you from `class(C, B)` then I think you need to adjust your feelings rather than expect Python to adjust its behavior. You're absolutely not harsh, you're actually quite respectful. Disagrement is not an insult. I think that python is (at least know to be) a language that cares about making it the easiest to program. Or that it's made to be easy to learn. Essentially, that it always cared about having a very reliable UX design, not that it named it UX design, but that's at the core of python values. I believe the change i propose goes very well with those values / goals of python, and wouldn't be out of place in python. I don't believe it's as clear cut as you say it is, honestly.
As much as i understand the feeling 'perhaps its time you learn', i don't believe it applies here, since it's a commonly misunderstood feature. If i were the actual only one guy who didn't understand it, sure. But that's not the case. And at some point, we gotta look at the feature itself.