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

Change by Raymond Hettinger : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___

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

Raymond Hettinger added the comment: I've add PR 15564 to clarify some known ambiguities for the super() docs including a specific example "what it actually does". -- ___ Python tracker

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

Carlos André Dantas de Lima added the comment: The method says who you will use some recursion. -- nosy: +Carlos André Dantas de Lima ___ Python tracker ___

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

Steven D'Aprano added the comment: On Sat, Jun 08, 2019 at 09:14:18PM +, Raymond Hettinger wrote: > Ideally, the text can also be made more compact. Having eight > paragraphs sends an implicit message that this is too complex to > understand and that it should be avoided. But it is

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

Raymond Hettinger added the comment: Yes, issue 23674 seems to be at least a partial duplicate. We should just get this fixed and close both issues. Ideally, the text can also be made more compact. Having eight paragraphs sends an implicit message that this is too complex to understand

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

Jeroen Demeyer added the comment: > Some of the problems brought up here (which sibling or subclass, and which > parameter’s MRO) also came up a few years ago in Issue 23674. Indeed. I would actually say that these two issues are duplicates of each other. --

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

Géry added the comment: @Steven D'Aprano > But neither can it *only* look at the MRO of the second class, because that > would restart the search at the top of the hierarchy; also if type(second > argument) was the only thing that mattered, that would make the first > argument redundant and

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

Martin Panter added the comment: Some of the problems brought up here (which sibling or subclass, and which parameter’s MRO) also came up a few years ago in Issue 23674. -- nosy: +martin.panter ___ Python tracker

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

Steven D'Aprano added the comment: > > What matters is the __mro__ attribute of the first argument. It matters > because that is how the MRO actually is searched. > > By the way, if it was true (it is not), Yes, I see that now. > then what did you think was > the purpose of the second

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

Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

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

Steven D'Aprano added the comment: > I'm sorry to say that you're wrong here. I'm happy to be corrected. It is fair to say I failed to take the multiple inheritance case into account. Clearly super can't *only* look at the MRO of the first object since that will miss the multiple

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

Raymond Hettinger added the comment: Please make a concrete proposal (a PR or somesuch). That will make it much easier to determine whether a particular bit of word-smithing is a improvement. Of the issues discussed so far, these are the most promising: * Document how the zero argument form

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

Géry added the comment: @Steven D'Aprano > What matters is the __mro__ attribute of the first argument. It matters because that is how the MRO actually is searched. By the way, if it was true (it is not), then what did you think was the purpose of the second parameter of super(type,

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

Géry added the comment: @Jeroen Demeyer > I'm sorry to say that you're wrong here. super() looks at the MRO of the type > of the object (the second argument) (*). Exactly! It is funny because I was about to open the same issue this weekend. The documentation of super() is wrong here.

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

Jeroen Demeyer added the comment: And this last comment is precisely the kind of information which should be explained in the super() docs. -- ___ Python tracker ___

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

Jeroen Demeyer added the comment: > What matters is the __mro__ attribute of the first argument. It matters because that is how the MRO actually is searched. I'm sorry to say that you're wrong here. super() looks at the MRO of the type of the object (the second argument) (*). It has to do

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

Steven D'Aprano added the comment: > If you have to explain in a bpo issue how the doc should be read, that > proves exactly my point that it's confusing. The fact that it's > technically correct if you read it the right way is irrelevant. Do you expect the docs to be technically correct

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

Steven D'Aprano added the comment: On Fri, Jun 07, 2019 at 09:57:11AM +, Jeroen Demeyer wrote: > I'm having problems with the first word of "a parent or sibling class of > type". The first word is "a". Did you mean something else or did you mean it literally? If the second case, we

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

Jeroen Demeyer added the comment: > The sentence doesn't talk about the MRO of *type* (the first argument), it talks about the __mro__ attribute. If you have to explain in a bpo issue how the doc should be read, that proves exactly my point that it's confusing. The fact that it's

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

Jeroen Demeyer added the comment: > Only one of the two arguments is called "type". The other is called "object-or-type". I'm having problems with the first word of "a parent or sibling class of type". The most important part of super() is to *which* class that attribute lookups are

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

Steven D'Aprano added the comment: On Fri, Jun 07, 2019 at 08:00:34AM +, Jeroen Demeyer wrote: > > Jeroen Demeyer 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

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

Jeroen Demeyer 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. And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and

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

Raymond Hettinger added the comment: > It only says "Return a proxy object that delegates method > calls to a parent or sibling class of type" and then gives > a bunch of use cases and examples." That wording seems very reasonable to me. -- nosy: +rhettinger

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

Steven D'Aprano added the comment: The docs do say what super does: it returns "a proxy object that delegates method calls to a parent or sibling class of type", just as you quoted. That concise description is (almost) completely accurate and precise. (I say *almost* because it's not just

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

Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg344892 ___ Python tracker ___ ___ Python-bugs-list

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

Steven D'Aprano added the comment: The docs do say what super does: it returns "a proxy object that delegates method calls to a parent or sibling class of type", just as you quoted. That concise description is (almost) completely accurate and precise. (I say *almost* because it's not just

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

New submission from Jeroen Demeyer : The documentation for super() at https://docs.python.org/3.8/library/functions.html#super does not actually say what super() does. It only says "Return a proxy object that delegates method calls to a parent or sibling class of type" and then gives a bunch