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.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/LJUOVC5PRPGDGX73R2T72F5PAZ25OCB5/
Code of Conduct: http://python.org/psf/codeofconduct/
