[Python-Dev] Things to Know About Super

[Michele Simionato]

On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger <python at rcn.com> wrote:
> What I would really like to see is a fourth blog entry that shows
> how to use super() reliably and correctly.

That could be arranged.

> 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.

Yep. The parts about the bugs of super in 2.2 and 2.3 were written years
ago, when they were relevant. Nowadays they are less relevant, but since they
were already written and since there are still people using older versions
of Python I decided to keep them. I would not keep them in a revised version
intended as "semi-official" documentation of super. Still, I think they are
fine as a blog post.

> 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.

> 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.

They just show that the tool is delicate and not easy to use.

> 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.

In my experience, one can go a long way using composition instead of
inheritance.
I also think that Python would not lose much without cooperative
multiple inheritance.
This is however a personal opinion and in any case the point is moot
because the language is the way it is. Still, in a blog post personal
opinions and even rants have their place. That part could be removed in an
"semi-official" document.

> 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.

Fine with me.

> 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).

I not completely against multiple inheritance. I am against multiple inheritance
as it is now. A restricted form of multiple inheritance in which mixins classes
are guaranteed to be orthogonal would be fine with me (provided it is
not abused).
This concept exists already in other languages, the orthogonal mixins
are called "traits".

I have written a trilogy of papers about mixins: if you read them, you will see
where I come from (Zope, which I do not like) and you will also see
that I like DictMixin
instead.
I will publish the papers in the blog soon or later, but you can find
the Italian version here:

http://stacktrace.it/articoli/2008/06/i-pericoli-della-programmazione-con-i-mixin1/
http://stacktrace.it/articoli/2008/07/i-pericoli-della-programmazione-con-i-mixin2/
http://stacktrace.it/articoli/2008/08/i-pericoli-della-programmazione-con-i-mixin3/


 Michele Simionato