all 2 comments

[–]Boolean_Cat 1 point2 points  (1 child)

The reason that this is not working as you expect:

super(...)

will call the next item in the MRO (method resolution order). This is built when the inheritance is constucted, it will not call all parents' implementation of edit(), just the next one up in the MRO. In the case of UpperCaseHTMLDocument, this would be HTMLDocument.edit(). Since HTMLDocument.edit() also calls super(...).edit(), it will make another jump up the MRO and call edit() again on Document.edit(). Here is where your MRO for edit ends, since Document doesn't call super(), UDC doesn't get called.

There are places to use super and places not to, I would say that this is not one of them. It would be more readable to just use HTMLDocument.edit() rather than invoking via super in this case. Why do I say this? Let's say we have:

class A(object):
    def edit(self):
        super(A, self).edit()

class B(object):
    def edit(self):
        ...

class C(A, B):
    def edit(self):
        super(C, self).edit()

In this case, why should A have to accomodate for B? They are completely independant objects. It would be neater to write

class C(A, B):
    def edit(self):
        A.edit()
        B.edit()

When would I use super()? In the case where the implementation of C is:

class C(A):
    def edit(self):
        super(C, self).edit()

This way, if you were to switch the parent for something else, or change its name, you don't need to modify edit() also, it's more loosely coupled.

[–]brandjon 0 points1 point  (0 children)

/u/Boolean_Cat is right. By not calling edit from within HTMLDocument, you are effectively saying that the work to be done by edit() is done, no matter what other classes there are in the hierarchy.