python-docs-pl/howto/mro.po at 3.12 · python/python-docs-pl

791 lines (671 loc) · 24.3 KB
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-2026, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# Translators:
# Rafael Fontenelle <rffontenelle@gmail.com>, 2025
"Project-Id-Version: Python 3.12\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-03-17 16:36+0000\n"
"PO-Revision-Date: 2025-07-18 19:57+0000\n"
"Last-Translator: Rafael Fontenelle <rffontenelle@gmail.com>, 2025\n"
"Language-Team: Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: pl\n"
"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : (n%10>=2 && n%10<=4) && "
"(n%100<12 || n%100>14) ? 1 : n!=1 && (n%10>=0 && n%10<=1) || (n%10>=5 && "
"n%10<=9) || (n%100>=12 && n%100<=14) ? 2 : 3);\n"
msgid "The Python 2.3 Method Resolution Order"
"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."
msgid "By `Michele Simionato <https://www.phyast.pitt.edu/~micheles/>`__."
msgid "Abstract"
msgstr "Streszczenie"
"*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.*"
msgid "Disclaimer:"
"*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!*"
msgid "Acknowledgments:"
"*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.*"
msgid "The beginning"
msgid "*Felix qui potuit rerum cognoscere causas* -- Virgilius"
"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."
"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:"
msgid "*Don't be scared!*"
"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."
msgid "Let me begin with some basic definitions."
"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."
"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."
"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."
"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*."
"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."
"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."
msgid "Here I give an example of this situation. Consider the hierarchy"
"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:"
" -----------\n"
"|           |\n"
"|    O      |\n"
"|  /   \\    |\n"
" - X    Y  /\n"
"   |  / | /\n"
"   | /  |/\n"
"   A    B\n"
"   \\   /\n"
"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."
"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)."
msgid "The C3 Method Resolution Order"
"Let me introduce a few simple notations which will be useful for the "
"following discussion.  I will use the shortcut notation::"
msgid "C1 C2 ... CN"
msgid "to indicate the list of classes [C1, C2, ... , CN]."
msgid "The *head* of the list is its first element::"
msgid "head = C1"
msgid "whereas the *tail* is the rest of the list::"
msgid "tail = C2 ... CN."
msgid "I shall also use the notation::"
msgid "C + (C1 C2 ... CN) = C C1 C2 ... CN"
msgid "to denote the sum of the lists [C] + [C1, C2, ... ,CN]."
msgid "Now I can explain how the MRO works in Python 2.3."
"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:"
"*the linearization of C is the sum of C plus the merge of the linearizations "
"of the parents and the list of the parents.*"
msgid "In symbolic notation::"
msgid "L[C(B1 ... BN)] = C + merge(L[B1] ... L[BN], B1 ... BN)"
"In particular, if C is the ``object`` class, which has no parents, the "
"linearization is trivial::"
msgid "L[object] = object."
"However, in general one has to compute the merge according to the following "
"prescription:"
"*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.*"
"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."
"The computation of the merge is trivial if C has only one parent (single "
"inheritance); in this case::"
msgid "L[C(B)] = C + merge(L[B],B) = C + L[B]"
"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 ;-)"
msgid "Examples"
msgstr "Przykłady"
msgid "First example. Consider the following hierarchy:"
msgid "In this case the inheritance graph can be drawn as:"
"                         ---\n"
"Level 3                 | O |                  (more general)\n"
"                      /  ---  \\\n"
"                  ---    ---    ---                   |\n"
"Level 2        3 | D | 4| E |  | F | 5                |\n"
"                  ---    ---    ---                   |\n"
"Level 1            1 | B |    | C | 2                 |\n"
"                           ---\n"
"Level 0                 0 | A |                (more specialized)\n"
msgid "The linearizations of O,D,E and F are trivial::"
"L[O] = O\n"
"L[D] = D O\n"
"L[E] = E O\n"
"L[F] = F O"
msgid "The linearization of B can be computed as::"
msgid "L[B] = B + merge(DO, EO, DE)"
"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::"
msgid "L[B] =  B D E O"
msgid "Using the same procedure one finds::"
"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"
msgid "Now we can compute::"
"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"
"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."
"I leave as an exercise for the reader to compute the linearization for my "
"second example:"
"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:"
"                          ---\n"
"Level 3                  | O |\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"
"Level 0                0 | A |\n"
"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."
"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:"
"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:"
"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"
"However, it is impossible to compute the linearization for a class C that "
"inherits from A and B::"
"L[C] = C + merge(AXYO, BYXO, AB)\n"
"     = C + A + merge(XYO, BYXO, B)\n"
"     = C + A + B + merge(XYO, YXO)"
"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."
msgid "Bad Method Resolution Orders"
"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."
"It is easier to start with the local precedence ordering.  Consider the "
"following example:"
msgid "with inheritance diagram"
"             O\n"
"             |\n"
"(buy spam)   F\n"
"             | \\\n"
"             | E   (buy eggs)\n"
"             | /\n"
"             G\n"
"      (buy eggs or spam ?)"
"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"
"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::"
msgid "L[G,P22]= G E F object   # F *follows* E"
"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:"
"In this case the MRO is GFEF and the local precedence ordering is preserved."
"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::"
msgid "merge(FO,EFO,FE)"
"cannot be computed, because F is in the tail of EFO and E is in the tail of "
"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."
"           O\n"
"           |\n"
"           F (spam)\n"
"         / |\n"
"(eggs)   E |\n"
"         \\ |\n"
"           G\n"
"             (eggs, no doubt)"
"Python 2.3 forces the programmer to write good hierarchies (or, at least, "
"less error-prone ones)."
"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:"
"Python 2.2 (both for classic classes and new style classes) in this "
"situation, would not raise any exception."
"Finally, I would like to point out two lessons we have learned from this "
"despite the name, the MRO determines the resolution order of attributes, not "
"only of methods;"
"the default food for Pythonistas is spam !  (but you already knew that ;-)"
"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."
"To prove that the MRO for classic classes is non-monotonic is rather "
"trivial, it is enough to look at the diamond diagram:"
" /   \\\n"
"A     B\n"
" \\   /\n"
msgid "One easily discerns the inconsistency::"
"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!"
"On the other hand, there are no problems with the Python 2.2 and 2.3 MROs, "
"they give both::"
msgid "L[D] = D A B C"
"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."
"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:"
"Here are the linearizations according to the C3 MRO (the reader should "
"verify these linearizations as an exercise and draw the inheritance "
"diagram ;-) ::"
"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"
"Python 2.2 gives exactly the same linearizations for A, B, C, D, E, K1, K2 "
"and K3, but a different linearization for Z::"
msgid "L[Z,P22] = Z K1 K3 A K2 D B C E O"
"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."
msgid "The end"
"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 "
"#<mro.py>\n"
"\"\"\"C3 algorithm by Samuele Pedroni (with readability enhanced by me)."
"class __metaclass__(type):\n"
"    \"All classes are metamagically modified to be nicely printed\"\n"
"    __repr__ = lambda cls: cls.__name__\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"
"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"
"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"
"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"
"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"
"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"
"def print_mro(C):\n"
"    print '\\nMRO[%s]=%s' % (C,mro(C))\n"
"    print '\\nP22 MRO[%s]=%s' % (C,C.mro())\n"
"print_mro(ex_9.Z)\n"
"#</mro.py>"
msgid "That's all folks,"
msgid "enjoy !"
msgid "Resources"
"The thread on python-dev started by Samuele Pedroni: https://mail.python.org/"
"pipermail/python-dev/2002-October/029035.html"
"The paper *A Monotonic Superclass Linearization for Dylan*: https://doi."
"org/10.1145/236337.236343"
"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"
Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

FilesExpand file tree

mro.po

Latest commit

History

mro.po

File metadata and controls
