Why did the Python designers decide that subclasses’ __init__() methods don’t automatically call the __init__() methods of their superclasses, as in some other languages? Is the Pythonic and recommended idiom really like the following?

class Superclass(object):
    def __init__(self):
        print 'Do something'

class Subclass(Superclass):
    def __init__(self):
        super(Subclass, self).__init__()
        print 'Do something else'

The crucial distinction between Python’s __init__ and those other languages constructors is that __init__ is not a constructor: it’s an initializer (the actual constructor (if any, but, see later;-) is __new__ and works completely differently again). While constructing all superclasses (and, no doubt, doing so “before” you continue constructing downwards) is obviously part of saying you’re constructing a subclass’s instance, that is clearly not the case for initializing, since there are many use cases in which superclasses’ initialization needs to be skipped, altered, controlled — happening, if at all, “in the middle” of the subclass initialization, and so forth.

Basically, super-class delegation of the initializer is not automatic in Python for exactly the same reasons such delegation is also not automatic for any other methods — and note that those “other languages” don’t do automatic super-class delegation for any other method either… just for the constructor (and if applicable, destructor), which, as I mentioned, is not what Python’s __init__ is. (Behavior of __new__ is also quite peculiar, though really not directly related to your question, since __new__ is such a peculiar constructor that it doesn’t actually necessarily need to construct anything — could perfectly well return an existing instance, or even a non-instance… clearly Python offers you a lot more control of the mechanics than the “other languages” you have in mind, which also includes having no automatic delegation in __new__ itself!-).

I’m somewhat embarrassed when people parrot the “Zen of Python”, as if it’s a justification for anything. It’s a design philosophy; particular design decisions can always be explained in more specific terms–and they must be, or else the “Zen of Python” becomes an excuse for doing anything.

The reason is simple: you don’t necessarily construct a derived class in a way similar at all to how you construct the base class. You may have more parameters, fewer, they may be in a different order or not related at all.

class myFile(object):
    def __init__(self, filename, mode):
        self.f = open(filename, mode)
class readFile(myFile):
    def __init__(self, filename):
        super(readFile, self).__init__(filename, "r")
class tempFile(myFile):
    def __init__(self, mode):
        super(tempFile, self).__init__("/tmp/file", mode)
class wordsFile(myFile):
    def __init__(self, language):
        super(wordsFile, self).__init__("/usr/share/dict/%s" % language, "r")

This applies to all derived methods, not just __init__.

Java and C++ require that a base class constructor is called because of memory layout.

If you have a class BaseClass with a member field1, and you create a new class SubClass that adds a member field2, then an instance of SubClass contains space for field1 and field2. You need a constructor of BaseClass to fill in field1, unless you require all inheriting classes to repeat BaseClass‘s initialization in their own constructors. And if field1 is private, then inheriting classes can’t initialise field1.

Python is not Java or C++. All instances of all user-defined classes have the same ‘shape’. They’re basically just dictionaries in which attributes can be inserted. Before any initialisation has been done, all instances of all user-defined classes are almost exactly the same; they’re just places to store attributes that aren’t storing any yet.

So it makes perfect sense for a Python subclass not to call its base class constructor. It could just add the attributes itself if it wanted to. There’s no space reserved for a given number of fields for each class in the hierarchy, and there’s no difference between an attribute added by code from a BaseClass method and an attribute added by code from a SubClass method.

If, as is common, SubClass actually does want to have all of BaseClass‘s invariants set up before it goes on to do its own customisation, then yes you can just call BaseClass.__init__() (or use super, but that’s complicated and has its own problems sometimes). But you don’t have to. And you can do it before, or after, or with different arguments. Hell, if you wanted you could call the BaseClass.__init__ from another method entirely than __init__; maybe you have some bizarre lazy initialization thing going.

Python achieves this flexibility by keeping things simple. You initialise objects by writing an __init__ method that sets attributes on self. That’s it. It behaves exactly like a method, because it is exactly a method. There are no other strange and unintuitive rules about things having to be done first, or things that will automatically happen if you don’t do other things. The only purpose it needs to serve is to be a hook to execute during object initialisation to set initial attribute values, and it does just that. If you want it to do something else, you explicitly write that in your code.

“Explicit is better than implicit.” It’s the same reasoning that indicates we should explicitly write ‘self’.

I think in in the end it is a benefit– can you recite all of the rules Java has regarding calling superclasses’ constructors?

Often the subclass has extra parameters which can’t be passed to the superclass.

Right now, we have a rather long page describing the method resolution order in case of multiple inheritance: http://www.python.org/download/releases/2.3/mro/

If constructors were called automatically, you’d need another page of at least the same length explaining the order of that happening. That would be hell…

To avoid confusion it is useful to know that you can invoke the base_class __init__() method if the child_class does not have an __init__() class.

Example:

class parent:
  def __init__(self, a=1, b=0):
    self.a = a
    self.b = b

class child(parent):
  def me(self):
    pass

p = child(5, 4)
q = child(7)
z= child()

print p.a # prints 5
print q.b # prints 0
print z.a # prints 1

In fact the MRO in python will look for __init__() in the parent class when can not find it in the children class. You need to invoke the parent class constructor directly if you have already an __init__() method in the children class.

For example the following code will return an error: class parent: def init(self, a=1, b=0): self.a = a self.b = b

    class child(parent):
      def __init__(self):
        pass
      def me(self):
        pass

    p = child(5, 4) # Error: constructor gets one argument 3 is provided.
    q = child(7)  # Error: constructor gets one argument 2 is provided.

    z= child()
    print z.a # Error: No attribute named as a can be found.

Maybe __init__ is the method that the subclass needs to override. Sometimes subclasses need the parent’s function to run before they add class-specific code, and other times they need to set up instance variables before calling the parent’s function. Since there’s no way Python could possibly know when it would be most appropriate to call those functions, it shouldn’t guess.

If those don’t sway you, consider that __init__ is Just Another Function. If the function in question were dostuff instead, would you still want Python to automatically call the corresponding function in the parent class?

i believe the one very important consideration here is that with an automatic call to super.__init__(), you proscribe, by design, when that initialization method is called, and with what arguments. eschewing automatically calling it, and requiring the programmer to explicitly do that call, entails a lot of flexibility.

after all, just because class B is derived from class A does not mean A.__init__() can or should be called with the same arguments as B.__init__(). making the call explicit means a programmer can have e.g. define B.__init__() with completely different parameters, do some computation with that data, call A.__init__() with arguments as appropriate for that method, and then do some postprocessing. this kind of flexibility would be awkward to attain if A.__init__() would be called from B.__init__() implicitly, either before B.__init__() executes or right after it.