Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!newsfeed.eweka.nl!eweka.nl!feeder3.eweka.nl!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5067cc81$0$29981$c3e8da3$5496439d@news.astraweb.com>
References: <d8fc9d99-8dc0-4290-88a0-33cd38d09f7d@googlegroups.com> <50672d20$0$29981$c3e8da3$5496439d@news.astraweb.com> <mailman.1650.1348943511.27098.python-list@python.org> <5067cc81$0$29981$c3e8da3$5496439d@news.astraweb.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Sun, 30 Sep 2012 01:13:16 -0600
Subject: Re: Should one always add super().__init__() to the __init__?
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1665.1348989229.27098.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:30545

On Sat, Sep 29, 2012 at 10:37 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> [1] You *should* call super, unless you have an excellent reason not to,
> so that your class doesn't break multiple-inheritance. But you need to do
> so with care making sure that the argument signatures are designed for
> cooperative use of super.

I disagree.  Most classes will not ever be used for multiple
inheritance, and the changes involved in "making sure that the
argument signatures are designed for cooperative use of super" are not
trivial.  For one, it means not being able to use positional arguments
in __init__ methods.  For two, the
receive-and-strip-off-keyword-arguments approach falls apart if you
have unrelated classes that take the same arguments.  For
illustration, suppose you have the following two classes, both of
which use a required Frobnik object to perform their functions.


class A:
    def __init__(self, frobnik, **kwargs):
        super().__init__(**kwargs)
        self._frobnik = frobnik
    ...

class B:
    def __init__(self, frobnik, **kwargs):
        super().__init__(**kwargs)
        self._frobnik = frobnik
    ...

Even though these classes have been designed to be cooperative, they
cannot be inherited together.  Whichever class is first in the MRO
will receive the frobnik argument and strip it off, and then the other
class's __init__ method will complain of a missing required argument.

There are solutions to this.  For instance, you could make frobnik
optional in each class, each one relying on the other to receive the
frobnik argument if it is missing, but this complicates the
implementations and makes it difficult to detect in a timely manner if
the frobnik argument has actually not been supplied.  Or you could
change the name of the argument in one of the classes, but then your
library users will complain of inconsistent naming.

What it boils down to is that classes that are expected to be used for
multiple inheritance should be designed to use super cooperatively,
but the majority of classes that you write should not have to deal
with these sorts of restrictions.  Classes that will only ever be
singly inherited should be written normally and using whatever
superclass call style feels most appropriate.