gh-136843: Document how multiple inheritance works #136844
Conversation
|
This all looks good to me except for the final section about "solid bases". That last section should be checked by another reviewer with a stronger understanding of the details. |
|
@ilovelinux |
|
The docs of |
Doc/reference/compound_stmts.rst
Outdated
| possible to compute a *solid base* for the class. A class is a solid base if it has a | ||
| nonempty :attr:`~object.__slots__` definition; some other classes may also be solid bases, |
There was a problem hiding this comment.
Can we also consider the __slots__ behaviour a CPython implementation detail?
IMO, it would be good if alternate implementations -- or even future versions of CPython -- could drop the limitation.
There was a problem hiding this comment.
Maybe, but this behavior is already documented in the __slots__ docs without any "implementation detail" warning.
There was a problem hiding this comment.
That note was added in #1819; it looks like a note on current behaviour rather than documenting design intent.
IMO, several of the notes are simply implementation limitations that we should be allowed to lift if the internals change.
There was a problem hiding this comment.
I moved the mention of __slots__ into the implementation detail section.
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Doc/reference/compound_stmts.rst
Outdated
| description of how Python determines the MRO for a class. | ||
|
|
||
| Multiple inheritance is not always allowed. Attempting to define a class with multiple | ||
| inheritance will raise an error if one of the bases is invalid, if a consistent MRO |
There was a problem hiding this comment.
I'm not sure about "one of the bases is invalid" part. Some class is not acceptable to be base class. Is it correct to call this class "invalid"? I'd suggest little rewording.
There was a problem hiding this comment.
I guess I was also thinking of trying to inherit from something that isn't a class. I'll reword.
Doc/reference/compound_stmts.rst
Outdated
| all other candidate metaclasses. If no such metaclass exists among the candidates, | ||
| the class cannot be created, as explained in :ref:`metaclass-determination`. | ||
|
|
||
| Finally, the memory layouts of the bases must be compatible. This means that it must be |
There was a problem hiding this comment.
Is it "memory layout" or "instance layout"? Or those are fully equivalent? This is not very obvious now.
There was a problem hiding this comment.
We debated how to describe this concept while writing the docs for the relevant ty rule. I think the clearest way to describe the concept is "the memory layout instances of the class will have", but that's a bit wordy 😄 "instance memory layout" is probably next best?
There was a problem hiding this comment.
I'll go with "instance layout" since that's what the TypeError says.
Co-authored-by: Akuli <akuviljanen17@gmail.com>
📚 Documentation preview 📚: https://cpython-previews--136844.org.readthedocs.build/