On May 3, 4:47 am, Keshav Kini <[email protected]> wrote: > 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.
I think what you are witnessing here is that in Python, construction of objects happens in two steps: First they are instantiated and then they are initialized. Instantiation indeed necessarily happens in reverse MRO. Initialization happens after that and, as you see, happens as an ordinary method lookup. The instantiation of the child has already run after the instantiation of the parent, so the object is in a state knowable to the child but not to the parent. As in the example given: The _repr_ method has been overridden to a form that cannot run yet because the new _repr_ method needs an extra attribute that needs to be set by the child's __init__ This doesn't make the parent into an abstract class. It just means that the child's instantiation has put the object in an inconsistent state (having a new _repr_ without having the requisite attributes) and the child better fix that in its __init__ before attempting to call the parent's __init__. Of course, the child could decide to modify its state even further after the parent has done its __init__, in which case the call would be neither at the start nor at the end. I think you'd unnaturally and unnecessarily restrict yourself if you would require a particular place where parent's __init__s should be called. -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
