> 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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/3VIPHO6WGVHORUPXBXSNYPDZCI4W3GYU/
Code of Conduct: http://python.org/psf/codeofconduct/
