Prev: ValueError: invalid literal for int():
Next: What does the output of return os.lstat(logFile)[ST_CTIME] mean?
From: Ethan Furman on 26 Jul 2010 12:20
Gregory Ewing 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.

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?

~Ethan~

From: Jean-Michel Pichavant on 29 Jul 2010 13:29
Steven D'Aprano wrote:
> [snip]
>
> super() is just as explicit as len(), or str.upper(). It says,
> explicitly, that it will call the method belonging to one or more
> superclass of the given class.
>
Come on Steven, you're better than this :) .
Everybody can accurately guess what len and upper are doing without
looking at the documentation. No one can guess for super without closely
looking at the documention, or even at some good articles on the net
which try to clear things up about super. And note there is no such
article about len or upper.

As someone already said in this list, the main problem with super is
that it tends to refer to the superclass method while in fact it calls
the next MRO method.

"mro" would have been the proper name for "super".

JM

From: Jean-Michel Pichavant on 30 Jul 2010 05:09
Steven D'Aprano wrote:
> On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
>
>
> [snip]
>> As someone already said in this list, the main problem with super is
>> that it tends to refer to the superclass method while in fact it calls
>> the next MRO method.
>>
>
> Why do you think that is a problem? That's what it is supposed to do,
> because that's what is needed to correctly implement multiple inheritance.
>
>
>
>> "mro" would have been the proper name for "super".
>>
>
> That's your opinion. In any case, whether super() was called super() or
> mro() or aardvark() makes no difference to the functionality or whether
> it is useful.
>
>
>
>
I have no problem with dogs nor cats, however I have problem with cats
called dogs and dogs called cats as I'm dealing with industrial
programming, not litterature nor poetry.

JM
From: Jean-Michel Pichavant on 30 Jul 2010 08:43
Steven D'Aprano wrote:
> On Fri, 30 Jul 2010 19:37:29 +1200, Gregory Ewing wrote:
>
>
>> Steven D'Aprano wrote:
>>
>>> On Thu, 29 Jul 2010 19:29:24 +0200, Jean-Michel Pichavant wrote:
>>>
>> >
>>
>>>> "mro" would have been the proper name for "super".
>>>>
>>> That's your opinion. In any case, whether super() was called super() or
>>> mro() or aardvark() makes no difference to the functionality or whether
>>> it is useful.
>>>
>> I think the point is that the name is misleading, because it makes it
>> *sound* like it's going to call a method in a superclass, when it fact
>> it might not.
>>
>
> I'm not sure I understand your point here. If you call super() from a
> method that doesn't exist in any superclass, then you are correct, it
> won't call a method in a superclass, and will raise AttributeError.
>
> But in the more sensible case that you only call super() when there is
> actually something to inherit, then of course it calls the method in a
> superclass. It certainly doesn't call methods from arbitrary unrelated
> classes, only those which are in the MRO. That is, superclasses.
>
> If Z is below A in the hierarchy, then we have no difficulty in
> identifying Z as a subclass of A, and likewise we should have no problem
> with identifying A as *a* (and not "the") superclass of Z, no matter how
> distant they are or how tangled the DIG between them.
>
> The exception would be if you could have loops in the class hierarchy, in
> which case the concepts of super- and sub-classes breaks down completely.
> But even if some other languages allowed that, Python doesn't, so we're
> safe.
>
>
>
>
Quoting Michele's article (I think he's still hanging around this list)

"Readers familiar will single inheritance languages, such as Java or
Smalltalk, will have a clear concept of superclass in mind. This
concept, however, has /no useful meaning/ in Python or in other multiple
inheritance languages".


the complete article on super:
http://www.artima.com/weblogs/viewpost.jsp?thread=236275

super is a strange name for something that makes no sense in python
(talking about superclass here). It doesn't take away the usefulness of
super, but it's a proof that you can ruin a good feature with a bad name.

JM
From: Ian Kelly on 30 Jul 2010 23:40
On Fri, Jul 30, 2010 at 6:38 AM, Hrvoje Niksic <hniksic(a)xemacs.org> wrote:
> Gregory Ewing <greg.ewing(a)canterbury.ac.nz> writes:
>
>> I think the point is that the name is misleading, because it makes it
>> *sound* like it's going to call a method in a superclass, when it fact
>> it might not.
>
> That is indeed confusing to some people, especially those who refuse to
> to accept the notion that "superclass" means the same as "next in MRO",
> maintaining instead that superclass refers to one of the base classes,
> their bases, etc. -- IMO a defensible position.
>
> super might have better been called next_in_mro, next_method, or
> next_class, except those are harder to type, and way less catchy than
> "super".  The Dylan and CLOS operator that super is most closely based
> on is called (call-)next-method.

I have to chime in and agree that the name "super" is problematic.
I'm reading this thread with a sense of alarm because I apparently
never read the super() documentation too closely (why would I? "Oh,
it just accesses an attribute from a superclass. Moving on.") and
have been writing code for the past four years under the impression
that super() will always refer to a superclass of the current class.
Fortunately, I don't use multiple inheritance often, and when I do I
prefer to write the superclasses explicitly (perhaps because of the
same misconception), so I probably haven't really abused it terribly.

On a tangent, is it just me, or is the super() documentation
incorrect, or at least unclear? Quoting from the first two
paragraphs:

super(type[, object-or-type])

Return a proxy object that delegates method calls to a parent or
sibling class of type. This is useful for accessing inherited methods
that have been overridden in a class. The search order is same as that
used by getattr() except that the type itself is skipped.

The __mro__ attribute of the type lists the method resolution
search order used by both getattr() and super(). The attribute is
dynamic and can change whenever the inheritance hierarchy is updated.

In the first paragraph, "type" refers to "type", the first parameter
in the function signature. In the second paragraph, "type" refers to
the type instance or the type of the object passed as the second
argument. If it also referred to the first parameter, then super()
would always access a superclass as I initially thought; I wonder if
this might have been partially responsible for my confusion.

Cheers,
Ian
 |  Next  |  Last
Pages: 1 2 3
Prev: ValueError: invalid literal for int():
Next: What does the output of return os.lstat(logFile)[ST_CTIME] mean?