By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,732 Members | 1,397 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,732 IT Pros & Developers. It's quick & easy.

super(...).__init__() vs Base.__init__(self)

P: n/a
Are there any best practice guidelines for when to use
super(Class, self).__init__()
vs
Base.__init__(self)
to call a base class __init__()?

The super() method only works correctly in multiple inheritance when the
base classes are written to expect it, so "Always use super()" seems
like bad advice. OTOH sometimes you need super() to get correct
behaviour. ISTM "Only use super() when you know you need it" might be
the best advice. Is there any conventional wisdom on this?

The question arises from a naive use of super() in a post on the tutor
list. This code gives an AttributeError because Base.__init__() is never
called:

import threading

class Base(object):
def __init__(self):
self.x = 1

class Derived(threading.Thread, Base):
def __init__(self):
super(Derived, self).__init__()

d=Derived()
d.x

If the order of base classes is reversed, the reference to d.x works but
of course threading.Thread.__init__() is never called.

1. One way to fix the code is to call Base.__init__() and
threading.Thread.__init__() explicitly in Derived.__init__().

2. Another fix is for Base.__init__() to call super(Base,
self).__init__() and to list Base first in the list of base classes.
This is fragile - it depends on the order of base classes and adding
another base class would break it.

3. A third fix might be to change both Base and threading.Thread() to
call super(...).__init__(). This might break existing code that is
written in the style of fix 1 (calling both base class __init__()
methods explicitly).

I prefer the first fix, it is explicit and fairly robust - it works if
the order of bases is changed, and it's pretty clear from the body of
Derived.__init__() that if you add another base class, you should change
__init__().

Any other opinions? Any consensus about the "best" way to do this?

BTW I understand what super() does, I know why the original code is
broken, I'm not asking for help with that. I'm wondering what others
think best practices are.

Thanks,
Kent
Feb 9 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
I remember there was somewhere a page called "super considered
harmful", some googling
should find it. It was discussing the issue you are alluding to, as
well others. Also google
in the newsgroup, there are lots of threads about super and its
shortcomings.

Michele Simionato

Feb 9 '06 #2

P: n/a
Kent Johnson wrote:
Are there any best practice guidelines for when to use
super(Class, self).__init__()
vs
Base.__init__(self)
to call a base class __init__()?
[snip]
3. A third fix might be to change both Base and threading.Thread() to
call super(...).__init__(). This might break existing code that is
written in the style of fix 1 (calling both base class __init__()
methods explicitly).


Personally, I'd call the lack of the super calls in threading.Thread and
Base bugs. So code relying on that behavior needs to be fixed when the
bug is fixed. But __init__() is definitely a tricky case since the
number of arguments tends to change in the __init__() methods of classes...

STeVe
Feb 9 '06 #3

P: n/a
Steven Bethard <st************@gmail.com> wrote:
Personally, I'd call the lack of the super calls in threading.Thread and
Base bugs.
It can't be a bug since it wasn't a bug before super was introduced and
you don't wan't to break working Python-2.x-code.
But __init__() is definitely a tricky case since the
number of arguments tends to change in the __init__() methods of classes...


ACK. And every __init__ will have to accept *any* arguments you give to
it and call super with *all* the arguments it got. This is tricky and
easily to get wrong. Super is a good tool to use, when dealing with
diamond shape inheritance. In any other case I would use the direct
calls to the base classes. In fact, i've yet to find a non-textbook-case
where I really need diamond shape inheritance. OTOH I don't mean to say
that noone else needs it either.

cu,
--Jan Niklas
Feb 9 '06 #4

P: n/a
Jan Niklas Fingerle wrote:
Steven Bethard <st************@gmail.com> wrote:
Personally, I'd call the lack of the super calls in threading.Thread and
Base bugs.


It can't be a bug since it wasn't a bug before super was introduced and
you don't wan't to break working Python-2.x-code.


Just because there wasn't a bugfix available at the time doesn't mean it
wasn't a bug. ;) The threading.Thread class does not properly call
sibling constructors in multiple inheritance. This should either be
fixed in the implementation (by introducing a call to super) or fixed in
the documentation (by indicating that threading.Thread does not support
multiple inheritance in its __init__() method).
But __init__() is definitely a tricky case since the
number of arguments tends to change in the __init__() methods of classes...


ACK. And every __init__ will have to accept *any* arguments you give to
it and call super with *all* the arguments it got. This is tricky and
easily to get wrong. Super is a good tool to use, when dealing with
diamond shape inheritance. In any other case I would use the direct
calls to the base classes. In fact, i've yet to find a non-textbook-case
where I really need diamond shape inheritance. OTOH I don't mean to say
that noone else needs it either.


I've used diamond inheritance exactly once, and all the classes under
that hierarchy were under my control, so they all used super properly.
And fortunately, the constructors of those classes didn't take any
arguments, so I didn't run into any of the nastier sides of super.

Using super is guaranteed to work as long as the number of arguments of
the method does not change from that of the superclass. For the
__init__() method, this means that super is guaranteed to work as long
as it takes no arguments, since object.__init__() takes no arguments.
Sure, I'd love to see super work right in other cases, but for the OP's
situation at least, super already does what it's supposed to.

STeVe
Feb 10 '06 #5

P: n/a
In article <43*********************@newsread4.arcor-online.net>,
Jan Niklas Fingerle <us*********@lithe.de> wrote:
...Super is a good tool to use, when dealing with
diamond shape inheritance. In any other case I would use the direct
calls to the base classes. In fact, i've yet to find a non-textbook-case
where I really need diamond shape inheritance. ...


As long as you don't use multiple inheritance with new-style classes,
you'll be fine.
__________________________________________________ ______________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>
Feb 10 '06 #6

P: n/a
Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:
In article <43*********************@newsread4.arcor-online.net>,
Jan Niklas Fingerle <us*********@lithe.de> wrote:
...Super is a good tool to use, when dealing with
diamond shape inheritance. In any other case I would use the direct
calls to the base classes. In fact, i've yet to find a non-textbook-case
where I really need diamond shape inheritance. ...


As long as you don't use multiple inheritance with new-style classes,
you'll be fine.


OK, I should have written: "... diamond shape inheritance where the base
class's methods have to be called cooperatively ..."

In other words: In almost every real world example of diamond shape
inheritance where the base class is "only" object we don't have a
problem, because you don't have to call object's __init__, yet it causes
no harm if you call it twice - and __init__ is the *the* method you most
commonly would use "super()" for.

So, yes, "no multiple inheritance" is sufficient, but not nessecary to
live happily without ever using "super()".

Nothing against super where it's appropiate. But don't optimize for
("real") diamond shape inheritance, before you really need it...

Cheers,
--Jan Niklas
Feb 12 '06 #7

P: n/a
Steven Bethard <st************@gmail.com> wrote:
Jan Niklas Fingerle wrote:
Steven Bethard <st************@gmail.com> wrote:
Personally, I'd call the lack of the super calls in threading.Thread and
Base bugs.
It can't be a bug since it wasn't a bug before super was introduced and
you don't wan't to break working Python-2.x-code.


Just because there wasn't a bugfix available at the time doesn't mean it
wasn't a bug. ;)


Yes, but it isn't a bug.
The threading.Thread class does not properly call
sibling constructors in multiple inheritance. > This should either be
fixed in the implementation (by introducing a call to super)
This would break existing code as shown in http://fuhm.org/super-harmful/
(look out for "Subclasses must use super if their superclasses do").
And as much as I agree with GvR that the word "harmful" is inappropriate
(http://mail.python.org/pipermail/pyt...y/050656.html),
I agree with both, that super is a part of your class's interface that
you might use or not. You just have to document it, whether you use
super, or not. Or to quote GvR: "Super is intended for use that are
designed with method cooperation in mind [...]". That's isn't "always".

The best pratices (see any of the two URLs above) obviously show, that
using super comes at some cost. This is OK, if you really have to
support cooperative method calling. But I wouldn't want to pay it "just
in case".
or fixed in
the documentation
This is true, but this or the other way round: You have to document,
that you're using super(), or that you don't do it.
(by indicating that threading.Thread does not support
multiple inheritance in its __init__() method).
It *does* support multiple inheritance, it just doesn't support diamond
shape inheritance (not counting object).
I've used diamond inheritance exactly once, and all the classes under
that hierarchy were under my control, so they all used super properly.


And this is, what super() is meant for. I, for my part, won't use
super() until I really need it, but when the time comes I will
worship an extra hour at my Guido-van-Rossum-shrine. ;-)
Feb 12 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.