[Python-Dev] python and super

[Ethan Furman]

Ricardo Kirkner wrote:
> 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.

I have to disagree -- anytime you are using somebody else's code you 
need to be aware of what it's supposed to do -- especially when playing 
with multiple inheritance.

This response to the decorator I wrote for this situation may be helpful:

Carl Banks wrote (on Python-List):
 > The problem is that he was doing mixins wrong.  Way wrong.
 >
 > Here is my advice on mixins:
 >
 > Mixins should almost always be listed first in the bases.  (The only
 > exception is to work around a technicality.  Otherwise mixins go
 > first.)
 >
 > If a mixin defines __init__, it should always accept self, *args and
 > **kwargs (and no other arguments), and pass those on to
 > super().__init__.  Same deal with any other function that different
 > sister classes might define in varied ways (such as __call__).
 >
 > A mixin should not accept arguments in __init__.  Instead, it should
 > burden the derived class to accept arguments on its behalf, and set
 > attributes before calling super().__init__, which the mixin can
 > access.
 >
 > If you insist on a mixin that accepts arguments in __init__, then it
 > should should pop them off kwargs.  Avoid using positional arguments,
 > and never use named arguments.  Always go through args and kwargs.
 >
 > If mixins follow these rules, they'll be reasonably safe to use on a
 > variety of classes.  (Maybe even safe enough to use in Django
 > classes.)

~Ethan~