Is super() broken in Python-2.x?
super() is not broken — it just should not be considered the standard way of calling a method of the base class. This did not change with Python 3.x. The only thing that changed is that you dont need to pass the arguments
self, cls in the standard case that
self is the first parameter of the current function and
cls is the class currently being defined.
Regarding your question when to actually use
super(), my answer would be: hardly ever. I personally try to avoid the kind of multiple inheritance that would make
Edit: An example from real life that I once ran into: I had some classes defining a
run() method, some of which had base classes. I used
super() to call the inherited constructors — I did not think it mattered because I was using single inheritance only:
class A(object): def __init__(self, i): self.i = i def run(self, value): return self.i * value class B(A): def __init__(self, i, j): super(B, self).__init__(i) self.j = j def run(self, value): return super(B, self).run(value) + self.j
Just imagine there were several of these classes, all with individual constructor prototypes, and all with the same interface to
Now I wanted to add some additional functionality to all of these classes, say logging. The additional functionality required an additional method to be defined on all these classes, say
info(). I did not want to invade the original classes, but rather define a second set of classes inheriting from the original ones, adding the
info() method and inheriting from a mix-in providing the actual logging. Now, I could not use
super() in the constructor any more, so I used direct calls:
class Logger(object): def __init__(self, name): self.name = name def run_logged(self, value): print Running, self.name, with info, self.info() return self.run(value) class BLogged(B, Logger): def __init__(self, i, j): B.__init__(self, i, j) Logger.__init__(B) def info(self): return 42
Here things stop working. The
super() call in the base class constructor suddenly calls
BLogged cant do anything about it. There is actually no way to make this work, except for removing the
super() call in
[Another Edit: I dont seem to have made my point, judging from all the comments here and below the other answers. Here is how to make this code work using
class A(object): def __init__(self, i, **kwargs): super(A, self).__init__(**kwargs) self.i = i def run(self, value): return self.i * value class B(A): def __init__(self, j, **kwargs): super(B, self).__init__(**kwargs) self.j = j def run(self, value): return super(B, self).run(value) + self.j class Logger(object): def __init__(self, name, **kwargs): super(Logger,self).__init__(**kwargs) self.name = name def run_logged(self, value): print Running, self.name, with info, self.info() return self.run(value) class BLogged(B, Logger): def __init__(self, **kwargs): super(BLogged, self).__init__(name=B, **kwargs) def info(self): return 42 b = BLogged(i=3, j=4)
Compare this with the use of explicit superclass calls. You decide which version you prefer.]
This and similar stories are why I think that
super() should not be considered the standard way of calling methods of the base class. It does not mean
super() is broken.
super() is not broken, in Python 2 or Python 3.
Lets consider the arguments from the blog post:
- It doesnt do what it sounds like it does.
OK, you may agree or disagree on that, its pretty subjective. What should it have been called then?
super() is a replacement for calling the superclass directly, so the name seems fine to me. It does NOT call the superclass directly, because if that was all it did, it would be pointless, as you could do that anyway. OK, admittedly, that may not be obvious, but the cases where you need
super() are generally not obvious. If you need it, you are doing some pretty hairy multiple inheritance. Its not going to be obvious. (Or you are doing a simple mixin, in which case it will be pretty obvious and behave as you expect even if you didnt read the docs).
If you can call the superclass directly, thats probably what youll end up doing. Thats the easy and intuitive way of doing it.
super() only comes into play when that doesnt work.
- It doesnt mesh well with calling the superclass directly.
Yes, because its designed to solve a problem with doing that. You can call the superclass directly if, and only if, you know exactly what class that is. Which you dont for mixins, for example, or when your class hierarchy is so messed up that you actually are merging two branches (which is the typical example in all examples of using
So as long as every class in your class hierarchy has a well defined place, calling the superclass directly works. If you dont, then it does not work, and in that case you must use
super() instead. Thats the point of
super() that it figures out what the next superclass is according to the MRO, without you explicitly having to specify it, because you cant always do that because you dont always know what it is, for example when using mixins.
- The completely different programming language Dylan, a sort of lisp-thingy, solves this in another way that cant be used in Python because its very different.
super()doesnt call your superclass.
Yeah, you said that.
- Dont mix
super()and direct calling.
Yeah, you said that too.
So, there is two arguments against it: 1. The name is bad. 2. You have to use it consistently.
That does not translate to it being broken or that it should be avoided.
Is super() broken in Python-2.x?
You seem to imply in your post that
def some_func(self, *args, **kwargs): self.__class__.some_func(self, *args, **kwargs)
is not an infinite recursion. It is, and super would be more correct.
Also, yes, you are required to pass all arguments to
super(). This is a bit like complaining that
max() doesnt work like expected unless you pass it all the numbers you want to check.
In 3.x, however, fewer arguments are needed: you can do
super().foo(*args, **kwargs) instead of
super(ThisClass, self).foo(*args, **kwargs).
Anyway, Im unsure as to any situations when super should be avoided. Its behavior is only weird when MI is involved, and when MI is involved,
super() is basically your only hope for a correct solution. In Single-Inheritance its just slightly wordier than
SuperClass.foo(self, *args, **kwargs), and does nothing different.
I think I agree with Sven that this sort of MI is worth avoiding, but I dont agree that
super is worth avoiding. If your class is supposed to be inherited,
super offers users of your class hope of getting MI to work, if theyre weird in that way, so it makes your class more usable.