> On 26 Mar 2022, at 18:15, malmiteria <martin.mi...@ensc.fr> wrote:
>
> the alternative to super really is not the important part of my proposal,
> it's the alternative to MRO.
>
> An example of a case where i genuinly believe my solution adds value is this :
>
> ```
> class A:
> def method(self):
> print("A")
>
> class B:
> def method(self):
> print("B")
>
> class C(A, B):
> pass
> ```
>
> Today, a code such as ```C().method()``` works without any problems
> except of course when the method you wanted to refer to was the method from B.
> If class A and B both come from libraries you don't own, and for some reason
> have each a method named the same (named run, for example)
> the run method of C is silently ignoring the run method of B.
>
> I believe it would make the programmers life easier to have an error at this
> time, or anything tbh, to make explicit this resolution, because it really is
> not explicit from most programmers perspective
>
>
> my alternative to super comes to fit the alternative to mro, i think it
> stills matter to have a dedicated feature instead of simply calling
> class.method, this allows for more error handling and stuff like that, in
> case for example you're calling super on a class that's not a parent for
> example, since super really is for accessing parents context.
> This is not so much about final code, but more about making it easier *when*
> writing code. But the final code would definitely not look that much prettier
> / ugglier, I agree
>
> And finally, super is not a proxy to parents, even plural, it's a proxy to
> the next in mro order.
>
> in this case :
> class Top:
> def method(self):
> print('Top')
> class Left(Top):
> def method(self):
> print('Left')
> super().method()
> class Right(Top):
> def method(self):
> print('Right')
> super().method()
> class Bottom(Left, Right):
> def method(self):
> print('Bottom')
> super().method()
>
> Bottom().super() would print "Bottom", "Left", "Right", "Top".
> super, in Left, reffers to Right, which is not a parent of Left (and is
> completely absent of it's definition)
My feeling is that if I was doing a code review of this sort of code I would be
raising two possible issues.
1) You have a class that does more than 1 thing. That is an OO code smell. Use
composition to avoid.
2) If you have a parent class that has a method that conflicts then I would say
that you need to
add a facade to allow one of the conflicting method names to be accessed via
another name.
For example
Class FacadeB(B):
def method_in_B(self, *args, **kwds):
B.method(self, *args, **kwds)
Barry
>
>
>
> Anyways, i'm called to a pub, i'll talk to you guys more tomorrow, have a
> great night
> _______________________________________________
> 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/EWMRM6HIDK4XJPEV7R3WETVP72SUT4RA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/OB5KXXGVCQABFVL242EMB7RV4GAHTPEO/
Code of Conduct: http://python.org/psf/codeofconduct/
