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

Discussion in 'Python' started by Kent Johnson, Feb 9, 2006.

  1. Kent Johnson

    Kent Johnson Guest

    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
     
    Kent Johnson, Feb 9, 2006
    #1
    1. Advertising

  2. 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
     
    Michele Simionato, Feb 9, 2006
    #2
    1. Advertising

  3. 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
     
    Steven Bethard, Feb 9, 2006
    #3
  4. Steven Bethard <> 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
     
    Jan Niklas Fingerle, Feb 9, 2006
    #4
  5. Jan Niklas Fingerle wrote:
    > Steven Bethard <> 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
     
    Steven Bethard, Feb 10, 2006
    #5
  6. Kent Johnson

    Tony Nelson Guest

    In article <43eba7f7$0$507$-online.net>,
    Jan Niklas Fingerle <> 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/>
     
    Tony Nelson, Feb 10, 2006
    #6
  7. Tony Nelson <*firstname*nlsnews@georgea*lastname*.com> wrote:
    > In article <43eba7f7$0$507$-online.net>,
    > Jan Niklas Fingerle <> 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
     
    Jan Niklas Fingerle, Feb 12, 2006
    #7
  8. Steven Bethard <> wrote:
    > Jan Niklas Fingerle wrote:
    > > Steven Bethard <> 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/python-dev/2005-January/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. ;-)
     
    Jan Niklas Fingerle, Feb 12, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest

    super.super.super how?

    Guest, Feb 19, 2005, in forum: Java
    Replies:
    24
    Views:
    10,825
    Darryl Pierce
    Feb 24, 2005
  2. Ralf W. Grosse-Kunstleve
    Replies:
    16
    Views:
    601
    Lonnie Princehouse
    Jul 11, 2005
  3. Ralf W. Grosse-Kunstleve
    Replies:
    18
    Views:
    606
    Bengt Richter
    Jul 11, 2005
  4. Adam Monsen
    Replies:
    1
    Views:
    345
    Tom Anderson
    Sep 19, 2005
  5. Ramchandra Apte
    Replies:
    17
    Views:
    351
    Manuel Pégourié-Gonnard
    Sep 30, 2012
Loading...

Share This Page