[docs] [issue37176] super() docs don't say what super() does

Steven D'Aprano report at bugs.python.org
Fri Jun 7 05:50:09 EDT 2019


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Jun 07, 2019 at 08:00:34AM +0000, Jeroen Demeyer wrote:
> 
> Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:
> 
> > What more do you want?
> 
> Mainly: it says "a parent or sibling class of *type*" but it doesn't 
> explain which class it actually uses.

Only one of the two arguments is called "type". The other is called 
"object-or-type".

> And the sentence "The __mro__ attribute of the type lists the method 
> resolution search order used by both getattr() and super()" is even 
> wrong or at least confusing: what matters is not the MRO of the type 
> (the first argument to super()) but the MRO of the object (the second 
> argument to super()).

The sentence doesn't talk about the MRO of *type* (the first argument), 
it talks about the __mro__ attribute. It is correct. The __mro__ 
attribute is on the type, not the instance:

py> int.__mro__
(<class 'int'>, <class 'object'>)

py> int().__mro__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute '__mro__'

super() look-ups never start at the instance, they delegate to the 
superclass (or superclasses), not back to the current class, or the 
instance itself.

> The zero-argument form super() is not explained at all.

Yes it is. Look at the example given:

    super().method(arg)    # This does the same thing as:
                           # super(C, self).method(arg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37176>
_______________________________________


More information about the docs mailing list