Comments on: Python’s super() considered super!

By: iguananaut

iguananaut — Fri, 11 Jan 2013 16:56:49 +0000

Re: “Explicit is better than implicit”–Although the semantics of calling super() in Python 3 are not explicit about the superclass an instance object it’s still at least well-defined and consistent. Likewise for the MRO. So as long as you understand the rules (which are not really all that complex at the end of the day) it’s at least predictable.

By: Python’s super() | blog.notmet.net

Python’s super() | blog.notmet.net — Fri, 05 Oct 2012 14:17:50 +0000

[...] when you’re using Python for object oriented code and have some inheritance going on. This blog post describes the best way I’ve seen it used so [...]

By: rhettinger

rhettinger — Thu, 06 Sep 2012 06:26:14 +0000

Yes, you’re correct. The Counter.__init__ method will be the first __init__ encountered in the MRO. The code in Counter.__init__ calls super which finds OrderedDict.__init__ as the next in the MRO.

By: nielshenrikbruun

nielshenrikbruun — Sun, 02 Sep 2012 04:50:09 +0000

Hi
I\’ve started using classes and subclasses etc for some time now.
And in lack of documentation I\’d do some trail and error when starting.

In my code I usually reuse methods in a class to define new methods, ie I define some base methods that might be used to create more complicated functionality in new methods.

In doing so I\’ve found that using self much like super() is used (I wasn\’t aware of super()) did the job for me.

class Example:
def basemethod1(self):
pass
def basemethod2(self):
pass
def advancedmethod1(self):
refers to self.basemethod1() and/or self.basemethod1()

And it also works when subclassing.

The question is whether the above is proper code or not?
Or if I should use super instead?
what are the pros and cons in self vs super()?

Looking forward to your answer

By: Ramesh Sahu

Ramesh Sahu — Wed, 08 Aug 2012 11:08:40 +0000

Thank you very much for taking the time to write this post. It is very informative..

By: lvc

lvc — Sun, 20 May 2012 02:34:26 +0000

There’s no way around having to know the signature of a parent class’ constructor in order to call the parent class’ constructor (aside from the technique mentioned in the post of accepting arbitrary kwargs, taking out the ones you can deal with, and passing the rest along). This problem isn’t unique to Python – Java and C++ convention have you always declare a constructor that can be called with no arguments.

By: Karl Knechtel

Karl Knechtel — Sat, 31 Mar 2012 00:57:50 +0000

Regarding the (Counter, OrderedDict) example: when the OrderedCounter is initialized or updated, the Counter __init__ (or update) is run because that’s the next class in the MRO, right? So how does the OrderedDict behaviour get triggered? Is Counter making a super() call somewhere that gets routed through OrderedDict (instead of passing directly to the builtin dict type as it normally would)? Or just what?

By: Snooze

Snooze — Sun, 11 Mar 2012 22:47:41 +0000

Thank you for the great post.

I get how python handles multiple class inheritance now, but I still don’t quite understand what you meant by this paragraph:

“Root.draw can also employ defensive programming using an assertion to ensure it isn’t masking some other draw() method later in the chain. This could happen if a subclass erroneously incorporates a class that has a draw() method but doesn’t inherit from Root.”

I can understand how the assertion would fail if Root inherited from another class, but we know that Root doesn’t because we wrote it ourselves.

I don’t quite understand how the assertion in Root will be called if the subclass in question doesn’t inherit from Root. Maybe you can show how such an inheritance tree would be structured?

By: Pedle Zelnip

Pedle Zelnip — Tue, 06 Mar 2012 17:12:37 +0000

My apologies, I missed the How to Incorporate a Non-cooperative Class section on my 1st read somehow.

“Oh, I wish that unrelated third-party classes composed together effortlessly and magically happened to do exactly the behavior I want without me every bothering to specify (or think about) what that behavior should be or how it would work.”

That’s a strawman right there. All I’m saying is that there should be a consistent, safe mechanism for calling parent class constructor’s. super() isn’t it, as it requires knowledge of how a class was defined in order to know how to call it’s constructor.

By: rhettinger

rhettinger — Mon, 05 Mar 2012 23:27:00 +0000

The article shows how to create a wrapper for third-party classes that were not designed for cooperative multiple inheritance.

Calling it a “fundamentally broken solution” is a red-herring. The solution is based on a good deal of academic research (plus real-world experience with the Dylan programming language). The underlying problem is non-trivial — care and forethought are required for freely composeable classes using multiple inheritance while allowing for diamond patterns.

There is a reason that the style is called cooperative multiple inheritance. The classes either need to be designed cooperatively or they need to be wrapped to make them cooperative. Anything else equates to wishful thinking — “Oh, I wish that unrelated third-party classes composed together effortlessly and magically happened to do exactly the behavior I want without me every bothering to specify (or think about) what that behavior should be or how it would work.”