[Python-Dev] py3k: TypeError: object.__init__() takes no parameters

[Terry Reedy]

Alexandre Passos wrote:
> On Fri, Jan 16, 2009 at 2:12 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> I do not understand.  You know it is going to run the .__init__ of its one
>> and only base class, which here is object.
> 
> Because this class might be used as base of another class. Take this
> trivial example code (in py2.6):
> 
> class A(object):
>     def __init__(self, a):
>         #super(A, self).__init__(a)
>         self.a = a
>         print "A"
> 
> class B(object):
>     def __init__(self, a):
>         #super(B, self).__init__(a)
>         self.b = a
>         print "B"
> 
> class C(A, B):
>     def __init__(self, a):
>         super(C, self).__init__(a)
>         self.c = a
>         print "C", dir(self)
> 
> C(1)
> 
> Running the last line shows that A's constructor got called, but not
> B's constructor.

Same in 3.0 with print ()s

> The only way to make sure all __init__s are called in
> this example is by doing
> 
> class A(object):
>     def __init__(self, a):
>         super(A, self).__init__(a)
>         self.a = a
>         print "A"
> 
> class B(object):
>     def __init__(self, a):
>         #super(B, self).__init__(a)
>         self.b = a
>         print "B"
> 
> class C(A, B):
>     def __init__(self, a):
>         super(C, self).__init__(a)
>         self.c = a
>         print "C", dir(self)
> 
> C(1)
> 
> which is really ugly (as in, why is B's call to super.__init__
> commented but not A's, if A and B are otherwise identical?)

Especially since the commenting would have to be reversed should the 
definition of C change to reverse the inheritance order. Should one
write "class D(B,A) .." or "class D(B,C..)", nothing would work.

> I'm not sure, but I think the proper behavior for object.__init__
> should be ignoring all args.

Given
  "The second use case is to support cooperative multiple inheritence in 
a dynamic execution environment. ... Good design dictates that this 
method have the same calling signature in every case (because the order 
of parent calls is determined at runtime and because that order adapts 
to changes in the class hierarchy)."
the change makes object unsuitable as a multiple inheritance base.

I think as a practical matter it is anyway since practical cases have 
other methods that object does not have that need exist in the pyramid 
base.  This must be why there have not been squawks about the change in 2.6.

So I wonder whether the proper change might have been to remove 
object.__init__.

Terry Jan Reedy