Greg Ewing writes:
It does this because the way it's intended to be used is to pass it the class in which the method you're calling it from is defined.
It doesn't really matter what's the intended way for it to be used tho, what matters when it comes to designing / updating the design of a feature is how people are using it today, and what people expect it to do naturally. Taking this into account is the easiest way to make an intuitive feature. The way it is intended to be used as virtually no value (when it comes to designing / updating the design of a feature). And updating the super feature(s) is what i'm proposing here.
Now that we have argumentless super, there's no longer any need to do that [pass argument to super].
Some exemple i give including, but not limited to the gobelin exemple are a fair use case in which you'd want to use the argumented version of super. The fact that today's super doesn't work in those scenario just means super doesn't work in all scenarios, I believe the scenarios i built to be fairly consistent with the average developper expectation of super's behavior, based on acquired knowledge on use of super in the general cases.
If you're using super at all with MI, your methods should all be designed so that it *doesn't matter* exactly what order they get called in This doesn't match the mixin case, which is the most common use today for ML. Essentially, in this case, you have a collection of parent class, all of which would benefit from having the same variant child class. The exemple i always give : you have multiple view class, you have the permission mixin, so you (as a lib author) wanna provide all possible combinations of simple view class, and permission mixin augmented view class. today's only (reasonable) way is ML.
class MyView(Permission, View): ...
This explicitely rely by design on the fact that permission comes before view. I'd argue this is a case of "I can't declare inheritance at definition, and I can't declare it later either, so we have to resort to ML" And this is covered by my adoption proposal, which allows for setting inheritance relationship in the MyView class. ``` class MyView( Permission( View ) ): ... ``` But I agree with the feeling that you should not expect an order between the parents. And essentially, if i get you right here, you're saying that ML should be designed (when we use it, at least) so that we could reorder the parent in the class definition, and it wouldn't matter, wouldn't break anything. Essentially, (i'm talking about what i understand you consider a properly designed ML scenario): ``` class A(P1,P2): ... ``` Is 100% equivalent of ``` class A(P2,P1): ... ``` correct me if i'm wrong. My proposal makes this an explicit feature of ML. As you have to think of a lot of things to make it work this way today, and this would be the default with my proposal. And as mentionned, there are cases that simply can't work this way. Also, i do wanna mention that you do in fact care, to some extent to which order things are called in. Not always, but in some cases you do, and not being able to target one of the parent first, instead of the default one, when the default one is not appropriate is a problem. Essentially, if for any reasons today, MRO is not consistently the good order for you, all you can do is forget about it. When really, there's no reason (not in term of UX i mean) to be so opinionated.