From dfe304d4b749d0e4df571361bc683f2c99959f07 Mon Sep 17 00:00:00 2001
From: Matt Wang <mattwang44@gmail.com>
Date: Sat, 31 Aug 2024 02:46:05 +0800
Subject: [PATCH] wip

---
 howto/mro.po | 296 +++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 251 insertions(+), 45 deletions(-)

diff --git a/howto/mro.po b/howto/mro.po
index 73af9a2376..b5f2639ef6 100644
--- a/howto/mro.po
+++ b/howto/mro.po
@@ -1,4 +1,3 @@
-# SOME DESCRIPTIVE TITLE.
 # Copyright (C) 2001-2024, Python Software Foundation
 # This file is distributed under the same license as the Python package.
 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
@@ -19,24 +18,28 @@ msgstr ""
 
 #: ../../howto/mro.rst:4
 msgid "The Python 2.3 Method Resolution Order"
-msgstr ""
+msgstr "Python 2.3 方法解析順序"
 
 #: ../../howto/mro.rst:8
+#, fuzzy
 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 ""
+"這是一份歷史文件，作為官方文件的附錄。這裡討論的方法解析順序是在 Python 2.3 "
+"中「引入」的，但它仍在更高版本中使用——包括 Python 3。"
 
 #: ../../howto/mro.rst:13
 msgid "By `Michele Simionato <https://www.phyast.pitt.edu/~micheles/>`__."
-msgstr ""
+msgstr "作者：`Michele Simionato <https://www.phyast.pitt.edu/~micheles/>`__。"
 
 #: ../../howto/mro.rst:0
 msgid "Abstract"
 msgstr "摘要"
 
 #: ../../howto/mro.rst:17
+#, fuzzy
 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 "
@@ -44,24 +47,32 @@ msgid ""
 "not aware of other publicly available documents with the same scope, "
 "therefore it should be useful.*"
 msgstr ""
+"*本文件適用於想要了解 Python 2.3 中所使用的 C3 方法解析順序的 Python 程式設計"
+"師。儘管它不適合新手，但它具有許多教學意義，並提供了許多範例。我不知道其他具"
+"有相同範圍的公開文件，因此它應該有用。"
 
 #: ../../howto/mro.rst:23
 msgid "Disclaimer:"
-msgstr ""
+msgstr "免責聲明："
 
 #: ../../howto/mro.rst:25
+#, fuzzy
 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 ""
+"*我根據 Python 2.3 許可證將本文件捐贈給 Python 軟體基金會。像往常一樣，在這些"
+"情況下，我警告讀者以下內容*應該是正確的，但我不提供任何保證。使用它需要你自擔"
+"風險和危險！"
 
 #: ../../howto/mro.rst:30
 msgid "Acknowledgments:"
-msgstr ""
+msgstr "致謝："
 
 #: ../../howto/mro.rst:32
+#, fuzzy
 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 "
@@ -70,16 +81,22 @@ msgid ""
 "Rossum who enthusiastically added this document to the official Python 2.3 "
 "home-page.*"
 msgstr ""
+"*Python 郵件清單中所有向我發送支援的人。Paul Foley 指出了各種不精確之處，並讓"
+"我加入有關本地優先順序的部分。David Goodger 尋求有關 reStructuredText 格式設"
+"定的協助。David Mertz 尋求編輯協助。最後，Guido van Rossum 熱情地將此文件新增"
+"到官方 Python 2.3 主頁。"
 
 #: ../../howto/mro.rst:40
+#, fuzzy
 msgid "The beginning"
-msgstr ""
+msgstr "開始"
 
 #: ../../howto/mro.rst:42
 msgid "*Felix qui potuit rerum cognoscere causas* -- Virgilius"
-msgstr ""
+msgstr "*Felix qui potuit rerum cognoscere causas* -- Virgilius"
 
 #: ../../howto/mro.rst:44
+#, fuzzy
 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 "
@@ -91,8 +108,15 @@ msgid ""
 "readable discussion of the C3 algorithm for Pythonistas who want to "
 "understand the reasons for the change."
 msgstr ""
+"一切都始於 Samuele Pedroni 在 Python 開發郵件清單 [#]_ 上發表的一篇文章。"
+"Samuele 在他的文章中表明，Python 2.2 方法解析順序不是單調的，他建議用 C3 方法"
+"解析順序取代它。Guido 同意他的觀點，因此現在 Python 2.3 使用 C3。C3 方法本身"
+"與 Python 無關，因為它是由 Dylan 的工作人員發明的，並且在一篇針對 lispers "
+"[#]_ 的論文中對其進行了描述。本文對 C3 演演算法進行了（希望）可讀的討論，供那"
+"些想要了解更改原因的 Python 愛好者參考。"
 
 #: ../../howto/mro.rst:55
+#, fuzzy
 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* "
@@ -103,12 +127,18 @@ msgid ""
 "differs from the Python 2.2 method resolution order are so rare that no real "
 "breaking of code is expected.  Therefore:"
 msgstr ""
+"首先，讓我指出，我要說的內容僅適用於 Python 2.2 中引入的「新樣式類別」：「經"
+"典類別」保持其舊的方法解析順序，深度優先，然後從左到右。因此，經典類別不會破"
+"壞舊程式碼；即使原則上可能會破壞 Python 2.2 新樣式類別的程式碼，但實際上，C3 "
+"解析順序與 Python 2.2 方法解析順序不同的情況非常罕見，因此不會出現真正的程式"
+"碼破壞。所以："
 
 #: ../../howto/mro.rst:64
 msgid "*Don't be scared!*"
-msgstr ""
+msgstr "*別怕！*"
 
 #: ../../howto/mro.rst:66
+#, fuzzy
 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 "
@@ -116,24 +146,34 @@ msgid ""
 "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 ""
+"此外，除非你強烈使用多重繼承並且你具有重要的層次結構，否則你不需要了解 C3 演"
+"演算法，並且可以輕鬆跳過本文。另一方面，如果你確實想了解多重繼承是如何運作"
+"的，那麼本文適合你。好消息是事情並不像你想像的那麼複雜。"
 
 #: ../../howto/mro.rst:73
+#, fuzzy
 msgid "Let me begin with some basic definitions."
-msgstr ""
+msgstr "讓我從一些基本定義開始。"
 
 #: ../../howto/mro.rst:75
+#, fuzzy
 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 ""
+"給定一個複雜的多重繼承層次結構中的類別 C，指定方法被重寫的順序（即指定 C 的祖"
+"先的順序）是一項艱鉅的任務。"
 
 #: ../../howto/mro.rst:79
+#, fuzzy
 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 ""
+"類別 C 的祖先清單（包括類別本身）從最近的祖先到最遠的祖先排序，稱為類別優先列"
+"表或 C 的\\ *線性化 (linearization)*。"
 
 #: ../../howto/mro.rst:83
 msgid ""
@@ -141,8 +181,11 @@ msgid ""
 "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 ""
+"*方法解析順序* (Method Resolution Order, MRO) 是建構線性化的一組規則。在 "
+"Python 文獻中，習慣用語「C 的 MRO」也是 C 類別線性化的同義詞。"
 
 #: ../../howto/mro.rst:88
+#, fuzzy
 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 "
@@ -151,8 +194,13 @@ msgid ""
 "it is more difficult to construct a linearization that respects *local "
 "precedence ordering* and *monotonicity*."
 msgstr ""
+"例如，在單一繼承層次結構的情況下，如果 C 是 C1 的子類別，且 C1 是 C2 的子類"
+"別，那麼 C 的線性化就是列表 [C, C1 , C2]。然而，對於多重繼承層次結構，線性化"
+"的建構更加麻煩，因為建構尊重\\ *局部優先順序 (local precedence ordering)*\\ "
+"和\\ *單調性 (monotonicity)*\\ 的線性化更加困難。"
 
 #: ../../howto/mro.rst:96
+#, fuzzy
 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 "
@@ -162,104 +210,138 @@ msgid ""
 "potentially introducing very subtle bugs.  Examples where this happens will "
 "be shown later."
 msgstr ""
+"稍後我將討論局部優先順序，但我可以在這裡給出單調性的定義。當滿足以下條件時，"
+"MRO 是單調的：*如果在 C 的線性化中 C1 領先於 C2，則在 C 的任何子類別的線性化"
+"中 C1 領先於 C2*。否則，派生新類別的無害操作可能會改變方法的解析順序，從而可"
+"能引入非常微妙的錯誤。稍後將顯示發生這種情況的範例。"
 
 #: ../../howto/mro.rst:104
+#, fuzzy
 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
+#, fuzzy
 msgid "Here I give an example of this situation. Consider the hierarchy"
-msgstr ""
+msgstr "這裡我舉一個例子來說明這種情況。考慮層次結構"
 
 #: ../../howto/mro.rst:116
+#, fuzzy
 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 ""
+"可以用下面的繼承圖來表示，其中我用 O 表示“object”類，它是新樣式類的任何層次結"
+"構的開始："
 
 #: ../../howto/mro.rst:133
+#, fuzzy
 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 ""
+"在這種情況下，不可能從 A 和 B 派生出新的類別 C，因為在 A 中 X 在 Y 之前，但"
+"在 B 中 Y 在 X 之前，因此 C 中的方法解析順序將不明確。"
 
 #: ../../howto/mro.rst:137
+#, fuzzy
 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 ""
+"Python 2.3 在這種情況下引發了一個例外（TypeError：基數 Y、X 之間的 MRO 衝"
+"突），禁止天真的程式設計師建立不明確的層次結構。  相反，Python 2.2 不會引發例"
+"外，而是選擇*暫時* 排序（在本例中為 CABXYO）。"
 
 #: ../../howto/mro.rst:143
+#, fuzzy
 msgid "The C3 Method Resolution Order"
-msgstr ""
+msgstr "C3 方法解析順序"
 
 #: ../../howto/mro.rst:145
+#, fuzzy
 msgid ""
 "Let me introduce a few simple notations which will be useful for the "
 "following discussion.  I will use the shortcut notation::"
-msgstr ""
+msgstr "讓我介紹一些對下面的討論有用的簡單符號。  我將使用快捷符號::"
 
 #: ../../howto/mro.rst:150
+#, fuzzy
 msgid "to indicate the list of classes [C1, C2, ... , CN]."
-msgstr ""
+msgstr "指示類別清單 [C1, C2, ... , CN]。"
 
 #: ../../howto/mro.rst:152
+#, fuzzy
 msgid "The *head* of the list is its first element::"
-msgstr ""
+msgstr "列表的 *head* 是它的第一個元素： ::"
 
 #: ../../howto/mro.rst:156
+#, fuzzy
 msgid "whereas the *tail* is the rest of the list::"
-msgstr ""
+msgstr "而 *tail* 是清單的其餘部分： ::"
 
 #: ../../howto/mro.rst:160
+#, fuzzy
 msgid "I shall also use the notation::"
-msgstr ""
+msgstr "我也會使用符號： ::"
 
 #: ../../howto/mro.rst:164
+#, fuzzy
 msgid "to denote the sum of the lists [C] + [C1, C2, ... ,CN]."
-msgstr ""
+msgstr "表示列表 [C] + [C1, C2, ... ,CN] 的總和。"
 
 #: ../../howto/mro.rst:166
+#, fuzzy
 msgid "Now I can explain how the MRO works in Python 2.3."
-msgstr ""
+msgstr "現在我可以解釋 MRO 在 Python 2.3 中是如何運作的。"
 
 #: ../../howto/mro.rst:168
+#, fuzzy
 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 ""
+"考慮多重繼承層次結構中的類別 C，其中 C 繼承自基底類別 B1, B2, ...  , BN。我們"
+"要計算 C 類別的線性化 L[C]。"
 
 #: ../../howto/mro.rst:173
+#, fuzzy
 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 ""
+msgstr "*C 的線性化是 C 的總和加上父級線性化和父級列表的合併。"
 
 #: ../../howto/mro.rst:176
+#, fuzzy
 msgid "In symbolic notation::"
-msgstr ""
+msgstr "用符號表示： ::"
 
 #: ../../howto/mro.rst:180
+#, fuzzy
 msgid ""
 "In particular, if C is the ``object`` class, which has no parents, the "
 "linearization is trivial::"
-msgstr ""
+msgstr "特別是，如果 C 是沒有父類的 ``object`` 類別，則線性化是微不足道的： ::"
 
 #: ../../howto/mro.rst:185
+#, fuzzy
 msgid ""
 "However, in general one has to compute the merge according to the following "
 "prescription:"
-msgstr ""
+msgstr "然而，通常必須根據以下規定來計算合併："
 
 #: ../../howto/mro.rst:188
+#, fuzzy
 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 "
@@ -269,48 +351,65 @@ msgid ""
 "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 ""
+"*取第一個清單的頭部，即L[B1][0]；如果這個頭不在任何其他列表的尾部，則將其新增"
+"到 C 的線性化中，並將其從合併的列表中刪除，否則請查看下一個列表的頭並取出它，"
+"如果它是一個好頭。然後重複操作，直到所有的類別都被移除或無法找到好的頭。在這"
+"種情況下，不可能建構合併，Python 2.3 將拒絕建立類別 C 並引發例外。"
 
 #: ../../howto/mro.rst:197
+#, fuzzy
 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
+#, fuzzy
 msgid ""
 "The computation of the merge is trivial if C has only one parent (single "
 "inheritance); in this case::"
 msgstr ""
+"如果 C 只有一個父級（單繼承），則合併的計算是微不足道的；在這種情況下： ::"
 
 #: ../../howto/mro.rst:207
+#, fuzzy
 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
+#, fuzzy
 msgid "First example. Consider the following hierarchy:"
-msgstr ""
+msgstr "第一個例子。參考以下層次結構："
 
 #: ../../howto/mro.rst:224
+#, fuzzy
 msgid "In this case the inheritance graph can be drawn as:"
-msgstr ""
+msgstr "在這種情況下，繼承圖可以繪製為："
 
 #: ../../howto/mro.rst:251
+#, fuzzy
 msgid "The linearizations of O,D,E and F are trivial::"
-msgstr ""
+msgstr "O、D、E 和 F 的線性化很簡單： ::"
 
 #: ../../howto/mro.rst:258
+#, fuzzy
 msgid "The linearization of B can be computed as::"
-msgstr ""
+msgstr "B 的線性化可以計算為： ::"
 
 #: ../../howto/mro.rst:262
+#, fuzzy
 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 "
@@ -318,108 +417,147 @@ msgid ""
 "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 ""
+"我們看到 D 是一個好頭，因此我們接受它並簡化為計算「merge(O,EO,E)」。  現在 O "
+"不是一個好的頭，因為它位於序列 EO 的尾部。在這種情況下，規則規定我們必須跳到"
+"下一個序列。那我們看到E是一個好頭；我們接受它並簡化為計算“merge(O,O)”，它給"
+"出 O。因此： ::"
 
 #: ../../howto/mro.rst:270
+#, fuzzy
 msgid "Using the same procedure one finds::"
-msgstr ""
+msgstr "使用相同的過程可以發現： ::"
 
 #: ../../howto/mro.rst:277
 msgid "Now we can compute::"
-msgstr ""
+msgstr "現在我們可以計算出： ::"
 
 #: ../../howto/mro.rst:287
+#, fuzzy
 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
+#, fuzzy
 msgid ""
 "I leave as an exercise for the reader to compute the linearization for my "
 "second example:"
-msgstr ""
+msgstr "我留給讀者當作練習來計算第二個範例的線性化："
 
 #: ../../howto/mro.rst:303
+#, fuzzy
 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 ""
+"與上一個範例的唯一差異是更改 B(D,E) --> B(E,D);然而，即使這樣一點點修改也會完"
+"全改變層次結構的順序："
 
 #: ../../howto/mro.rst:332
+#, fuzzy
 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 ""
+"請注意，位於層次結構第二層的類別 E 位於位於層次結構第一層的類別 C 之前，即 E "
+"比 C 更專業，即使它位於更高的層級。"
 
 #: ../../howto/mro.rst:336
+#, fuzzy
 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 ""
+"懶惰的程式設計師可以直接從 Python 2.2 取得 MRO，因為在這種情況下它與 Python "
+"2.3 線性化一致。呼叫 A 類別的 .mro() 方法就足夠了："
 
 #: ../../howto/mro.rst:345
+#, fuzzy
 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 ""
+"最後，讓我考慮第一節中討論的例子，其中涉及嚴重的順序分歧。在這種情況下，計算 "
+"O、X、Y、A 和 B 的線性化非常簡單："
 
 #: ../../howto/mro.rst:357
+#, fuzzy
 msgid ""
 "However, it is impossible to compute the linearization for a class C that "
 "inherits from A and B::"
-msgstr ""
+msgstr "然而，不可能計算繼承自 A 和 B 的類別 C 的線性化："
 
 #: ../../howto/mro.rst:364
+#, fuzzy
 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 ""
+"此時我們無法合併清單 XYO 和 YXO，因為 X 位於 YXO 的尾部，而 Y 位於 XYO 的尾"
+"部：因此沒有好的頭並且 C3 演演算法停止。Python 2.3 引發錯誤並拒絕建立 C 類"
+"別。"
 
 #: ../../howto/mro.rst:370
 msgid "Bad Method Resolution Orders"
-msgstr ""
+msgstr "不良的方法解析順序"
 
 #: ../../howto/mro.rst:372
+#, fuzzy
 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 ""
+"當 MRO 破壞了局部優先順序和單調性等基本屬性時，它就是「壞」的。在本節中，我將"
+"展示 Python 2.2 中經典類別的 MRO 和新樣式類別的 MRO 都很糟糕。"
 
 #: ../../howto/mro.rst:377
+#, fuzzy
 msgid ""
 "It is easier to start with the local precedence ordering.  Consider the "
 "following example:"
-msgstr ""
+msgstr "從本地優先順序開始會更容易。考慮以下範例："
 
 #: ../../howto/mro.rst:384
+#, fuzzy
 msgid "with inheritance diagram"
-msgstr ""
+msgstr "附有繼承圖"
 
 #: ../../howto/mro.rst:399
+#, fuzzy
 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 ""
+"我們看到類別 G 繼承自 F 和 E，其中 F *在* E 之前：因此我們期望屬性 *G."
+"remember2buy* 由 *F.rembermer2buy* 繼承，而不是由 *E.remember2buy* 繼承：儘管"
+"如此，Python 2.2給出"
 
 #: ../../howto/mro.rst:407
+#, fuzzy
 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 ""
+"這是對局部優先順序的破壞，因為局部優先列表（即 G 的父級列表）中的順序未保留"
+"在 G 的 Python 2.2 線性化中： ::"
 
 #: ../../howto/mro.rst:413
+#, fuzzy
 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 "
@@ -427,13 +565,18 @@ msgid ""
 "quite non-intuitive and error prone.  This is particularly true since it is "
 "a different from old style classes:"
 msgstr ""
+"有人可能會說，在 Python 2.2 線性化中 F 跟隨 E 的原因是 F 不如 E 專業化，因為 "
+"F 是 E 的超類別；然而，破壞本地優先順序是相當不直觀且容易出錯的。這是特別正確"
+"的，因為它與舊式類別不同："
 
 #: ../../howto/mro.rst:425
+#, fuzzy
 msgid ""
 "In this case the MRO is GFEF and the local precedence ordering is preserved."
-msgstr ""
+msgstr "在這種情況下，MRO 是 GFEF，並且保留本地優先順序。"
 
 #: ../../howto/mro.rst:428
+#, fuzzy
 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 "
@@ -441,108 +584,145 @@ msgid ""
 "effectively stopping the programmer from generating ambiguous hierarchies.  "
 "The reason for that is that the C3 algorithm fails when the merge::"
 msgstr ""
+"作為一般規則，應該避免像前一個這樣的層次結構，因為尚不清楚 F 是否應該覆蓋 E "
+"或反之亦然。 Python 2.3 透過在建立類別 G 時引發例外來解決歧義性，有效地阻止程"
+"式設計師產生歧義的層次結構。原因是 C3 演演算法在合併時失敗： ::"
 
 #: ../../howto/mro.rst:437
+#, fuzzy
 msgid ""
 "cannot be computed, because F is in the tail of EFO and E is in the tail of "
 "FE."
-msgstr ""
+msgstr "無法計算，因為 F 在 EFO 的尾部，E 在 FE 的尾部。"
 
 #: ../../howto/mro.rst:440
+#, fuzzy
 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 ""
+"真正的解決方案是設計一個明確的層次結構，即從 E 和 F（更具體的第一個）導出 G，"
+"而不是從 F 和 E 導出；在這種情況下，MRO 毫無疑問就是 GEF。"
 
 #: ../../howto/mro.rst:456
+#, fuzzy
 msgid ""
 "Python 2.3 forces the programmer to write good hierarchies (or, at least, "
 "less error-prone ones)."
 msgstr ""
+"Python 2.3 迫使程式設計師寫出良好的層次結構（或至少是不容易出錯的層次結構）。"
 
 #: ../../howto/mro.rst:459
+#, fuzzy
 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 ""
+"在相關說明中，讓我指出 Python 2.3 演演算法足夠聰明，可以識別明顯的錯誤，例如"
+"父級列表中的類別重複："
 
 #: ../../howto/mro.rst:469
+#, fuzzy
 msgid ""
 "Python 2.2 (both for classic classes and new style classes) in this "
 "situation, would not raise any exception."
 msgstr ""
+"Python 2.2（無論是經典類別還是新式類別）在這種情況下都不會引發任何例外。"
 
 #: ../../howto/mro.rst:472
+#, fuzzy
 msgid ""
 "Finally, I would like to point out two lessons we have learned from this "
 "example:"
-msgstr ""
+msgstr "最後，我想指出我們從這個例子中學到的兩個教訓："
 
 #: ../../howto/mro.rst:475
+#, fuzzy
 msgid ""
 "despite the name, the MRO determines the resolution order of attributes, not "
 "only of methods;"
-msgstr ""
+msgstr "儘管名稱如此，MRO 決定了屬性的解析順序，而不僅僅是方法的解析順序；"
 
 #: ../../howto/mro.rst:478
+#, fuzzy
 msgid ""
 "the default food for Pythonistas is spam !  (but you already knew that ;-)"
-msgstr ""
+msgstr "Pythonista 的預設食物是垃圾郵件！（但你已經知道了；-）"
 
 #: ../../howto/mro.rst:481
+#, fuzzy
 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 ""
+"討論完局部優先順序問題後，現在讓我考慮單調性問題。我的目標是表明經典類別的 "
+"MRO 和 Python 2.2 新樣式類別的 MRO 都不是單調的。"
 
 #: ../../howto/mro.rst:486
+#, fuzzy
 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 ""
+msgstr "要證明經典類的 MRO 是非單調的相當簡單，看一下菱形圖就夠了："
 
 #: ../../howto/mro.rst:500
+#, fuzzy
 msgid "One easily discerns the inconsistency::"
-msgstr ""
+msgstr "人們很容易辨別出這種不一致： ::"
 
 #: ../../howto/mro.rst:505
+#, fuzzy
 msgid ""
 "On the other hand, there are no problems with the Python 2.2 and 2.3 MROs, "
 "they give both::"
-msgstr ""
+msgstr "另一方面，Python 2.2 和 2.3 MRO 沒有問題，它們同時提供： ::"
 
 #: ../../howto/mro.rst:510
+#, fuzzy
 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 ""
+"Guido 在他的文章 [#]_ 中指出，經典的 MRO 在實踐中並沒有那麼糟糕，因為人們通常"
+"可以避免經典類別的鑽石。但是所有新樣式類別都繼承自“object”，因此菱形是不可避"
+"免的，並且每個多重繼承圖中都會出現不一致。"
 
 #: ../../howto/mro.rst:516
+#, fuzzy
 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 ""
+"Python 2.2 的 MRO 讓打破單調變得困難，但並非不可能。以下範例最初由 Samuele "
+"Pedroni 提供，顯示 Python 2.2 的 MRO 是非單調的："
 
 #: ../../howto/mro.rst:530
+#, fuzzy
 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 ""
+"以下是根據 C3 MRO 的線性化（讀者應該驗證這些線性化作為練習並繪製繼承"
+"圖;-）： ::"
 
 #: ../../howto/mro.rst:544
+#, fuzzy
 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 ""
+"Python 2.2 為 A、B、C、D、E、K1、K2 和 K3 提供了完全相同的線性化，但為 Z 提供"
+"了不同的線性化： ::"
 
 #: ../../howto/mro.rst:549
+#, fuzzy
 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 "
@@ -554,12 +734,19 @@ msgid ""
 "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 ""
+"很明顯，這種線性化是“錯誤的”，因為A 在D 之前，而在K3 的線性化中，A 在D 之後。"
+"但在Z 中，仍然是K3的子類別，A派生的方法覆蓋D派生的方法！這是違反單調性的。此"
+"外，Z 的Python 2.2 線性化也與局部優先權順序不一致，因為類Z 的局部優先權列表是"
+"[K1, K2, K3]（K2 在K3 之前），而在Z 的線性化中，K2 *跟隨* K3 。這些問題解釋了"
+"為什麼 2.2 規則被 C3 規則所取代。"
 
 #: ../../howto/mro.rst:561
+#, fuzzy
 msgid "The end"
-msgstr ""
+msgstr "結束"
 
 #: ../../howto/mro.rst:563
+#, fuzzy
 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 "
@@ -572,34 +759,53 @@ msgid ""
 "the last line to play with the various examples I have discussed in this "
 "paper.::"
 msgstr ""
+"本節是為不耐煩的讀者準備的，他們跳過了前面的所有部分並立即跳到了最後。本節也"
+"適合懶惰的程式設計師，他們不想鍛鍊她/他的大腦。最後，它是為那些傲慢的程式設計"
+"師準備的，否則他/她就不會閱讀關於多重繼承層次結構中 C3 方法解析順序的論"
+"文；-) 這三個優點放在一起（而不是單獨）值得獎勵：獎品是一個簡短的Python 2.2 "
+"腳本，它允許你計算2.3 MRO，而不會給你的大腦帶來風險。只需更改最後一行即可使用"
+"我在本文中討論的各種範例。 ::"
 
 #: ../../howto/mro.rst:656
+#, fuzzy
 msgid "That's all folks,"
-msgstr ""
+msgstr "這就是大家，"
 
 #: ../../howto/mro.rst:658
+#, fuzzy
 msgid "enjoy !"
-msgstr ""
+msgstr "享受！"
 
 #: ../../howto/mro.rst:662
+#, fuzzy
 msgid "Resources"
-msgstr ""
+msgstr "資源"
 
 #: ../../howto/mro.rst:664
+#, fuzzy
 msgid ""
 "The thread on python-dev started by Samuele Pedroni: https://mail.python.org/"
 "pipermail/python-dev/2002-October/029035.html"
 msgstr ""
+"Samuele Pedroni 發起的 python-dev 主題：https://mail.python.org/pipermail/"
+"python-dev/2002-October/029035.html"
 
 #: ../../howto/mro.rst:667
+#, fuzzy
 msgid ""
 "The paper *A Monotonic Superclass Linearization for Dylan*: https://doi."
 "org/10.1145/236337.236343"
 msgstr ""
+"論文 *A Monotonic Superclass Linearization for Dylan*: https://doi."
+"org/10.1145/236337.236343"
 
 #: ../../howto/mro.rst:670
+#, fuzzy
 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 ""
+"Guido van Rossum 的文章，*統一 Python 2.2 中的型別和類別*：https://web."
+"archive.org/web/20140210194412/http://www.python.org/download/releases/2.2.2/"
+"descrintro"