On 12 Apr 2022, at 13:17, malmiteria <martin.milon@ensc.fr> wrote:

Steven D'Aprano writes:

So in the general case, order matters. We have to linearize the
superclasses, and call them in that linear order, and the best way to do
that is with the MRO and super.
Why would we *have* to do that?
When multiple parent provide candidate to a method resolution, raise an error.
The child class now has to redefine the method, and in the body of that method, can decide which parent method call, or in what order call them.
That's essentially the basic idea of my proposal.

To be blunt: That’s not going to happen because this is big backward compatibility break. Either that, or this adds a second way to define classes.  Both are good reasons to keep the status quo.

You’re of course free to create a library that checks for this at runtime, or as a lint tool. 


Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/