On 7/04/22 11:11 pm, malmiteria wrote:
But if there was a way to tell super what class it should be a proxy of, that would be very easy to explain : when there's two parent, just give the parent you want to target as an argument to super.
That sounds like exactly what Class.method(self) does today. Why do we need another way to do it? It requires knowing a *lot* about the classes you're inheriting from, *today*, and that's a problem I'm trying to adress.
And you being able to tell those 2 classes have some sort of common ancestry wouldn't be of much help if you don't already know about MRO and the effect it might have on inherited classes in case of multiple inheritance.
That's not the kind of knowledge I'm talking about. You need to know a lot about how those particular classes behave -- what their methods do, whether they would conflict with each other in any way, what the consequences would be of calling them in various orders, etc. You seem to think that removing the MRO and making super work the way you imagine it should would make it easy to grab any bunch of arbitrary classes and inherit from them and everything would be fine and dandy. It would not!
The Mixin use case, where we explicitely use the super ability to side jump so that our mixin 'specialise' the last class in MI order would really benefit from a feature allowing a class to select a parent after being defined.
I still don't understand how you expect a particular super call in a particular method to somehow be able to jump sideways when you want it to and not other times. You'll have to provide a detailed example, not just vague waffling about mixins and proxying. -- Greg