1

Quick question about Python(ic) inheritence: what is the difference between the idiom posted here (super(ChildClass,self).method(args)) vs. the one on the Python docs site (ParentClass.method(self,[args]))? Is one more Pythonic than the other?

Community
  • 1
  • 1
tudor
  • 43
  • 7

1 Answers1

4

Using super(ChildClass, self).method(args) allows you to walk the method resolution order and -- if everyone but the last parent uses super -- call every class in the hierarchy exactly once. (Not that super only works with new-style classes.)

Using ParentClass.method(self, args) calls one specific class. It does not work when involved in multiple inheritance.

This article provides some description of the issue and clarifies a lot of issues for some people. I don't agree with all of its conclusions, but it provides good examples and discussion.

Mike Graham
  • 73,987
  • 14
  • 101
  • 130
  • Yeah I've yet to find any possibility how to make `super()` useful in face of possible multiple inheritance. Seems to me like not taking arguments in object's `__innit__` makes the whole argument moot. Pity that :/ See also [this](http://freshfoo.com/blog/object__init__takes_no_parameters) which is quite short but brings it to the point I think :) – Voo Sep 02 '11 at 21:49
  • Dealing with `__init__` is precarious because of a few reasons: 1) `__init__`'s signature becomes the constructor's signature, and constructors are the one area where the theory says vastly different signatures are completely kosher. 2) There are gazillions of `__init__`s out there already that do this wrong already. 3) Some details of `__init__` have been fiddled with multiple times in recent years. It's often better—though possibly not as useful—to think about how `super` works with methods other than `__init__`, where the situation is more straightforward. – Mike Graham Sep 02 '11 at 22:12
  • Personally, I avoid inheritance the vast majority of the time, which avoids much of this nastiness. The times I do tend to use it—for mixins and for registering some defined set of callbacks—don't really require this sort of thing. – Mike Graham Sep 02 '11 at 22:14
  • I assume you meant "multiple inheritance" above in which case I agree. But if I write a class that may be inherited, I'd prefer if my init function wouldn't make it unusable for that usecase if I can avoid it. Sure in other situations it's simpler, but if I can't use super in my "constructor" (which is where I need this functionality the most often I think), that means I may have to use two different methods to do the same in one class - that's also not great. – Voo Sep 02 '11 at 22:51
  • @Voo, Nope, I mean inheritance. – Mike Graham Sep 02 '11 at 23:20
  • But if you ignore inheritance, why would you ever need to use super() or any other construct solely there to call parent classes? There are enough use cases where inheritance is useful and you still want to call the parent after all (although you can obviously misuse inheritance where another solution would be more appropriate - but then the same is true for basically everything) – Voo Sep 02 '11 at 23:58
  • @Voo, as stated, one of the benefits of avoiding inheritance is avoiding such nonsense. I certainly don't deny that that inheritance can be the best tool for some jobs, but they are fairly few, and the ones where real method-overriding inheritance is the best idea are even fewer. – Mike Graham Sep 03 '11 at 00:45