I’m not sure that this implementation detail should be documented in three places.
One place with an index should be enough. Please also use the right markup to mark it as an impl. detail.

@merwok Since class.__bases__ is defined in stdtypes.rst and datamodel.rst files, I wanted to define class.__base__ in these files.

I understand your reason, but still think one place would be better than 3. I would like to see other people’s opinion!

For the markup, I meant this: https://devguide.python.org/documentation/markup/#codecell33 🙂

I understand your reason, but still think one place would be better than 3. I would like to see other people’s opinion!

CC: @hugovk @CAM-Gerlach

I don't have a strong opinion, but if it's an implementation detail, fewer places might be better. The search should help people find it when they're looking.

@furkanonder, can you please rework this PR to align with the comments Raymond, Guido, and Éric gave on the issue?

@erlend-aasland Based on Raymond, Guido, and Éric's feedback, I believe changes have been made. Could you please let me know if there is anything I missed?

@erlend-aasland Based on Raymond, Guido, and Éric's feedback, I believe changes have been made. Could you please let me know if there is anything I missed?

Not at all. I will repeat their comments here:

Raymond said in #66646 (comment):

I think that base was intended to be a non-guaranteed implementation detail for new-style classes just like dictoffset and flags .

Guido followed up in #66646 (comment):

Raymond is correct. base is closely tied to the C implementation. I think it might be worth a mention, but with an explicit note that it is CPython-specific. It is sometimes useful, e.g. when wondering why a certain case of multiple inheritance is rejected.

So, we're talking about a non-guaranteed implementation detail. You've also been told multiple times that a single mention is sufficient, yet you do not follow up this; your PR still changes three doc files, including the reference. "Worth a mention" is far from your PR which adds 64 (!) lines.

I'm sorry, but I cannot see that you've taken any review or issue remarks into account.

I understand your reason, but still think one place would be better than 3. I would like to see other people’s opinion!

I didn't think that the idea of repetition here was stated unequivocally, since he said I would like to see other people's views!.

"Worth a mention" is far from your PR which adds 64 (!) lines.

I think it might be worth a mention, but with an explicit note that it is CPython-specific.

The statement does not include a line count for the section to be documented. Hence I did not consider the amount of lines for the section. The reason for the 64 lines of the section was to ensure a better understanding of the subject by supporting it with examples.

I re-read the original ticket — I think this PR adds too much text.
«A mention» was meant to be a line or two, possibly all in an impl-detail block.
Here we have many paragraphs, going into details about inheritance that should be already covered somewhere else!

I re-read the original ticket — I think this PR adds too much text.
«A mention» was meant to be a line or two, possibly all in an impl-detail block.
Here we have many paragraphs, going into details about inheritance that should be already covered somewhere else!

I've shortened the explanation as requested. I was thinking that keeping the examples would make it easier to understand. Regarding your comment about "inheritance that should be already covered somewhere else" - it actually hasn't been covered anywhere else in the documentation. Could you point me to where you think this information should be documented instead?

You’re right, the specific docs for __bases__ and __mro__ don’t explain how base classes (included parent classes) are collapsed. But https://docs.python.org/3/howto/mro.html does.

If you think clarifications are helpful, I would expand the notes for one of these official attributes, not __base__.