the alternative to super really is not the important part of my proposal, it's the alternative to MRO. An example of a case where i genuinly believe my solution adds value is this : ``` class A: def method(self): print("A") class B: def method(self): print("B") class C(A, B): pass ``` Today, a code such as ```C().method()``` works without any problems except of course when the method you wanted to refer to was the method from B. If class A and B both come from libraries you don't own, and for some reason have each a method named the same (named run, for example) the run method of C is silently ignoring the run method of B. I believe it would make the programmers life easier to have an error at this time, or anything tbh, to make explicit this resolution, because it really is not explicit from most programmers perspective my alternative to super comes to fit the alternative to mro, i think it stills matter to have a dedicated feature instead of simply calling class.method, this allows for more error handling and stuff like that, in case for example you're calling super on a class that's not a parent for example, since super really is for accessing parents context. This is not so much about final code, but more about making it easier *when* writing code. But the final code would definitely not look that much prettier / ugglier, I agree And finally, super is not a proxy to parents, even plural, it's a proxy to the next in mro order. in this case : class Top: def method(self): print('Top') class Left(Top): def method(self): print('Left') super().method() class Right(Top): def method(self): print('Right') super().method() class Bottom(Left, Right): def method(self): print('Bottom') super().method() Bottom().super() would print "Bottom", "Left", "Right", "Top". super, in Left, reffers to Right, which is not a parent of Left (and is completely absent of it's definition) Anyways, i'm called to a pub, i'll talk to you guys more tomorrow, have a great night