summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRaymond Hettinger <python@rcn.com>2007-04-03 01:37:56 (GMT)
committerRaymond Hettinger <python@rcn.com>2007-04-03 01:37:56 (GMT)
commit95289052f77f91c09c75cfcd699a6651cd13bb9c (patch)
tree4d16e27933d169aaa09ffcb26a705f5188f0c266
parent6a390b34b72cbffdea2115f5e2594895dbbd5c09 (diff)
downloadcpython-95289052f77f91c09c75cfcd699a6651cd13bb9c.zip
cpython-95289052f77f91c09c75cfcd699a6651cd13bb9c.tar.gz
cpython-95289052f77f91c09c75cfcd699a6651cd13bb9c.tar.bz2
SF #1382213: Tutorial section 9.5.1 ignores MRO for new-style classes
-rw-r--r--Doc/tut/tut.tex31
1 files changed, 20 insertions, 11 deletions
diff --git a/Doc/tut/tut.tex b/Doc/tut/tut.tex
index 342fbca..2981a78 100644
--- a/Doc/tut/tut.tex
+++ b/Doc/tut/tut.tex
@@ -4329,8 +4329,7 @@ class DerivedClassName(Base1, Base2, Base3):
<statement-N>
\end{verbatim}
-The only rule necessary to explain the semantics is the resolution
-rule used for class attribute references. This is depth-first,
+For old-style classes, the only rule is depth-first,
left-to-right. Thus, if an attribute is not found in
\class{DerivedClassName}, it is searched in \class{Base1}, then
(recursively) in the base classes of \class{Base1}, and only if it is
@@ -4345,16 +4344,26 @@ a name conflict with an attribute of \class{Base2}. The depth-first
rule makes no differences between direct and inherited attributes of
\class{Base1}.)
-It is clear that indiscriminate use of multiple inheritance is a
-maintenance nightmare, given the reliance in Python on conventions to
-avoid accidental name conflicts. A well-known problem with multiple
-inheritance is a class derived from two classes that happen to have a
-common base class. While it is easy enough to figure out what happens
-in this case (the instance will have a single copy of ``instance
-variables'' or data attributes used by the common base class), it is
-not clear that these semantics are in any way useful.
+For new-style classes, the method resolution order changes dynamically
+to support cooperative calls to \function{super()}. This approach
+is known in some other multiple-inheritance languages as call-next-method
+and is more powerful than the super call found in single-inheritance languages.
+
+With new-style classes, dynamic ordering is necessary because all
+cases of multiple inheritance exhibit one or more diamond relationships
+(where one at least one of the parent classes can be accessed through
+multiple paths from the bottommost class). For example, all new-style
+classes inherit from \class{object}, so any case of multiple inheritance
+provides more than one path to reach \class{object}. To keep the
+base classes from being accessed more than once, the dynamic algorithm
+linearizes the search order in a way that preserves the left-to-right
+ordering specified in each class, that calls each parent only once, and
+that is monotonic (meaning that a class can be subclassed without affecting
+the precedence order of its parents). Taken together, these properties
+make it possible to design reliable and extensible classes with
+multiple inheritance. For more detail, see
+\url{http://www.python.org/download/releases/2.3/mro/}.
-%% XXX Add rules for new-style MRO?
\section{Private Variables \label{private}}