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~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4