Paul Moore writes: > > super(A, self) does not proxy to A, but to the first *after* A in MRO order. > Correct, that's how it's defined to work. Glad we're on the same page so far. I love you profile pic by the way
> That's the point - the type > argument to super() can be omitted in 99% of cases Yep, and my proposal would make it behave reasonably similarly in those cases Always the same for simple inheritance. Diamond case would behave the exact same too, as my proposal is to implement multiple "diamond strats", and default to the current one mixins cases would have their dedicated syntax (adoption / postponed inheritance), but no changes to lines of code with super would be needed in those cases. Only the class definition line would change, only for the class integrating those mixins. And for the class dependency injection, my proposal is to rely on __bases__, so it wouldn't be an issue either (in cases of the argumentless syntax). > using super() in a case where you're trying to > force a specific resolution path is *not what super is for*. Cases where the super reliance on MRO is not fitting the need still would benefit from super proxying feature. The syntax "proxy to another class".method is still valuable, no matter if super "targeting" feature matches my needs or not. super has too many responsibility, my proposal(s) goal is to untangle them. honeslty, when's the last time you looked at a piece of code that was doing way too many thing and thought to yourself "this is my definition of perfection". This would allow the Gobelin exemple to still benefit from today's super's proxy feature, while allowing it also to not integrate today's super's reliance on MRO. > *especially* not if there are other solutions available in Python > today, which don't use super. There's not a solution that provide today's super's proxy feature without today's super's reliance on MRO feature. Well except I implemented it i guess, but that's not python, that's me, and i'm pretty sure you wouldn't want that near anything you love :p > If you're trying to hit a nail into a > piece of wood, and your screwdriver isn't doing a good job at it, that > means that you should learn about hammers All we have today is the screwhammer, and in cases the screw part don't work, you're telling me to get rid of it all. hammer part included. I'm telling you maybe we should break the screwhammer apart into a screwdriver and a hammer. Stop answering to me "but this is not how to use a screwhammer". I know. _______________________________________________ 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/PRLDID4QPWRH2V3TNVJWYIIHEZO7QBUU/ Code of Conduct: http://python.org/psf/codeofconduct/
