malmiteria writes:
> My alternative to super would, since you can just pass it an
> argument telling what parent it should target, it would look like
> that
>
> class A:
> def call_me_in_A_first(self):
> # don't have to calls super
> def call_me_in_B_first(self):
> # don't have to calls super
>
> class B:
> def call_me_in_A_first(self):
> # don't have to calls super
> def call_me_in_B_first(self):
> # don't have to calls super
Shouldn't A and B derive from Parenting? Or is it C that should?
> class C(A,B):
> def call_me_in_A_first(self):
> __as_parent__(A).call_me_in_A_first()
> __as_parent__(B).call_me_in_A_first()
> def call_me_in_B_first(self):
> __as_parent__(B).call_me_in_B_first()
> __as_parent__(A).call_me_in_B_first()
Consider
class D(A,B):
def call_me_in_A_first(self):
# arguments supplied to first call for symmetry
super(D,self).call_me_in_A_first()
super(A,self).call_me_in_A_first()
def call_me_in_B_first(self):
# arguments supplied to second call for symmetry
super(A,self).call_me_in_B_first()
super(D,self).call_me_in_B_first()
How does the behavior of class C differ from class D? I don't think
it does.
I'll grant your API is nicer for exactly this purpose, but I suppose
there are reasons why the API is designed for starting at the *next*
in MRO rather than the specified type, and requires self to be
specified. Aside from being a little prettier in this case, what
advantages are you claiming for __as_parent___?
_______________________________________________
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/NYJ73JHM3TZGUU5OJZPZ6HHVKZE6NCMQ/
Code of Conduct: http://python.org/psf/codeofconduct/
