malmiteria writes:
Why would this be the order you wanna call all the methods provided by the parents?
It works often. ;-) My guess would be that typical multiple inheritance scenarios are of the form "I want my child class to have the behavior of classes earlier in the declaration order, *unless* the behavior is inherited and I explicitly override it by explicitly declaring an overriding class." Why this would work "right" in cases like class C(A, B) where A inherits a method from its grandparent and B inherits from its parent, I don't know. But that's the way I expect C to behave when A inherits a method and B implements it directly.
It seems possible that for some method, the wanted order won't be the same all throughout the class.
That's why super can take arguments. I know you don't like the arguments it takes, but it makes it possible to resolve the problem, although for methods not defined in the parents you may have to reach arbitrarily far into the MRO to get the instance you want of that method. I doubt that __as_parent__ solves the "arbitrarily deep" problem (although you may be able to persuade me it will work "better" "most of the time").
I think most people when they use super are just saying, call the parent method, since that's what it visibly does in simple inheritance, and that's what most people will face in their programming lives.
True. But that's irrelevant to this discussion, because (a) there are people who use it for more advanced purposes and (b) it can't cause you any confusion in that case.
The problem still relies on MRO in the end, which is the thing that needs reworking the most: My point is that : it is not correct to assume it is meaningful to give an order to multiple inheritence
But C3/super assumes nothing of the kind. First, in some cases the C3 algorithm fails to produce an MRO, and you get an error at class definition time. Second, of course it's *meaningful* to give an order to multiple inheritance. Sometimes that order is *not useful*. Other times it may be *confusing*. Pragmatically, C3 seems to give useful results frequently, unuseful or confusing results infrequently (except for people who don't understand C3 and randomly change code, who will be confused frequently).
It make sense to say a child is more specific than its parents, because that's literraly what inheritance is, but saying that parent 1 is more specific than parent 2 is... weird to say the least.
It doesn't say that. It says that parent 1 comes before parent 2 in the MRO. It turns out that this is useful to quite a few Python programmers.
Please re read the list of features i proposed for the alternative to MRO
Have you specified when the ExplicitResolutionRequired error is raised (at class declaration time or method resolution time)? I don't see it. (No, I'm not going to read your code for the implementation, I'm interested in the specification.) You can't have "reliability" without disabling super, I suspect, since you can't prevent stdlib or 3rd-party code from using it, and I believe that means method resolution in that code will depend on MROs, even if you can specify the root of the class subtree explicitly. I doubt disabling super would be acceptable to Python core devs, and it would very likely make the stdlib less than useful to you. I'm not sure I like "reliability" as a requirement. The point of MRO is that it is an attribute of the object. That means that if the object is a subclass of list and it has a my_sort method, regardless of which class in the tree calls super().my_sort, it will get the same order. You can assume that any method documented as "sorts the list in-place" will leave it in the same order. But with a "reliable" __as_parent__, it's possible that a method defined in the child calls __as_parent(SmallestFirst).my_sort(), while a method in the parent calls __as_parent(LargestFirst).my_sort(). This may be a problem. I don't understand "ancestors as targets". If there's a name collision between grandparents, that will already raise ExplicitResolutionRequired. So a child of those grandparents must use __as_parent__, which resolves the problem in the default case. Do you just mean that if for this particular grandchild, you don't want the default resolution, you can use __as_parent__(grandparent_a)? I don't understand "transmitting errors". If the error is raised at declaration of the parent, you don't need to transmit; you won't get to execute the declaration of the child. If the error is raised at method resolution time, what happens if you never try to resolve it? How about a case where the parent doesn't specify a resolution of a collision between grandparents, but no code tries to resolve that method? Shouldn't the child be allowed to use __as_parent__ there?
It is very similar to MRO in cases there's no conflict, but simply raises an error in case there's a conflict.
I don't much like your definition of "conflict". Mine is "when super() does the wrong thing", which (surprise!) it almost never does for me, and I've never used the two-argument form (except in my other post to you): class.method calls have always been adequate. I've never seen a case where I couldn't diagnose the need to override the MRO from the class declaration. Not saying problem cases don't exist, just that I'm perfectly happy with C3 MRO and super().