diff --git a/howto/mro.po b/howto/mro.po index 4b1860b886..ee4b8e836d 100644 --- a/howto/mro.po +++ b/howto/mro.po @@ -1,6 +1,7 @@ # Copyright (C) 2001-2024, Python Software Foundation # This file is distributed under the same license as the Python package. -# FIRST AUTHOR , YEAR. +# Translators: +# Matt Wang , 2024 # #, fuzzy msgid "" @@ -9,7 +10,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2024-09-27 00:14+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME \n" +"Last-Translator: Matt Wang \n" "Language-Team: Chinese - TAIWAN (https://github.com/python/python-docs-zh-" "tw)\n" "Language: zh_TW\n" @@ -19,24 +20,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 `__." -msgstr "" +msgstr "作者:`Michele Simionato `__。" #: ../../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 +49,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 +83,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 +110,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 +129,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 +148,33 @@ 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 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 +182,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 +195,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,24 +211,35 @@ 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:120 msgid "" @@ -206,108 +266,132 @@ msgstr "" " ?" #: ../../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:148 msgid "C1 C2 ... CN" msgstr "C1 C2 ... CN" #: ../../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:154 msgid "head = C1" msgstr "head = C1" #: ../../howto/mro.rst:156 +#, fuzzy msgid "whereas the *tail* is the rest of the list::" -msgstr "" +msgstr "而 *tail* 是清單的其餘部分: ::" #: ../../howto/mro.rst:158 msgid "tail = C2 ... CN." msgstr "tail = C2 ... CN." #: ../../howto/mro.rst:160 +#, fuzzy msgid "I shall also use the notation::" -msgstr "" +msgstr "我也會使用符號: ::" #: ../../howto/mro.rst:162 msgid "C + (C1 C2 ... CN) = C C1 C2 ... CN" msgstr "C + (C1 C2 ... CN) = C C1 C2 ... CN" #: ../../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:178 msgid "L[C(B1 ... BN)] = C + merge(L[B1] ... L[BN], B1 ... BN)" msgstr "L[C(B1 ... BN)] = C + merge(L[B1] ... L[BN], B1 ... BN)" #: ../../howto/mro.rst:180 +#, fuzzy msgid "" "In particular, if C is the ``object`` class, which has no parents, the " "linearization is trivial::" msgstr "" +"特別是,如果 C 是沒有父類別的 ``object`` 類別,則線性化是微不足道的: ::" #: ../../howto/mro.rst:183 msgid "L[object] = object." msgstr "L[object] = 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 " @@ -317,42 +401,56 @@ 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:205 msgid "L[C(B)] = C + merge(L[B],B) = C + L[B]" msgstr "L[C(B)] = C + merge(L[B],B) = C + L[B]" #: ../../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:226 msgid "" @@ -380,8 +478,9 @@ msgid "" 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:253 msgid "" @@ -392,14 +491,16 @@ msgid "" msgstr "" #: ../../howto/mro.rst:258 +#, fuzzy msgid "The linearization of B can be computed as::" -msgstr "" +msgstr "B 的線性化可以計算為: ::" #: ../../howto/mro.rst:260 msgid "L[B] = B + merge(DO, EO, DE)" msgstr "L[B] = B + merge(DO, EO, DE)" #: ../../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 " @@ -407,14 +508,19 @@ 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:268 msgid "L[B] = B D E O" msgstr "L[B] = B D E O" #: ../../howto/mro.rst:270 +#, fuzzy msgid "Using the same procedure one finds::" -msgstr "" +msgstr "使用相同的過程可以發現: ::" #: ../../howto/mro.rst:272 msgid "" @@ -430,7 +536,7 @@ msgstr "" #: ../../howto/mro.rst:277 msgid "Now we can compute::" -msgstr "" +msgstr "現在我們可以計算出: ::" #: ../../howto/mro.rst:279 msgid "" @@ -451,25 +557,32 @@ msgstr "" " = A B C D E F O" #: ../../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:307 msgid "" @@ -518,25 +631,34 @@ msgstr "" " ---" #: ../../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 :meth:`~type.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:349 msgid "" @@ -553,10 +675,11 @@ msgstr "" "L[B] = B Y X O" #: ../../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:360 msgid "" @@ -569,34 +692,43 @@ msgstr "" " = C + A + B + merge(XYO, YXO)" #: ../../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:386 msgid "" @@ -612,24 +744,32 @@ msgid "" 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:411 msgid "L[G,P22]= G E F object # F *follows* E" msgstr "L[G,P22]= G E F object # F *follows* E" #: ../../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 " @@ -637,13 +777,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 " @@ -651,23 +796,30 @@ 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:435 msgid "merge(FO,EFO,FE)" msgstr "merge(FO,EFO,FE)" #: ../../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:444 msgid "" @@ -682,53 +834,67 @@ msgid "" msgstr "" #: ../../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:489 msgid "" @@ -749,8 +915,9 @@ msgstr "" " D" #: ../../howto/mro.rst:500 +#, fuzzy msgid "One easily discerns the inconsistency::" -msgstr "" +msgstr "人們可以很容易地辨別出這種不一致: ::" #: ../../howto/mro.rst:502 msgid "" @@ -759,36 +926,47 @@ msgid "" 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:508 msgid "L[D] = D A B C" msgstr "L[D] = D A B C" #: ../../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:534 msgid "" @@ -813,16 +991,20 @@ msgstr "" "L[Z] = Z K1 K2 K3 D A B C E O" #: ../../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:547 msgid "L[Z,P22] = Z K1 K3 A K2 D B C E O" msgstr "L[Z,P22] = Z K1 K3 A K2 D B C E O" #: ../../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 " @@ -834,12 +1016,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 " @@ -852,6 +1041,12 @@ 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:574 msgid "" @@ -940,32 +1135,45 @@ msgid "" msgstr "" #: ../../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"