Refine docs for super() noting that sibling classes can

be called, not just parents.  Add a comparison to getattr()
which has the same search order but also includes the type
itself.

1 files changed, 13 insertions, 9 deletions

diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst
index e1436f8..3dfbb2b 100644
--- a/Doc/library/functions.rst
+++ b/Doc/library/functions.rst
@@ -1045,11 +1045,14 @@ are always available.  They are listed here in alphabetical order.
 
 .. function:: super([type[, object-or-type]])
 
-   Return a proxy object that delegates method calls to a parent class of
-   *type*.  This is useful for accessing inherited methods that have been
-   overriden in a child class.  The search order for parent classes is
-   determined by the ``__mro__`` attribute of the *type* and can change
-   whenever the parent classes are updated.
+   Return a proxy object that delegates method calls to a parent or sibling
+   class of *type*.  This is useful for accessing inherited methods that have
+   been overridden in a class. The search order is same as that used by
+   :func:`getattr` except that the *type* itself is skipped.
+
+   The ``__mro__`` attribute of the *type* lists the method resolution search
+   order used by both func:`getattr` and :func:`super`.  The attribue is dynamic
+   and can change whenever the inheritance hierarchy is updated.
 
    If the second argument is omitted the super object returned is unbound.  If
    the second argument is an object, ``isinstance(obj, type)`` must be true.  If
@@ -1061,14 +1064,15 @@ are always available.  They are listed here in alphabetical order.
    naming them explicitly, thus making the code more maintainable.  This use
    closely parallels the use of "super" in other programming languages.
 
-   The second use case is to support cooperative multiple inheritence in a
+   The second use case is to support cooperative multiple inheritance in a
    dynamic execution environment.  This use case is unique to Python and is
    not found in statically compiled languages or languages that only support
    single inheritance.  This makes in possible to implement "diamond diagrams"
    where multiple base classes implement the same method.  Good design dictates
    that this method have the same calling signature in every case (because the
-   order of parent calls is determined at runtime and because that order adapts
-   to changes in the class hierarchy).
+   order of calls is determined at runtime, because that order adapts
+   to changes in the class hierarchy, and because that order can include
+   sibling classes that are unknown prior to runtime).
 
    For both use cases, a typical superclass call looks like this::
 
@@ -1079,7 +1083,7 @@ are always available.  They are listed here in alphabetical order.
    Note that :func:`super` is implemented as part of the binding process for
    explicit dotted attribute lookups such as ``super().__getitem__(name)``.
    It does so by implementing its own :meth:`__getattribute__` method for searching
-   parent classes in a predictable order that supports cooperative multiple inheritance.
+   classes in a predictable order that supports cooperative multiple inheritance.
    Accordingly, :func:`super` is undefined for implicit lookups using statements or
    operators such as ``super()[name]``.