Backward chaining for __init__?

[Remco Gerlich]

Courageous wrote in comp.lang.python:
> > class Derived(Parent):
> >   def __init__(self):
> >     Parent.__init__(self)
> >     # do whatever else
> 
> Thank you. Somehow in the various pieces of documentation
> I have, it wasn't at all obvious to me that you could treat
> the type as an object. This makes sense now in retrospect.

It's not a type but a class, and not only can you treat it like an object,
in fact it *is* an object like any other :-).

> I'm curious, however, as to the philosophical justification
> for leaving backward-chaining ctors out of Python? While
> it's just synactic sugar, some kinds of sugar really taste
> good.

For one thing, __init__ isn't really a constructor but an initializer. The
object is first constructed, then a function called __init__ is called. It's
just a normal method, otherwise. So if the interpreter were to call the
parents' versions of this method too (with which arguments?!), it would have
to do the same thing for any other method call.

So if

class A:
   def m(): print "A"
class B:
   def m(): print "B"
class C(A,B):
   def m(): print "C"
   
C().m()

Would you want that to print "C", "A", and "B"?

> What would be really nice is some use controlled way of
> making backward chaining methods in general, as opposed
> the the limited __init__ case.

Everywhere you want to call a method in the parent (like the one you're
overloading), you just call Parent.method(self, args). What would you
suggest that is better? (and still consistent with the rest of Python).

Main philosophical reasons: __init__ is just a method like any other.
Explicit is better than implicit.

-- 
Remco Gerlich,  scarblac at pino.selwerd.nl

   This is no way to be
     Man ought to be free      -- Ted Bundy
       That man should be me