Prev: 'as' keyword - when/how to use it
Next: Are those features still the same?
From: Raymond Hettinger on 26 Jul 2010 20:46
[Ethan Furman]
> Speaking of new-style classes only, don't they all end in object?  And
> if the MRO is only known at run-time, how is one to know at code-time
> whether your (new-style) class is at the end of the line?

That is a bit of a PITA. One way of handling it is to design your
diamond so that only one class inherits from object and that class
doesn't use super(). Or you can wrap the super call in a try/except
AttributeError.

Cooperative multiple inheritance isn't pretty -- which is just another
good reason to use composition rather that inheritance.


Raymond

From: Raymond Hettinger on 30 Jul 2010 12:34
On Jul 25, 5:30 pm, Gregory Ewing <greg.ew...(a)canterbury.ac.nz> wrote:
> Raymond Hettinger wrote:
> > Every class
> > in the MRO implementing the target method *must* call super() to give
> > the next class in the MRO a chance to run.
>
> EXCEPT for the last one, which must NOT call super!
>
> The posted example happens to work because object has
> a default __init__ method that does nothing. But this
> is not generally true of other methods, which means you
> need a "terminating" class at the end of the MRO whose
> methods don't call super.

That is an important point and it is what Guido does in his examples:
http://www.python.org/download/releases/2.2.3/descrintro/#cooperation

The design options are:

* if overriding a method provided by object() such as __init__(),
__getattribute__() or __setattr__(), then you should call super() in
each class that overrides or extends those methods.

* if you know the whole class structure in advance, you call super()
in every class except the last one -- that is what Guido does in the
save() example.

* if you don't know the whole class structure in advance, then you
can't be sure which is that last class in the mro with the target
method, so you need to wrap the super() call in a try / except
AttributeError

Raymond


From: Carl Banks on 31 Jul 2010 23:54
On Jul 31, 8:48 pm, Carl Banks <pavlovevide...(a)gmail.com> wrote:
> When you have a class you that don't anything about the implementation
> of, that is NOT the place for inheritance.

And, just to be clear, if the class is explicity documented as being
subclassable and the documentation states the proper procedure for
doing so, that counts as "knowing about the implementation"--even if
you don't know the exact implementation, you do have sufficient
knowledge.

I just don't want someone following up saying, "Well I think it's ok
to inherit from a class you know nothing about if it's documented
properly." I agree, and that is knowing something about it.


Carl Banks
From: Michele Simionato on 2 Aug 2010 02:15
On Jul 31, 5:08 am, Steven D'Aprano <st...(a)REMOVE-THIS-
cybersource.com.au> wrote:
> I have read Michelle Simionato's articles on super in Python.

One "l" please! I am a man! ;-)

>
> But Michelle is wrong to conclude that the problem lies with the concept
> of *superclass*. The problem lies with the idea that there is ONE
> superclass. By dismissing the entire concept, he is throwing out the baby
> with the bathwater.

I am actually more radical than that. From
http://www.artima.com/weblogs/viewpost.jsp?thread=237121:

"""
In this series I have argued that super is tricky; I think nobody can
dispute that. However the existence of dark corners is not a
compelling argument against a language construct: after all, they are
rare and there is an easy solution to their obscurity, i.e.
documenting them. This is what I have being doing all along. On the
other hand, one may wonder if all super warts aren't hints of some
serious problem underlying. It may well be that the problem is not
with super, nor with cooperative methods: the problem may be with
multiple inheritance itself.
"""

Then I spend thousands of words in the "Mixin considered harmful"
series and in other articles arguing against
multiple inheritance and cooperative methods. They are just bad design
IMO. Of course we are in the range of opinions, this is a tricky
subject: many smart people agree with me and many others equally smart
disagree.
Still I believe that super is a red herring and that you should really
start thinking: what advantages did
multiple inheritance *really* bring into my code? Could have I done
without? And what would have happen?
These are the relevant question, not the exact meaning of super in
hairy hierarchies.

M. Simionato
First  |  Prev  | 
Pages: 1 2
Prev: 'as' keyword - when/how to use it
Next: Are those features still the same?