Stephen J. Turnbull writes: > Shouldn't A and B derive from Parenting? Or is it C that should?
Having Parenting anywhere in the inheritance tree would work with the current implementation i have for it. I intended it to be a root parent of any class without pre existing parent. -- > How does the behavior of class C differ from class D? I don't think it does. As a part of bigger inheritance trees, most scenarios would behave the same, but since mro is prone to dependency injection, having a call so super(A, self) and super(D, self) in the same method is dangerous. And especially, in this case your goal with making this use of super is to control tightly what parent method is called in what order. MRO as it stands prevents you from any certainty on that regard, whereas my solution is much more reliable on what method it targets. An idea that i can add on this example is that it seems unlikely you'll be using super without the intent of always resolving the same method. I mean, when else do you call a method but would think reasonable to expect to be delivered another one? Do you even do that when using super? i doubt it. A close enough scenario is when you intent to do dependencies injection. Which is often portrayed as a feature of the current MRO + super objects. But such a feature is not hard to introduce within my explicit method resolution + __as_parent__. (more on that later) And my __as_parent__, with or without this dependency injection feature added on the side will keep behaving like you'd expect to. Of course, denying the possibility of dependency injection is not something i'm arguing, i think it should be preserved, but as a side feature. To tell a bit more about how to allow dependency injection with my __as_parent__, the target argument could be matched against a remap dict, that could be set as extra argument, class attribute, or whatever, to allow for replacing a target class. The replacment can then inherits from the original class, and voila, you got your dependency injection. Without the need for MRO _______________________________________________ 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/L5ZNVZLOOJP4PMJDFTXTOSCGTUWZ5CDY/ Code of Conduct: http://python.org/psf/codeofconduct/
