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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4