== Thinking about Python's inheritance model

I recently read [[an entry http://nenoblog.net/?p=10]] by someone who
was surprised that Python subclasses did not automatically call their
parent class's 'constructor' method, by which he meant ((__init__)).
This is a straightforward consequence of Python's inheritance model,
but Python's inheritance model is slightly odd.

The straightforward way to explain Python's inheritance model is that
it uses what I could call 'lookup based' or 'name based' subclassing,
where what subclassing does is change what [[binding WhatVariablesMean]]
will be returned when you look up a given name on an instance of the
(sub)class. And that's pretty much it as for what subclassing does.

(Technically subclassing has some additional effects when you use
((__slots__)), but that's another discussion.)

The next thing to know is that all of Python's special operations,
including ((__init__)), work by normal method calls; they look up the
binding for the name of the special method and then call what they get
back (if anything). So in this model it makes perfect sense that there
is no upcall to the parent class's ((__init__)) method; your subclass
overrode the binding of the name, so your method function gets called
instead of the parent's. Doing an upcall would make ((__init__)) a magic
special operation, unlike all of the others.

(Note that multiple inheritance does not preclude magic upcalls, since
there is a defined [[method resolution order MethodResolutionOrder]]
that the upcalling could follow.)

One consequence of this simple model of subclassing is that you can
fake subclassed instances by using [[other methods MutatingProxies]]
and outside people generally won't notice anything. (They can tell
if they use _isinstance()_ or the like, but most code shouldn't.)