class decorator aren't propagated through inheritance, so i just made it with a good ol' parent class. again, feel free to take a look at my implementation of it here: https://github.com/malmiteria/super-alternative-to-super It's thorougly tested, and hopefully a good showcase of what it does. But yeah, i think i agree with everything you say, the child needs to implement its version of the method for it to work properly, and the inheritance is a tight coulpling. My proposal would just make it more explicit from the developper perspective, as in, if you're trying to access a method you didn't override in the child class, and on top of that, both parent can resolve it, you get an error. I assume in other cases, the resolution could still be implicit. I think the set of rules i propose for my version of method resolution covers all cases, by simply adding this error case to what's the current external behavior of MRO Because you're not supposed to let that hanging like that. And current MRO would not raise any error, and be completely silent on that. which is an issue.