# SOME DESCRIPTIVE TITLE. # Copyright (C) 2001 Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , YEAR. # # Translators: # python-doc bot, 2025 # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 3.14\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2025-10-27 14:15+0000\n" "PO-Revision-Date: 2025-09-16 00:00+0000\n" "Last-Translator: python-doc bot, 2025\n" "Language-Team: Japanese (https://app.transifex.com/python-doc/teams/5390/" "ja/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Language: ja\n" "Plural-Forms: nplurals=1; plural=0;\n" #: ../../howto/mro.rst:4 msgid "The Python 2.3 Method Resolution Order" msgstr "" #: ../../howto/mro.rst:8 msgid "" "This is a historical document, provided as an appendix to the official " "documentation. The Method Resolution Order discussed here was *introduced* " "in Python 2.3, but it is still used in later versions -- including Python 3." msgstr "" #: ../../howto/mro.rst:13 msgid "By `Michele Simionato `__." msgstr "" #: ../../howto/mro.rst:0 msgid "Abstract" msgstr "概要" #: ../../howto/mro.rst:17 msgid "" "*This document is intended for Python programmers who want to understand the " "C3 Method Resolution Order used in Python 2.3. Although it is not intended " "for newbies, it is quite pedagogical with many worked out examples. I am " "not aware of other publicly available documents with the same scope, " "therefore it should be useful.*" msgstr "" #: ../../howto/mro.rst:23 msgid "Disclaimer:" msgstr "" #: ../../howto/mro.rst:25 msgid "" "*I donate this document to the Python Software Foundation, under the Python " "2.3 license. As usual in these circumstances, I warn the reader that what " "follows* should *be correct, but I don't give any warranty. Use it at your " "own risk and peril!*" msgstr "" #: ../../howto/mro.rst:30 msgid "Acknowledgments:" msgstr "" #: ../../howto/mro.rst:32 msgid "" "*All the people of the Python mailing list who sent me their support. Paul " "Foley who pointed out various imprecisions and made me to add the part on " "local precedence ordering. David Goodger for help with the formatting in " "reStructuredText. David Mertz for help with the editing. Finally, Guido van " "Rossum who enthusiastically added this document to the official Python 2.3 " "home-page.*" msgstr "" #: ../../howto/mro.rst:40 msgid "The beginning" msgstr "" #: ../../howto/mro.rst:42 msgid "*Felix qui potuit rerum cognoscere causas* -- Virgilius" msgstr "" #: ../../howto/mro.rst:44 msgid "" "Everything started with a post by Samuele Pedroni to the Python development " "mailing list [#]_. In his post, Samuele showed that the Python 2.2 method " "resolution order is not monotonic and he proposed to replace it with the C3 " "method resolution order. Guido agreed with his arguments and therefore now " "Python 2.3 uses C3. The C3 method itself has nothing to do with Python, " "since it was invented by people working on Dylan and it is described in a " "paper intended for lispers [#]_. The present paper gives a (hopefully) " "readable discussion of the C3 algorithm for Pythonistas who want to " "understand the reasons for the change." msgstr "" #: ../../howto/mro.rst:55 msgid "" "First of all, let me point out that what I am going to say only applies to " "the *new style classes* introduced in Python 2.2: *classic classes* " "maintain their old method resolution order, depth first and then left to " "right. Therefore, there is no breaking of old code for classic classes; and " "even if in principle there could be breaking of code for Python 2.2 new " "style classes, in practice the cases in which the C3 resolution order " "differs from the Python 2.2 method resolution order are so rare that no real " "breaking of code is expected. Therefore:" msgstr "" #: ../../howto/mro.rst:64 msgid "*Don't be scared!*" msgstr "" #: ../../howto/mro.rst:66 msgid "" "Moreover, unless you make strong use of multiple inheritance and you have " "non-trivial hierarchies, you don't need to understand the C3 algorithm, and " "you can easily skip this paper. On the other hand, if you really want to " "know how multiple inheritance works, then this paper is for you. The good " "news is that things are not as complicated as you might expect." msgstr "" #: ../../howto/mro.rst:73 msgid "Let me begin with some basic definitions." msgstr "" #: ../../howto/mro.rst:75 msgid "" "Given a class C in a complicated multiple inheritance hierarchy, it is a non-" "trivial task to specify the order in which methods are overridden, i.e. to " "specify the order of the ancestors of C." msgstr "" #: ../../howto/mro.rst:79 msgid "" "The list of the ancestors of a class C, including the class itself, ordered " "from the nearest ancestor to the furthest, is called the class precedence " "list or the *linearization* of C." msgstr "" #: ../../howto/mro.rst:83 msgid "" "The *Method Resolution Order* (MRO) is the set of rules that construct the " "linearization. In the Python literature, the idiom \"the MRO of C\" is also " "used as a synonymous for the linearization of the class C." msgstr "" #: ../../howto/mro.rst:88 msgid "" "For instance, in the case of single inheritance hierarchy, if C is a " "subclass of C1, and C1 is a subclass of C2, then the linearization of C is " "simply the list [C, C1 , C2]. However, with multiple inheritance " "hierarchies, the construction of the linearization is more cumbersome, since " "it is more difficult to construct a linearization that respects *local " "precedence ordering* and *monotonicity*." msgstr "" #: ../../howto/mro.rst:96 msgid "" "I will discuss the local precedence ordering later, but I can give the " "definition of monotonicity here. A MRO is monotonic when the following is " "true: *if C1 precedes C2 in the linearization of C, then C1 precedes C2 in " "the linearization of any subclass of C*. Otherwise, the innocuous operation " "of deriving a new class could change the resolution order of methods, " "potentially introducing very subtle bugs. Examples where this happens will " "be shown later." msgstr "" #: ../../howto/mro.rst:104 msgid "" "Not all classes admit a linearization. There are cases, in complicated " "hierarchies, where it is not possible to derive a class such that its " "linearization respects all the desired properties." msgstr "" #: ../../howto/mro.rst:108 msgid "Here I give an example of this situation. Consider the hierarchy" msgstr "" #: ../../howto/mro.rst:116 msgid "" "which can be represented with the following inheritance graph, where I have " "denoted with O the ``object`` class, which is the beginning of any hierarchy " "for new style classes:" msgstr "" #: ../../howto/mro.rst:120 msgid "" " -----------\n" "| |\n" "| O |\n" "| / \\ |\n" " - X Y /\n" " | / | /\n" " | / |/\n" " A B\n" " \\ /\n" " ?" msgstr "" #: ../../howto/mro.rst:133 msgid "" "In this case, it is not possible to derive a new class C from A and B, since " "X precedes Y in A, but Y precedes X in B, therefore the method resolution " "order would be ambiguous in C." msgstr "" #: ../../howto/mro.rst:137 msgid "" "Python 2.3 raises an exception in this situation (TypeError: MRO conflict " "among bases Y, X) forbidding the naive programmer from creating ambiguous " "hierarchies. Python 2.2 instead does not raise an exception, but chooses an " "*ad hoc* ordering (CABXYO in this case)." msgstr "" #: ../../howto/mro.rst:143 msgid "The C3 Method Resolution Order" msgstr "" #: ../../howto/mro.rst:145 msgid "" "Let me introduce a few simple notations which will be useful for the " "following discussion. I will use the shortcut notation::" msgstr "" #: ../../howto/mro.rst:148 msgid "C1 C2 ... CN" msgstr "" #: ../../howto/mro.rst:150 msgid "to indicate the list of classes [C1, C2, ... , CN]." msgstr "" #: ../../howto/mro.rst:152 msgid "The *head* of the list is its first element::" msgstr "" #: ../../howto/mro.rst:154 msgid "head = C1" msgstr "" #: ../../howto/mro.rst:156 msgid "whereas the *tail* is the rest of the list::" msgstr "" #: ../../howto/mro.rst:158 msgid "tail = C2 ... CN." msgstr "" #: ../../howto/mro.rst:160 msgid "I shall also use the notation::" msgstr "" #: ../../howto/mro.rst:162 msgid "C + (C1 C2 ... CN) = C C1 C2 ... CN" msgstr "" #: ../../howto/mro.rst:164 msgid "to denote the sum of the lists [C] + [C1, C2, ... ,CN]." msgstr "" #: ../../howto/mro.rst:166 msgid "Now I can explain how the MRO works in Python 2.3." msgstr "" #: ../../howto/mro.rst:168 msgid "" "Consider a class C in a multiple inheritance hierarchy, with C inheriting " "from the base classes B1, B2, ... , BN. We want to compute the " "linearization L[C] of the class C. The rule is the following:" msgstr "" #: ../../howto/mro.rst:173 msgid "" "*the linearization of C is the sum of C plus the merge of the linearizations " "of the parents and the list of the parents.*" msgstr "" #: ../../howto/mro.rst:176 msgid "In symbolic notation::" msgstr "" #: ../../howto/mro.rst:178 msgid "L[C(B1 ... BN)] = C + merge(L[B1] ... L[BN], B1 ... BN)" msgstr "" #: ../../howto/mro.rst:180 msgid "" "In particular, if C is the ``object`` class, which has no parents, the " "linearization is trivial::" msgstr "" #: ../../howto/mro.rst:183 msgid "L[object] = object." msgstr "" #: ../../howto/mro.rst:185 msgid "" "However, in general one has to compute the merge according to the following " "prescription:" msgstr "" #: ../../howto/mro.rst:188 msgid "" "*take the head of the first list, i.e L[B1][0]; if this head is not in the " "tail of any of the other lists, then add it to the linearization of C and " "remove it from the lists in the merge, otherwise look at the head of the " "next list and take it, if it is a good head. Then repeat the operation " "until all the class are removed or it is impossible to find good heads. In " "this case, it is impossible to construct the merge, Python 2.3 will refuse " "to create the class C and will raise an exception.*" msgstr "" #: ../../howto/mro.rst:197 msgid "" "This prescription ensures that the merge operation *preserves* the ordering, " "if the ordering can be preserved. On the other hand, if the order cannot be " "preserved (as in the example of serious order disagreement discussed above) " "then the merge cannot be computed." msgstr "" #: ../../howto/mro.rst:202 msgid "" "The computation of the merge is trivial if C has only one parent (single " "inheritance); in this case::" msgstr "" #: ../../howto/mro.rst:205 msgid "L[C(B)] = C + merge(L[B],B) = C + L[B]" msgstr "" #: ../../howto/mro.rst:207 msgid "" "However, in the case of multiple inheritance things are more cumbersome and " "I don't expect you can understand the rule without a couple of examples ;-)" msgstr "" #: ../../howto/mro.rst:212 msgid "Examples" msgstr "使用例" #: ../../howto/mro.rst:214 msgid "First example. Consider the following hierarchy:" msgstr "" #: ../../howto/mro.rst:224 msgid "In this case the inheritance graph can be drawn as:" msgstr "" #: ../../howto/mro.rst:226 msgid "" " 6\n" " ---\n" "Level 3 | O | (more general)\n" " / --- \\\n" " / | \\ |\n" " / | \\ |\n" " / | \\ |\n" " --- --- --- |\n" "Level 2 3 | D | 4| E | | F | 5 |\n" " --- --- --- |\n" " \\ \\ _ / | |\n" " \\ / \\ _ | |\n" " \\ / \\ | |\n" " --- --- |\n" "Level 1 1 | B | | C | 2 |\n" " --- --- |\n" " \\ / |\n" " \\ / \\ /\n" " ---\n" "Level 0 0 | A | (more specialized)\n" " ---" msgstr "" #: ../../howto/mro.rst:251 msgid "The linearizations of O,D,E and F are trivial::" msgstr "" #: ../../howto/mro.rst:253 msgid "" "L[O] = O\n" "L[D] = D O\n" "L[E] = E O\n" "L[F] = F O" msgstr "" #: ../../howto/mro.rst:258 msgid "The linearization of B can be computed as::" msgstr "" #: ../../howto/mro.rst:260 msgid "L[B] = B + merge(DO, EO, DE)" msgstr "" #: ../../howto/mro.rst:262 msgid "" "We see that D is a good head, therefore we take it and we are reduced to " "compute ``merge(O,EO,E)``. Now O is not a good head, since it is in the " "tail of the sequence EO. In this case the rule says that we have to skip to " "the next sequence. Then we see that E is a good head; we take it and we are " "reduced to compute ``merge(O,O)`` which gives O. Therefore::" msgstr "" #: ../../howto/mro.rst:268 msgid "L[B] = B D E O" msgstr "" #: ../../howto/mro.rst:270 msgid "Using the same procedure one finds::" msgstr "" #: ../../howto/mro.rst:272 msgid "" "L[C] = C + merge(DO,FO,DF)\n" " = C + D + merge(O,FO,F)\n" " = C + D + F + merge(O,O)\n" " = C D F O" msgstr "" #: ../../howto/mro.rst:277 msgid "Now we can compute::" msgstr "" #: ../../howto/mro.rst:279 msgid "" "L[A] = A + merge(BDEO,CDFO,BC)\n" " = A + B + merge(DEO,CDFO,C)\n" " = A + B + C + merge(DEO,DFO)\n" " = A + B + C + D + merge(EO,FO)\n" " = A + B + C + D + E + merge(O,FO)\n" " = A + B + C + D + E + F + merge(O,O)\n" " = A B C D E F O" msgstr "" #: ../../howto/mro.rst:287 msgid "" "In this example, the linearization is ordered in a pretty nice way according " "to the inheritance level, in the sense that lower levels (i.e. more " "specialized classes) have higher precedence (see the inheritance graph). " "However, this is not the general case." msgstr "" #: ../../howto/mro.rst:292 msgid "" "I leave as an exercise for the reader to compute the linearization for my " "second example:" msgstr "" #: ../../howto/mro.rst:303 msgid "" "The only difference with the previous example is the change B(D,E) --> B(E," "D); however even such a little modification completely changes the ordering " "of the hierarchy:" msgstr "" #: ../../howto/mro.rst:307 msgid "" " 6\n" " ---\n" "Level 3 | O |\n" " / --- \\\n" " / | \\\n" " / | \\\n" " / | \\\n" " --- --- ---\n" "Level 2 2 | E | 4 | D | | F | 5\n" " --- --- ---\n" " \\ / \\ /\n" " \\ / \\ /\n" " \\ / \\ /\n" " --- ---\n" "Level 1 1 | B | | C | 3\n" " --- ---\n" " \\ /\n" " \\ /\n" " ---\n" "Level 0 0 | A |\n" " ---" msgstr "" #: ../../howto/mro.rst:332 msgid "" "Notice that the class E, which is in the second level of the hierarchy, " "precedes the class C, which is in the first level of the hierarchy, i.e. E " "is more specialized than C, even if it is in a higher level." msgstr "" #: ../../howto/mro.rst:336 msgid "" "A lazy programmer can obtain the MRO directly from Python 2.2, since in this " "case it coincides with the Python 2.3 linearization. It is enough to invoke " "the :meth:`~type.mro` method of class A:" msgstr "" #: ../../howto/mro.rst:345 msgid "" "Finally, let me consider the example discussed in the first section, " "involving a serious order disagreement. In this case, it is straightforward " "to compute the linearizations of O, X, Y, A and B:" msgstr "" #: ../../howto/mro.rst:349 msgid "" "L[O] = 0\n" "L[X] = X O\n" "L[Y] = Y O\n" "L[A] = A X Y O\n" "L[B] = B Y X O" msgstr "" #: ../../howto/mro.rst:357 msgid "" "However, it is impossible to compute the linearization for a class C that " "inherits from A and B::" msgstr "" #: ../../howto/mro.rst:360 msgid "" "L[C] = C + merge(AXYO, BYXO, AB)\n" " = C + A + merge(XYO, BYXO, B)\n" " = C + A + B + merge(XYO, YXO)" msgstr "" #: ../../howto/mro.rst:364 msgid "" "At this point we cannot merge the lists XYO and YXO, since X is in the tail " "of YXO whereas Y is in the tail of XYO: therefore there are no good heads " "and the C3 algorithm stops. Python 2.3 raises an error and refuses to " "create the class C." msgstr "" #: ../../howto/mro.rst:370 msgid "Bad Method Resolution Orders" msgstr "" #: ../../howto/mro.rst:372 msgid "" "A MRO is *bad* when it breaks such fundamental properties as local " "precedence ordering and monotonicity. In this section, I will show that " "both the MRO for classic classes and the MRO for new style classes in Python " "2.2 are bad." msgstr "" #: ../../howto/mro.rst:377 msgid "" "It is easier to start with the local precedence ordering. Consider the " "following example:" msgstr "" #: ../../howto/mro.rst:384 msgid "with inheritance diagram" msgstr "" #: ../../howto/mro.rst:386 msgid "" " O\n" " |\n" "(buy spam) F\n" " | \\\n" " | E (buy eggs)\n" " | /\n" " G\n" "\n" " (buy eggs or spam ?)" msgstr "" #: ../../howto/mro.rst:399 msgid "" "We see that class G inherits from F and E, with F *before* E: therefore we " "would expect the attribute *G.remember2buy* to be inherited by *F." "remember2buy* and not by *E.remember2buy*: nevertheless Python 2.2 gives" msgstr "" #: ../../howto/mro.rst:407 msgid "" "This is a breaking of local precedence ordering since the order in the local " "precedence list, i.e. the list of the parents of G, is not preserved in the " "Python 2.2 linearization of G::" msgstr "" #: ../../howto/mro.rst:411 msgid "L[G,P22]= G E F object # F *follows* E" msgstr "" #: ../../howto/mro.rst:413 msgid "" "One could argue that the reason why F follows E in the Python 2.2 " "linearization is that F is less specialized than E, since F is the " "superclass of E; nevertheless the breaking of local precedence ordering is " "quite non-intuitive and error prone. This is particularly true since it is " "a different from old style classes:" msgstr "" #: ../../howto/mro.rst:425 msgid "" "In this case the MRO is GFEF and the local precedence ordering is preserved." msgstr "" #: ../../howto/mro.rst:428 msgid "" "As a general rule, hierarchies such as the previous one should be avoided, " "since it is unclear if F should override E or vice-versa. Python 2.3 solves " "the ambiguity by raising an exception in the creation of class G, " "effectively stopping the programmer from generating ambiguous hierarchies. " "The reason for that is that the C3 algorithm fails when the merge::" msgstr "" #: ../../howto/mro.rst:435 msgid "merge(FO,EFO,FE)" msgstr "" #: ../../howto/mro.rst:437 msgid "" "cannot be computed, because F is in the tail of EFO and E is in the tail of " "FE." msgstr "" #: ../../howto/mro.rst:440 msgid "" "The real solution is to design a non-ambiguous hierarchy, i.e. to derive G " "from E and F (the more specific first) and not from F and E; in this case " "the MRO is GEF without any doubt." msgstr "" #: ../../howto/mro.rst:444 msgid "" " O\n" " |\n" " F (spam)\n" " / |\n" "(eggs) E |\n" " \\ |\n" " G\n" " (eggs, no doubt)" msgstr "" #: ../../howto/mro.rst:456 msgid "" "Python 2.3 forces the programmer to write good hierarchies (or, at least, " "less error-prone ones)." msgstr "" #: ../../howto/mro.rst:459 msgid "" "On a related note, let me point out that the Python 2.3 algorithm is smart " "enough to recognize obvious mistakes, as the duplication of classes in the " "list of parents:" msgstr "" #: ../../howto/mro.rst:469 msgid "" "Python 2.2 (both for classic classes and new style classes) in this " "situation, would not raise any exception." msgstr "" #: ../../howto/mro.rst:472 msgid "" "Finally, I would like to point out two lessons we have learned from this " "example:" msgstr "" #: ../../howto/mro.rst:475 msgid "" "despite the name, the MRO determines the resolution order of attributes, not " "only of methods;" msgstr "" #: ../../howto/mro.rst:478 msgid "" "the default food for Pythonistas is spam ! (but you already knew that ;-)" msgstr "" #: ../../howto/mro.rst:481 msgid "" "Having discussed the issue of local precedence ordering, let me now consider " "the issue of monotonicity. My goal is to show that neither the MRO for " "classic classes nor that for Python 2.2 new style classes is monotonic." msgstr "" #: ../../howto/mro.rst:486 msgid "" "To prove that the MRO for classic classes is non-monotonic is rather " "trivial, it is enough to look at the diamond diagram:" msgstr "" #: ../../howto/mro.rst:489 msgid "" " C\n" " / \\\n" " / \\\n" "A B\n" " \\ /\n" " \\ /\n" " D" msgstr "" #: ../../howto/mro.rst:500 msgid "One easily discerns the inconsistency::" msgstr "" #: ../../howto/mro.rst:502 msgid "" "L[B,P21] = B C # B precedes C : B's methods win\n" "L[D,P21] = D A C B C # B follows C : C's methods win!" msgstr "" #: ../../howto/mro.rst:505 msgid "" "On the other hand, there are no problems with the Python 2.2 and 2.3 MROs, " "they give both::" msgstr "" #: ../../howto/mro.rst:508 msgid "L[D] = D A B C" msgstr "" #: ../../howto/mro.rst:510 msgid "" "Guido points out in his essay [#]_ that the classic MRO is not so bad in " "practice, since one can typically avoids diamonds for classic classes. But " "all new style classes inherit from ``object``, therefore diamonds are " "unavoidable and inconsistencies shows up in every multiple inheritance graph." msgstr "" #: ../../howto/mro.rst:516 msgid "" "The MRO of Python 2.2 makes breaking monotonicity difficult, but not " "impossible. The following example, originally provided by Samuele Pedroni, " "shows that the MRO of Python 2.2 is non-monotonic:" msgstr "" #: ../../howto/mro.rst:530 msgid "" "Here are the linearizations according to the C3 MRO (the reader should " "verify these linearizations as an exercise and draw the inheritance " "diagram ;-) ::" msgstr "" #: ../../howto/mro.rst:534 msgid "" "L[A] = A O\n" "L[B] = B O\n" "L[C] = C O\n" "L[D] = D O\n" "L[E] = E O\n" "L[K1]= K1 A B C O\n" "L[K2]= K2 D B E O\n" "L[K3]= K3 D A O\n" "L[Z] = Z K1 K2 K3 D A B C E O" msgstr "" #: ../../howto/mro.rst:544 msgid "" "Python 2.2 gives exactly the same linearizations for A, B, C, D, E, K1, K2 " "and K3, but a different linearization for Z::" msgstr "" #: ../../howto/mro.rst:547 msgid "L[Z,P22] = Z K1 K3 A K2 D B C E O" msgstr "" #: ../../howto/mro.rst:549 msgid "" "It is clear that this linearization is *wrong*, since A comes before D " "whereas in the linearization of K3 A comes *after* D. In other words, in K3 " "methods derived by D override methods derived by A, but in Z, which still is " "a subclass of K3, methods derived by A override methods derived by D! This " "is a violation of monotonicity. Moreover, the Python 2.2 linearization of Z " "is also inconsistent with local precedence ordering, since the local " "precedence list of the class Z is [K1, K2, K3] (K2 precedes K3), whereas in " "the linearization of Z K2 *follows* K3. These problems explain why the 2.2 " "rule has been dismissed in favor of the C3 rule." msgstr "" #: ../../howto/mro.rst:561 msgid "The end" msgstr "" #: ../../howto/mro.rst:563 msgid "" "This section is for the impatient reader, who skipped all the previous " "sections and jumped immediately to the end. This section is for the lazy " "programmer too, who didn't want to exercise her/his brain. Finally, it is " "for the programmer with some hubris, otherwise s/he would not be reading a " "paper on the C3 method resolution order in multiple inheritance " "hierarchies ;-) These three virtues taken all together (and *not* " "separately) deserve a prize: the prize is a short Python 2.2 script that " "allows you to compute the 2.3 MRO without risk to your brain. Simply change " "the last line to play with the various examples I have discussed in this " "paper.::" msgstr "" #: ../../howto/mro.rst:574 msgid "" "#\n" "\n" "\"\"\"C3 algorithm by Samuele Pedroni (with readability enhanced by me)." "\"\"\"\n" "\n" "class __metaclass__(type):\n" " \"All classes are metamagically modified to be nicely printed\"\n" " __repr__ = lambda cls: cls.__name__\n" "\n" "class ex_2:\n" " \"Serious order disagreement\" #From Guido\n" " class O: pass\n" " class X(O): pass\n" " class Y(O): pass\n" " class A(X,Y): pass\n" " class B(Y,X): pass\n" " try:\n" " class Z(A,B): pass #creates Z(A,B) in Python 2.2\n" " except TypeError:\n" " pass # Z(A,B) cannot be created in Python 2.3\n" "\n" "class ex_5:\n" " \"My first example\"\n" " class O: pass\n" " class F(O): pass\n" " class E(O): pass\n" " class D(O): pass\n" " class C(D,F): pass\n" " class B(D,E): pass\n" " class A(B,C): pass\n" "\n" "class ex_6:\n" " \"My second example\"\n" " class O: pass\n" " class F(O): pass\n" " class E(O): pass\n" " class D(O): pass\n" " class C(D,F): pass\n" " class B(E,D): pass\n" " class A(B,C): pass\n" "\n" "class ex_9:\n" " \"Difference between Python 2.2 MRO and C3\" #From Samuele\n" " class O: pass\n" " class A(O): pass\n" " class B(O): pass\n" " class C(O): pass\n" " class D(O): pass\n" " class E(O): pass\n" " class K1(A,B,C): pass\n" " class K2(D,B,E): pass\n" " class K3(D,A): pass\n" " class Z(K1,K2,K3): pass\n" "\n" "def merge(seqs):\n" " print '\\n\\nCPL[%s]=%s' % (seqs[0][0],seqs),\n" " res = []; i=0\n" " while 1:\n" " nonemptyseqs=[seq for seq in seqs if seq]\n" " if not nonemptyseqs: return res\n" " i+=1; print '\\n',i,'round: candidates...',\n" " for seq in nonemptyseqs: # find merge candidates among seq heads\n" " cand = seq[0]; print ' ',cand,\n" " nothead=[s for s in nonemptyseqs if cand in s[1:]]\n" " if nothead: cand=None #reject candidate\n" " else: break\n" " if not cand: raise \"Inconsistent hierarchy\"\n" " res.append(cand)\n" " for seq in nonemptyseqs: # remove cand\n" " if seq[0] == cand: del seq[0]\n" "\n" "def mro(C):\n" " \"Compute the class precedence list (mro) according to C3\"\n" " return merge([[C]]+map(mro,C.__bases__)+[list(C.__bases__)])\n" "\n" "def print_mro(C):\n" " print '\\nMRO[%s]=%s' % (C,mro(C))\n" " print '\\nP22 MRO[%s]=%s' % (C,C.mro())\n" "\n" "print_mro(ex_9.Z)\n" "\n" "#" msgstr "" #: ../../howto/mro.rst:656 msgid "That's all folks," msgstr "" #: ../../howto/mro.rst:658 msgid "enjoy !" msgstr "" #: ../../howto/mro.rst:662 msgid "Resources" msgstr "" #: ../../howto/mro.rst:664 msgid "" "The thread on python-dev started by Samuele Pedroni: https://mail.python.org/" "pipermail/python-dev/2002-October/029035.html" msgstr "" #: ../../howto/mro.rst:667 msgid "" "The paper *A Monotonic Superclass Linearization for Dylan*: https://doi." "org/10.1145/236337.236343" msgstr "" #: ../../howto/mro.rst:670 msgid "" "Guido van Rossum's essay, *Unifying types and classes in Python 2.2*: " "https://web.archive.org/web/20140210194412/http://www.python.org/download/" "releases/2.2.2/descrintro" msgstr ""