Ricardo Kirkner wrote:
What would the semantics be of a super that intentially calls all siblings? In particular what is the return value of such a call? The implementation can't know how to combine the implementations in the inheritance chain and should refuse the tempation to guess.
I'll give you the example I came upon:
I have a TestCase class, which inherits from both Django's TestCase and from some custom TestCases that act as mixin classes. So I have something like
class MyTestCase(TestCase, Mixin1, Mixin2): ...
now django's TestCase class inherits from unittest2.TestCase, which we found was not calling super. Even if this is a bug and should be fixed in unittest2, this is an example where I, as a consumer of django, shouldn't have to be worried about how django's TestCase class is implemented. Since I explicitely base off 3 classes, I expected all 3 classes to be initialized, and I expect the setUp method to be called on all of them.
If I'm assuming/expecting unreasonable things, please enlighten me. Otherwise, there you have a real-world use case for when you'd want the sibling classes to be called even if one class breaks the mro chain (in this case TestCase).
How does python tell your use-case from, say, this: class Mixin3(unittest2.TestCase): "stuff happens" class MyTestCase(TestCase, Mixin1, Mixin2, Mixin3): ... Here we have django's TestCase that does *not* want to call unittest2.TestCase (assuming that's not a bug), but it gets called anyway because the Mixin3 sibling has it as a base class. So does this mean that TestCase and Mixin3 just don't play well together? Maybe composition instead of inheritance is the answer (in this case, anyway ;). ~Ethan~