Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
On Fri, Jun 07, 2019 at 08:00:34AM +0000, Jeroen Demeyer wrote:
>
> Jeroen Demeyer <j.deme...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue37176>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
