[Python-Dev] Things to Know About Super (original) (raw)

Raymond Hettinger python at rcn.com
Tue Aug 26 17:32:23 CEST 2008

[Michele Simionato]

Recently I have opened a blog on Artima and I am publishing a few Python-related essays I had in store. In particular a trilogy of papers about "super". From the foreword:

""" In 2004 I decided to write a comprehensive paper documenting super pitfalls and traps, ...

Thanks for posting these blogs. I think they serve as a nice compilation of docs, original analysis, and various discussions on super().

What I would really like to see is a fourth blog entry that shows how to use super() reliably and correctly. In general, I opposed to creating documentation in the form of "danger, danger this could explode ...." IMO, there is not much point in dwelling on bugs that have already been fixed, nor is there an advantage to showing all the ways the tool can be misused.

In applications without multiple inheritance, it is a straight-forward to use super() as a way to avoid directly naming an immediate parent class. This is useful in and of itself.

For cooperative multiple inheritance, I take issue with the abstracted examples provided (i.e. inconsistent signatures). In a real app that actually needs cooperative multiple inheritance, it becomes self-evident what "cooperative" actually means -- the methods have to be designed to interoperate -- it is intrinsic to the problem at hand.

Your reasoning is akin to saying that cooperative multitasking is intrinsically flawed because one of the tasks could be designed to not cooperate (never yield).

Cooperative multiple inheritance is not about mixing two unrelated parents that just happen to use the same method name but have different semantics and were not designed to cooperate with each other.

The A-B-C-D diagrams and foo/bar methods in the examples are deceptive because they silently drop the precondition of cooperation while attempting to demonstrate a supposed flaw in the tool.

If I understand the problem correctly, in the rare cases where you do need cooperative multiple inheritance, then super() is the only workable solution short of designing some equivalent using composition instead of inheritance.

I do agree with you that the docs can be improved. I'll work on patch that makes clear that super() returns a proxy-object (not an actual parent class) that dispatches explict method calls (not syntax driven) to one of multiple parents designed to interact cooperatively.

Also, it may be controversial, but there may be some merit in de-documenting the "unbound" case. It seems to add more confusion than it's worth.

Lastly, I take issue with one other part of the blogs. While they show a clear dislike for cooperative multiple inheritance, they take a potshot at multiple inheritance in general. I don't follow the logic here. IMO, mixin classes like DictMixin have proven themselves as being very useful. Plenty of frameworks share this approach. Likewise, the new ABCs offer mixin capabilities that are really nice.

I think it is a non-sequiter to reason from "diamond diagrams are complicated" to "mixins should be disallowed". Instead, I think it better to simply recommend that a key to happiness is to keep various mixin classes completely orthogonal to one another (no overlapping method names).

Lest I sound negative, let me thank you again for the blog entries and for compiling the most complete discussion of it in one place.

Raymond

More information about the Python-Dev mailing list