Chris Angelo writes :
> You start out with the assumption that MOST PEOPLE think of super as a
> way to call THE, singular, parent. If this is indeed a problem, then
> it's not a problem with super, it's a problem with expectations.
This is not so much a problem as this is the context we're working under.
If we're defining / updating features of the langage, people understanding of 
the langage do matter.
A feature that would stick closer to the expectation of most people would 
provide a much smoother learning curve, for most people.
And just to make it clear, I am not under the impression super can only target 
one class.
What i'm saying here is that it is the most common impression the average 
developper would have.


> I got a little bit further into your post and found you fighting hard
> against the existing feature, and that's when I gave up on reading it.
ugh.
Let's make it simple then. Do you agree this list to be a comprehensive list of 
use case / feature of today's MRO + super:
1) method resolution
2) parent proxying
3) dependency injection
4) sideway specialisation (Mixins use case)
Not really a use case / feature, but related:
5) the diamond problem

If you have any doubts about what i mean by any of those, i describe them at 
the top of my lengthy post.

> You've already been given a solution to your problem: if you don't
> want super, don't use super.
And lose dependency injection and sideway specialisation. (And obviously the 
proxying feature)
Which is the most common complaint against my proposal : the loss of those use 
cases.
And my proposal now accounts for those cases, unlike this solution.

> At the very least, test all your code blocks and
> fix the typos in those.
I do test my code blocks, but if you find errors, please let me know.
About typos, english is not my native langage, so i'm most likely blind to some 
of them, as much as i wanna apologise, it's not really in my control, again, 
let me know if some of them hurt your eyes.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5J7XYWQ5SVGGFBUO6GCUQ7ODCM2O53EP/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to