Greg Ewing writes:
Even if you do, it's still an arbitrary choice to prefer the leftmost method, which might be what you want or might not.
Yep, i 100% agree with you, and that's (one of) my problems with current MI in python, and the reason i named that thread MRO and super don't feel so pythonic And the fact that this python feature doesn't abide by python's zen is an argument against it. Stephen J. Turnbull writes:
Sure, the too tricky somebody may be a library author (hello, Django) in which case the person we're worried about is innocent collateral damage. I'm afraid that person is going to have to put out the effort to learn what the MRO is and how it works, or consult someone who already knows. In any case, I don't see evidence that such collateral damage is anything but a theoretical possibility. That's again the "user's who can't use my feature are the problem, my feature itself doesn't have a problem" mindset. Truth is, user's who can't use a feature properly can be in the wrong, because they didn't learn enough about it, as much as they can be living proof the feature is not mature enough.
to give you exemples of problems : 1) let's start with a django problem : ``` class MyView(ModelView, PermissionMixin): pass ``` doesn't apply any of the PermissionMixin logic to the view. It doesn't raise a single error either. Since it's mostly made out of django stuff, it's likely there wouldn't be automated testing to check if the permissions are indeed required when attempting to visit whatever resource MyView serves. After all, automated testing should test your code, not the library you're importing's code. The only way to tell those permission aren't applied, in this case, is to actually see the bug happen IRL. 2) Another one, straight from django docs : https://docs.djangoproject.com/fr/4.0/topics/auth/default/#django.contrib.au... Some would argue the proper way to do multiple inheritance implies having one single parent class all classes you inherit from do themselves inherit from. This allows you to use super in those class, and still allows you to inherit from each of them individually, as needed, without risking a super call to target object, in which case you'd face the problem that object doesn't have whatever method you're trying to access. What happens when the common parent class raises NotImplemented errors? You can't use super in any of it's child class, and any of its child class using super would work only under MI, if not the last parent inherited from. In other term, you render those 'independant' objects not independant anymore. Note that this django docs explicitely states it is not possible to practice multiple inheritance in this case, which is my point : people don't know a way out of super for MI cases, when super doesn't work. 3) My gobelin exemple is another case. What if you want to inherit from multiple parent 'as is', instead of having them ignore their respective parent (GP) because this parent (GP) is reoccuring in the inheritance tree? 4) Lib refactoring are breaking changes A Lib author refactoring his code by extracting a class as a parent class of multiple of the class provided is introducing a breaking change. Because any user's code inheriting from at least 2 of the class impacted by this refactoring will now exhibit a different behavior. If O1 and O2 are refactored into N1(GP) and N2(GP) the MRO as it was before refactoring was essentially N1, GP, N2, GP, as what was O1 before refactoring is equivalent to N1, GP after refactoring. After refactoring, the MRO is now N1, N2, GP. Which do behave differently, in general. If your point is :
I'm afraid that person is going to have to put out the effort to learn what the MRO is and how it works Then how are any lib user's supposed to account for this case 4? The only way is to never use MI with any class from any lib you're inheriting from... And no, class.method doesn't work in this case either.