April 3, 2022
2:12 p.m.
Paul Moor writes :
> PS Please don't respond to this with another wall of text. I won't
> read it.
I'll try my best, just tell me if this is too long.
> your fundamental
> misconception that there is always a single well defined "parent
> class"
I don't hold such a conception
> In practice there are cases (which have been noted here) that
> don't follow that pattern. And if you don't take that into account,
> any proposal you make will be flawed.
That's why I am accounting for them.
To quickly list the cases i account for :
- the ability of super to 'side jump' used for mixins
- dependency injection
- diamond inheritance
I dedicate one proposal to each of those cases, and one to the proxying feature of super, and one to method resolution.
> > a dedicated module for dependency injection and more called alterhitance
> That's not a feature of the current MRO+super.
Today's MRO + super allows for dependency injection (by inserting a class in between other in MRO order), my proposal is to dedicate a module to this feature, which as you mentionned could be published to PyPI now, and i'll be working on it
> > a way to declare inheritance after defining the class (postponed inheritance)
> If you want this as a Python feature, you'll need to describe use
> cases and semantics
Use cases : Mixins.
When we define a child class that could be applied to multiple parent class, we have to define the child independently first, not inheriting from any parent, otherwise we would need to repeat the child definition for each parent.
Syntax:
```
class MyView(
PermissionMixin(
View
)
):
```
Which just makes use of the child(parent) syntax, and extends it to allows for deeper inheritence tree definition at class definition time.
> > a solution to the diamond problem
> You haven't demonstrated that there's a problem to be solved.
The problem called "diamond problem" is a classic of multiple inheritance, an exemple here that was already posted on this thread : https://stackoverflow.com/questions/55829798/c-diamond-problem-how-to-call-base-method-only-once.
When a class appear multiple time in an inheritance tree, should call to this class methods occur multiple times?
In case the class appearing multiple time does commits to a database, we don't want multiple calls.
In case such as the exemple i described in my lengthy post, we do want all those calls.
I propose a decorator / attribute that would allow users to define the strategy they want.
> > changes to the proxy feature of super (that i already mentionned earlier in this thread)
> What's wrong with how it is now?
when we wanna use super to proxy a class that is not the next in MRO order, we have to pass as argument of super the class that comes before the one we target in MRO order. This API is a bit weird.
And again, i think that despite all the values of its current form, the fact that it can target sideway for one is not easy to understand (i mean, that's what y'all are accusing me of, not understanding it) and makes for a hard learning curves. Which is a problem. A smoother learning curve would be preferable
> > changes to the method resolution algorithm (that i already mentionned earlier in this thread)
> Same as for (4), what's wrong with it now?
Essentially two things :
1) when two parent class provide the same attribute, the child resolves it to the first parent attribute, and silently ignores the second parent attribute.
2) Some inheritance tree produce inconsistent MRO, those class definition raise an error at definition time.
> Overall, you stand very little chance of getting anywhere with this as
> you seem to be unwilling to make the attempt to understand people's
> objections
I've incorporated most peoples remarks and objection to my proposals, as i hope this shorter answer helped you realise.
PS: I'm trying my best to understand anyone remarks / the current state of the features.
I don't think most of you are fair tho. I do understand fairly comprehensively those features.
Idk how some of you are still under the impression that i think super targets the same class no matter what for exemple.
I eventually disagree that this makes for a great proxying feature, which i assume some of you understand as me completely rejecting it's value.
So, allow me to make it clear, I do get its value. Its value appears in the other use cases i account for, and wanna provide dedicated features for. (before getting rid of super and MRO's ability to provide those use case).
PSS: I hope it wasn't too long.