If the only feature you need from super is the proxy one, why don't you code your own parent-proxy-type?
class parentproxy: def __init__(self, cls, obj): self.__thisclass__ = cls self.__self_class__ = type(obj) self.__self__ = obj def __getattr__(self, name): attr = getattr(self.__thisclass__, name) if hasattr(attr, '__get__'): attr = attr.__get__(self.__self_class__, self.__self__) return attr class A: x = 0 y = 1 def method(self): return 'A.method' class B(A): y = 2 def method(self): return 'B.method' obj = B() # prints 0, 0, 0 print(obj.x, parentproxy(B, obj).x, parentproxy(A, obj).x) # prints 2, 2, 1 print(obj.y, parentproxy(B, obj).y, parentproxy(A, obj).y) # prints B.method, B.method, A.method print(obj.method(), parentproxy(B, obj).method(), parentproxy(A, obj).method()) It gives the proxy you need and it works well with multiple inheritance too. Le jeu. 7 avr. 2022 à 13:14, malmiteria <martin.mi...@ensc.fr> a écrit : > Greg Ewing writes: > > If I were teaching a newcomer about super, I wouldn't even tell them > > that it *has* a class argument. So they wouldn't have any expectation > > about targeting, because they wouldn't know about it. > > I would probably teach newcomers the argumentless form only too. That's > all they'll need. But argument or not, they need to know "what" does super > proxy, and the simple answer, for a newcomer, is "the parent". > If they were to ask me what happens when there's multiple parents, i would > definitely have to tell them not to go there, today at least, since today's > multiple inheritance is complex. > But if there was a way to tell super what class it should be a proxy of, > that would be very easy to explain : when there's two parent, just give the > parent you want to target as an argument to super. > > > It's a delicate > > operation that requires knowing a *lot* about the classes you're > > blending together. > > In this case, the fact that both class names have the form > > <adjective>Gobelin would make me suspect quite strongly that they > > *do* have some common ancestry. > > It requires knowing a *lot* about the classes you're inheriting from, > *today*, and that's a problem I'm trying to adress. > And you being able to tell those 2 classes have some sort of common > ancestry wouldn't be of much help if you don't already know about MRO and > the effect it might have on inherited classes in case of multiple > inheritance. > So you would already need to be quite knowledgable about MRO and multiple > inheritance to got the result you expect here. > > If super were to only target the parents, either the only parent for the > argumentless form, or the specified parent in case of MI, this scpeific > scenario wouldn't require you to have any extra knowledge on MRO / super / > MI. > It would already behave exactly like you would expect. > > Of course there are use cases for super following MRO. Those need to be > covered too, and not get rid of. > I think the ability of super to handle remaps after MRO injections should > be conserved, so the scenarios in which we would pass directly the class we > wanna target should allow for remapping of the parents. > Not that there's a common use for it, but still. > > The Mixin use case, where we explicitely use the super ability to side > jump so that our mixin 'specialise' the last class in MI order would really > benefit from a feature allowing a class to select a parent after being > defined. > This is the meaning of my adpotion proposal, and i believe this use case > to be the most common use case of MI in python. > We could actually consider it a case of simple inheritance that didn't say > its name. > The adoption proposal would convert those MI cases back to SI cases. > > The diamond problem on its own requires specific attention, as the gobelin > exemple i give showcases a case where we would most definitely want the top > class to be called every time it appears in the inheritance tree, but there > are other cases where we most definitely want the top class to be called > only once, case such as ORMs doing commits to databases. > My proposal is to implement a way to allow the programmer to decide what > strategy fits their needs. > the 'use_parent_mro' keyword of super would work nice in today's context, > perhaps not so nice assuming all other changes i advocate for passed first. > A class decorator / attribute deciding the strategy super should use is an > option too. Follow MRO / follow inheritance tree for exemple would be 2 > simple options. > honestly, idk what design would be the best for this case, all i know is > that the solution should allow for multiple strategies. > > ---- > Chris Angelico writes: > > I'm curious when you would ever be subclassing something from another > > library without knowing its hierarchy. > This is common in Django. > > ---- > Stephen J. Turnbull writes: > > One really plausible example is given in Raymond's piece: a later > > version of the same library refactors a "monolithic" class as a child > > of one or more "private" classes that are not intended to be exposed > > in the public API, but your multiply-derived class *written before the > > refactoring* Just Works. As far as I can see, super(), and maybe even > > the deterministic MRO, is needed to make that work. > I'm curious about this exemple, do you have a link to share so i could > have a look at the code / change in code? This could be a good exercice. > _______________________________________________ > 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/LRKJNN7RQUEYURNZZTSRDDXBEJQO5AMA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Antoine Rozo
_______________________________________________ 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/BETUQI4NEOCPQNX6PN23QITFLVNK5RZK/ Code of Conduct: http://python.org/psf/codeofconduct/