On Tue, Apr 05, 2022 at 04:27:45PM +0100, Paul Moore wrote:
On Tue, 5 Apr 2022 at 12:37, malmiteria <martin.milon@ensc.fr> wrote:
5) replacing MRO with a method resolution that I describe at the top of my post: - accessing an attribute / method that multiple parent can provide would raise an ExplicitResolutionRequiredError, those errors can be solved by defining the attribute in the child class, and performing the "merge" as you'd want it there.
Roughly speaking, this is how traits behave. Multiple inheritence with large class hierarchies can be a real problem. It can lead to horrific spaghetti code, and as we can see in this discussion, some (many?) people do not really "get" inheritence in a multiple inheritence world.
So making the programmer do all the work, rather than having a default behaviour that works in at least some cases. That's strictly worse than the current behaviour.
I don't think that malmiteria proposes to force users to do *all* the work, but only in cases where there is ambiguity. Instead of linearising the MRO, I think malmiteria wishes the user to choose their own order resolution for that specific method. That is very similar to the way traits work. See Michele Simionato writings on the topic. I've already posted the links here: https://mail.python.org/archives/list/python-ideas@python.org/message/6M7XPN... Michele also wrote the original Python 2.3 guide to super and the MRO, so he understands how and why super does what it does. But he has come to see that MI is a trap, that leads to massively over-complicated and confusing class hierarchies with hundreds of methods and convoluted inheritence DAGs in real world frameworks. Traits are one partial solution which can be used as a way to tame MI into something understandable by human beings rather than Skynet :-) There are other solutions to this complexity too. Generic functions is another, and composition/delegation. The point is that simple code is better code, and multiple inheritence with complex DAGs is far from simple, so we should try to avoid it when possible.
The value of this proposal is that today's super feature is widely misunderstood, and even considered deceptive by some.
What *evidence* do you have for that?
Hmm, well I don't know if this would meet the standards required for a court case, but I thought that it was common knowledge that super() is widely misunderstood and considered a black art by many Python programmers. Have a look at Stackoverflow, or such blog posts as "super considered harmful". Even Raymond Hettinger's *excellent* article on super considered super is evidence for the widespread confusion over super. If people didn't misunderstand it, or misuse it, Raymond wouldn't have needed to write the article. I for one frequently find myself being surprised by super and the MRO, which I interpret as *my misunderstanding* rather than a problem with super and the MRO. As soon as you leave the nice, cosy world of single inheritence, things get complicated.
In reality, I think super is only occasionally used, mostly only for straightforward cases,
Naturally single inheritence is significantly more common than multiple inheritence, but MI is not precisely *rare* in the Python ecosystem. -- Steve