[Python-Dev] Things to Know About Super
casey at pandora.com
Fri Aug 29 20:33:35 CEST 2008
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>
>> The mixin methods in the ABC machinery would be a lot less useful
>> without multiple inheritance (and the collections ABCs would be a
>> lot harder to define and to write).
>> So if you're looking for use cases for multiple inheritance, I'd
>> starting with the Python 2.6 collections module and seeing how you
>> go about rewriting it using only single inheritance. I believe the
>> 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-
> 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
- 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
More information about the Python-Dev