ROUND 3 i guess I promised paul moore an up to date proposal, here it is: 1) an alterhitance module, dedicated to all __bases__ (the iterable of parents) alteration operations This replaces the "dependency injection" use case (based on MRO injection, not __bases__ edits), and on its own doesn't need any addition to python itself, however, it relies on today's super ability to handle implicitely remaps of __bases__, and other proposal might remove this capacity, if not accounted for, so i'm leaving this altheritance module in the proposal, just so we all know it's not forgotten about. 2) the adoption syntax, for classes that are designed to work with multiple parent (mixin use case) would replace code from: ``` class MyView(LoginMixin, PermissionMixin, View): ... ``` to ``` class MyView( LoginMixin( PermissionMixin( View ) ) ): ... ``` Essentially, it's a way to tell MyView to inherit from LoginMixin, which in this context inherits from PermissionMixin, which in this context inherits from View. Again, this could be talked about in a separate post, but it is relevant to the current discussion, as Mixins are the most current use case for today's ML. Actually, idk, should i make a dedicated post for it? or should i keep it in this thread, as it is relevant to the end goal? It has value on its own tho. 3) Multiple strategies for diamond problems Essentially, in more general terms, how to handle the case of a class appearing multiple time in an inheritance tree, should it be specialised once? each time? only on some specific occasions? I want to add either a decorator, or a class attribute, or anything for that matter, so that the programmers can choose the strat they need. I've got an idea this night about having the kwargs "use_target_MRO" for super, that might cover this need, i'm not sure. 4) Allowing to pass as argument of super the class you're targeting, which i got the idea this night could be done with a target kwarg. argumentless syntax would behave the same I believe if all those proposal come first, super is not benefitting from MRO anymore, and MRO could be removed. 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. - accessing an attribute that only one parent can provide would work fine, even if multiple parent are present (what matters is the uniqueness of the candidate to resolution) - accessing an attribute that no parent have would raise an AttributeError. - obviously, accessing an attribute defined in the class body would resolve to this attribute - this would apply for attribute and method, just like today's MRO. I personnally have an issue with the fact that today, some class definition are not allowed, because MRO doesn't know how to deal with those scenarios. I'm trying to see if i can come up with a non breaking change alternative, i don't have one for now. The value of this proposal is that today's super feature is widely misunderstood, and even considered deceptive by some. My proposal is built around the idea of making the most straightforward / least surprises UX for the programmer. As some of you mentionned, there are questions to be solved before introducing breaking change. As it is, only change 5 would be a breaking change, and previous proposal have values on their own. I intend this 5 proposal to be produced one by one, not all at once, the order in which i present them is relevant. I'm perfectly willing to try to produce an implementation to these proposal, run it against a selection of python project, and compare their tests output with / without those change, to measure the amount of code that actually breaks. This would give us a very clear idea of the amount of actual breakings, so we could make a more enlightened decision. The adoption proposal would require to come first i think, and start getting used by the community, as removing MRO would most definitely make the old syntax break. Other than that, the use cases of ML are very limited today, so i'm not sure what amount of breakings would be reasonable to expect, after spreading of the adoption feature.