Thanks for your answer. On Mon, 11 Apr 2022 at 00:46, malmiteria <martin.milon@ensc.fr> wrote:
There's a few problems, mainly, if you provide ProudGobelin and CorruptedGobelin as a lib author, you're very likely not to think of the HalfBreed use case, so the lib users wanting to create the HalfBreed class is bared from this solution, as it requires some work on ProudGobelin and CorruptedGobelin classes.
Starting from the "lib" definitions of HighGobelin, CorruptedGobelin and ProudGobelin you originally wrote, the lib user can surely have a similar solution, but, it will take many more (though straightforward) steps. So, if the lib code was that, MRO doesn't seem to be the most helpful thing for the lib user. (I assume, with your solution, the other behaviour of HalfBreed, that is, the original behaviour of it with the "failing" code, can also be achieved as easily in the case where that is what the lib user wants. Does this hold?) By the way, On Mon, 4 Apr 2022 at 02:11, malmiteria <martin.milon@ensc.fr> wrote:
Getting the correct behavior requires to let go of super, in such a way:
``` class HalfBreed(ProudGobelin, CorrupteGobelin): def scream(self): if random.choices([True, False]): ProudGobelin.scream(self) else: CorrupteGobelin.scream(self) ```
I don't think this is better than the failing code in any way. It will fail in the same way. If you stopped using super in ProudGobelin.scream, then you would have been good, even though that's not necessary as I already said. The lib user can't complain the use of super when it does the job for the lib author, but what I felt from the example is there might be some notion of abuse of super, perhaps. Best regards, Takuo Matsuoka