Alexandre Passos wrote:
On Fri, Jan 16, 2009 at 2:12 PM, Terry Reedy <tjre...@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


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to