diff --git a/howto/mro.po b/howto/mro.po new file mode 100644 index 000000000..529d575c1 --- /dev/null +++ b/howto/mro.po @@ -0,0 +1,604 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2001-2024, Python Software Foundation +# This file is distributed under the same license as the Python package. +# FIRST AUTHOR , YEAR. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Python 3.12\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2024-05-01 00:16+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\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: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: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:156 +msgid "whereas the *tail* is the rest of the list::" +msgstr "" + +#: howto/mro.rst:160 +msgid "I shall also use the notation::" +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:180 +msgid "" +"In particular, if C is the ``object`` class, which has no parents, the " +"linearization is trivial::" +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: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:251 +msgid "The linearizations of O,D,E and F are trivial::" +msgstr "" + +#: howto/mro.rst:258 +msgid "The linearization of B can be computed as::" +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:270 +msgid "Using the same procedure one finds::" +msgstr "" + +#: howto/mro.rst:277 +msgid "Now we can compute::" +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: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 .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:357 +msgid "" +"However, it is impossible to compute the linearization for a class C that " +"inherits from A and B::" +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: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." +"rembermer2buy* 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: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 viceversa. 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: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: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:500 +msgid "One easily discerns the inconsistency::" +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: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: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: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: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 ""