Simon King <simon.k...@uni-jena.de> writes: > Hi Keshav, > > On 2012-05-03, Keshav Kini <keshav.k...@gmail.com> wrote: >> Simon King <simon.k...@uni-jena.de> writes: >>> No idea. Clearly, unless there is a good reason, the init method of the >>> base class should be called at some point. But I was not aware of a >>> convention whether the base init should be called first or last or >>> whatever. Does someone have a pointer? >> >> I think the reasoning behind calling the parent class's initializer >> before the child class's initializer is that the parent class doesn't >> know about the child class, so the parent class shouldn't be expected to >> successfully initialize something that has already been modified by the >> child class. On the other hand, the child class does know about its >> parent classes and can be designed to handle the result of whatever >> initialization the parent class has done. > > I figured that the argument for an initialisation that is anti-parallel > to the mro would be like that. Some special initialisation steps would, > for example, expect that self.variable_names() is present, which is only > available *after* calling Ring.__init__.
Well, if you want to bring the MRO into it, I have a more direct reason why initialization should be done in an order opposite to the MRO. In the MRO, you are choosing which methods override the other methods, i.e. the first overloaded method in the MRO becomes the method chosen. However, when doing initialization of objects, it is the *last* initialization which has the final say on how the object is initialized. So it is natural that the order is the opposite of the MRO. > On the other hand: One could argue that the parent class can > expect that some basic tools (such as __hash__ and __repr__) already > work when being called. Hence, before calling __init__ of the parent > class, one is supposed to make sure that the "tool chain" is provided. If such conditions exist (necessitating the calling of the parent initializer at the end of the child initializer rather than at the beginning) then the parent types are pretty clearly "abstract base classes", in OOP terminology -- i.e. classes which cannot directly be instantiated, because if they were, their __init__() would fail, being called before anything else. Since we don't want to force all classes that might ever be subclassed to become abstract base classes, this doesn't make a good argument for a uniform choice of which order to initialize things in, and we should try to avoid causing initializers of any class to require something to be done before they are called. > And one could argue that a commutative algebra is, in the *first* place, > a commutative algebra, then in the *second* place it is an algebra, > which is a module and a commutative ring (which then is a ring), which > are parents. From that point of view, one would expect that the > initialisation goes from the most specific to the most general - hence, > *parallel* to the mro. As for what characteristics of the object are "more important", I don't think that is really relevant here... Anyway, I am totally ignorant of how all the hierarchical frameworks in Sage work (such as the category / coercion frameworks). I was just theorizing based on what I've seen in other code, and my own thoughts. Passing initialization to the parent at the end rather than the beginning might be the correct way to do it in Sage, I have no idea :) I don't recall seeing any instructions on the matter in the Sage docs, nor have I heard any kind of standards for Python in this matter -- though some stackoverflow questions I found on Google seem to suggest that sometimes people just don't call the parent initializer at all, or they duplicate code from it, or something. But I'm no expert. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
