[Python-Dev] Things to Know About Super

[Casey Duncan]

On Aug 29, 2008, at 11:46 AM, Michele Simionato wrote:

> On Fri, Aug 29, 2008 at 6:15 PM, Nick Coghlan <ncoghlan at gmail.com>  
> wrote:
>> The mixin methods in the ABC machinery would be a lot less useful
>> without multiple inheritance (and the collections ABCs would be a  
>> whole
>> lot harder to define and to write).
>>
>> So if you're looking for use cases for multiple inheritance, I'd  
>> suggest
>> starting with the Python 2.6 collections module and seeing how you  
>> would
>> go about rewriting it using only single inheritance. I believe the  
>> new
>> io module is also fairly dependent on multiple inheritance.
>
> I am very well aware of the collection module and the ABC mechanism.
> However, you are missing that mixins can be implemented in a single- 
> inheritance
> world without the complications of the MRO. See my answer to Alex
> Martelli in this same thread.

As interesting as this conversation is at a meta-level, I'm not sure  
how much more can be accomplished here by debating the merits of  
multiple vs. single inheritance. Unfortunately I think this is a case  
where there is not just one good way to do it in all cases, especially  
given the subjective nature of "good" in this context.

This is what I take away from this:

- super() is tricky to use at best, and its documentation is  
inaccurate and incomplete. I think it should also be made more clear  
that super() is really mostly useful for framework developers,  
including users extending frameworks. Unfortunately many frameworks  
require you to extend them in order to write useful applications in my  
experience, so it trickles down to the app developer at times. In  
short, more correct documentation == good.

- The difficulties of super() are really symptomatic of the  
difficulties of multiple inheritance. I think it's clear that multiple  
inheritance is here to stay in Python, and it solves certain classes  
of problems quite well. But, it requires careful consideration, and  
it's easy to get carried away and create a huge mess (ala Zope2, which  
I am all too familiar), and it can hinder code clarity as much as it  
facilitates reuse.

- There are good alternatives to multiple inheritance for many cases,  
but there are cases where multiple inheritance is arguably best.  
Traits are a possible alternative that deserve further study. I think  
that study would be greatly aided by a 3rd-party library implementing  
traits for Python. If traits are to gain any traction or ever be  
considered for inclusion into the language such a library would need  
to exist first and demonstrate its utility.

I know I'm probably just stating the obvious here, but I found it  
therapeutic ;^)

-Casey