Actually, no, it does not. Only the A.method() runs, because A was not designed for multiple-inheritance. C inherits from both A and B, but only calls one of the methods.
Yeah, my point was to say that no error is raised, but that the behavior of the program is not really what you'd expect, so yeah. Essentially, i have a problem with code behavior being unexpected, and my proposal would add an error here, to attract the attention of the developper, for them to solve that problem. And yeah, A is not designed for multiple inheritence. Today it would have to be designed for it, but that's (one of) my problem here, why would a parent class need to know about its childs, it seems like a poorly attribute responsibility, especially since this child can have other parents, and its behavior can't be fully known from A. In fact, the github repository i made about it proposes an alternative, where a single parent inheriting from the Parenting class that implements my version of super, and my alternative to MRO is enough for all classes in the inheritence tree to behave like that. Because the dunder methods can be overriden by anyone class in the inheritence tree, and apply to all the tree. That to me is a major issue : We *can't* know enough in the class definition to make it work in all cases, because the responsibility of handling multiple inheritance is set in a different place (the parent) than where it is requested (the child).
Why are you inheriting from A if you don't want to inherit from A?
Okay, i wasn't clear enough, my bad ``` class A: def call_me_in_A_first(self): # calls super def call_me_in_B_first(self): # calls super class B: def call_me_in_A_first(self): # calls super def call_me_in_B_first(self): # calls super class C(A,B): def call_me_in_A_first(self): # calls super def call_me_in_B_first(self): # calls super ``` Today, super locks you in the C A B order, even if that is not the order you want A solution in some cases would be to reorder the parent in the class definition of C This scenario here highlights a case when such a workaround is not enough Obviously you can still use the class.method syntax, but that's the problem : the current super feature doesn't work here My alternative to super would, since you can just pass it an argument telling what parent it should target, it would look like that ``` class A: def call_me_in_A_first(self): # don't have to calls super def call_me_in_B_first(self): # don't have to calls super class B: def call_me_in_A_first(self): # don't have to calls super def call_me_in_B_first(self): # don't have to calls super class C(A,B): def call_me_in_A_first(self): __as_parent__(A).call_me_in_A_first() __as_parent__(B).call_me_in_A_first() def call_me_in_B_first(self): __as_parent__(B).call_me_in_B_first() __as_parent__(A).call_me_in_B_first() ``` the __as_parent__ is the name i gave my alternative to super in my github repository : https://github.com/malmiteria/super-alternative-to-super (and yes, you can run that code for yourself, i've included ~100 tests to showcase different behaviors) And yeah, the name of that repository is an hommage at the "super being super" talk from raymond hettinger (which started my reflection on this topic around a year ago), very good talk
You can't just inherit from arbitrary classes that don't work together. "Uncooperative multiple inheritance" is an unsolvable problem, and is best refactored using composition instead.
It isn't solved today, and that's the point of my alternative to MRO and my alternative to super. Although i'm not sure exactly how you define "uncooperative multiple inheritence" But this seems to be solvable by raising error on conflicting names, right? I mean, it's not so different from a conflict when merging a git branch into another one, i'll explain that more in an answer down below, i'm trying to answer every one as much as i can in a timely manner