"Project-Id-Version: Python 3.14\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2026-10-28 04:13+0000\n"

"PO-Revision-Date: 2026-09-15 10:40+0330\n"

"Last-Translator: Sepehr Rasouli <[email protected]>, 2026\n"

"Language-Team: Persian (https://github.com/python/python-docs-fa/)\n"

"Language: fa\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=UTF-8\n"

"Content-Transfer-Encoding: 8bit\n"

"Plural-Forms: nplurals=2; plural=(n > 1);\n"

"X-Generator: Poedit 3.6\n"

msgid "The Python 2.3 Method Resolution Order"

msgstr "ترتیب حل متد در پایتون 2.3"

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 — استفاده می‌شود."

msgid "By `Michele Simionato <https://github.com/micheles>`__."

msgstr "نوشته‌شده توسط `Michele Simionato <https://github.com/micheles>`__."

msgid "Abstract"

msgstr "چکیده"

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 "*این سند برای برنامه‌نویسان پایتون در نظر گرفته شده است که می‌خواهند ترتیب حل متد C3 (C3 Method Resolution Order) را که در پایتون 2.3 استفاده می‌شود، درک کنند. اگرچه این سند برای تازه‌کاران در نظر گرفته نشده است، اما با مثال‌های حل‌شده‌ی متعدد، کاملاً آموزشی است. من از اسناد دیگری که به‌صورت عمومی در دسترس باشند و همان محدوده را داشته باشند، آگاه نیستم؛ بنابراین باید مفید باشد.*"

msgid "Disclaimer:"

msgstr "سلب مسئولیت:"

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 به بنیاد نرم‌افزار پایتون اهدا می‌کنم. همان‌طور که در این شرایط معمول است، به شما، خواننده، هشدار می‌دهم که آنچه در ادامه می‌آید* باید *صحیح باشد، اما هیچ ضمانتی نمی‌دهم. با مسئولیت و خطر خودتان از آن استفاده کنید!*"

msgid "Acknowledgments:"

msgstr "سپاسگزاری‌ها:"

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 "*همه‌ی افراد فهرست پستی پایتون که حمایت خود را برایم فرستادند. Paul Foley که بی‌دقتی‌های مختلفی را گوشزد کرد و مرا بر آن داشت تا بخش مربوط به ترتیب اولویت محلی را اضافه کنم. David Goodger برای کمک در قالب‌بندی در reStructuredText. David Mertz برای کمک در ویرایش. در نهایت، Guido van Rossum که با اشتیاق این سند را به صفحه‌ی اصلی رسمی پایتون 2.3 افزود.*"

msgid "The beginning"

msgstr "آغاز"

msgid "*Felix qui potuit rerum cognoscere causas* -- Virgilius"

msgstr "*خوشبخت کسی است که توانسته است علل چیزها را بشناسد* -- ویرژیل"

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 "همه‌چیز با پیامی از Samuele Pedroni در فهرست ایمیلی توسعه پایتون آغاز شد [#]_. در پیام خود، Samuele نشان داد که ترتیب حل متد (method resolution order) در پایتون 2.2 یک‌نواخت نیست و پیشنهاد داد آن را با ترتیب حل متد C3 جایگزین کند. Guido با استدلال‌های او موافقت کرد و بنابراین اکنون پایتون 2.3 از C3 استفاده می‌کند. خود روش C3 هیچ ارتباطی به پایتون ندارد، زیرا توسط افرادی که بر روی Dylan کار می‌کردند ابداع شده است و در مقاله‌ای که برای برنامه‌نویسان Lisp در نظر گرفته شده است، توصیف شده است [#]_. مقاله حاضر بحثی (امیدواریم) خواندنی از الگوریتم C3 را برای پایتون‌کاران (Pythonistas) ارائه می‌دهد که می‌خواهند دلایل این تغییر را درک کنند."

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 "پیش از هر چیز، اجازه دهید اشاره کنم که آنچه می‌خواهم بگویم فقط در مورد *کلاس‌های جدید* معرفی‌شده در Python 2.2 صدق می‌کند: *کلاس‌های کلاسیک* ترتیب حل متد قدیمی خود، یعنی عمق‌اول و سپس چپ‌به‌راست، را حفظ می‌کنند. بنابراین، برای کلاس‌های کلاسیک هیچ شکستی در کد قدیمی رخ نمی‌دهد؛ و حتی اگر از نظر اصولی ممکن است شکستی در کد برای کلاس‌های جدید Python 2.2 وجود داشته باشد، در عمل مواردی که ترتیب حل C3 با ترتیب حل متد Python 2.2 تفاوت دارد، آن‌قدر نادر هستند که انتظار نمی‌رود هیچ شکست واقعی در کد رخ دهد. بنابراین:"

msgid "*Don't be scared!*"

msgstr "*نترسید!*"

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 "علاوه بر این، مگر اینکه از وراثت چندگانه به‌طور گسترده استفاده کنید و سلسله‌مراتب‌های غیربدیهی داشته باشید، نیازی نیست الگوریتم C3 را درک کنید و می‌توانید به‌راحتی از این مقاله بگذرید. از سوی دیگر، اگر واقعاً می‌خواهید بدانید که وراثت چندگانه چگونه کار می‌کند، این مقاله برای شماست. خبر خوب این است که مسائل آن‌گونه که ممکن است انتظار داشته باشید، پیچیده نیستند."

msgid "Let me begin with some basic definitions."

msgstr "اجازه دهید با چند تعریف پایه آغاز کنم."

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، کار ساده‌ای نیست."

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 نامیده می‌شود."

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 "*ترتیب حل متد* مجموعه‌ای از قوانین است که خطی‌سازی را تشکیل می‌دهد. در ادبیات پایتون، اصطلاح «the MRO of C» نیز به‌عنوان مترادفی برای خطی‌سازی کلاس C به کار می‌رود."

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 "برای مثال، در مورد سلسله‌مراتب وراثت تکی، اگر C زیرکلاسی از C1 باشد و C1 زیرکلاسی از C2 باشد، آنگاه خطی‌سازی C صرفاً فهرست [C, C1 , C2] است. با این حال، در سلسله‌مراتب‌های وراثت چندگانه، ساختن خطی‌سازی دشوارتر است، زیرا ساختن خطی‌سازی‌ای که *ترتیب تقدم محلی* و *یکنواختی* را رعایت کند، دشوارتر است."

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 "من ترتیب تقدم محلی را بعداً بررسی خواهم کرد، اما می‌توانم تعریف یک‌نواختی را در اینجا ارائه دهم. یک MRO زمانی یک‌نواخت است که شرط زیر برقرار باشد: *اگر C1 در خطی‌سازی C پیش از C2 بیاید، آنگاه C1 در خطی‌سازی هر زیرکلاسی از C پیش از C2 خواهد آمد*. در غیر این صورت، عملیات بی‌ضرر اشتقاق یک کلاس جدید می‌تواند ترتیب حل متدها را تغییر دهد و به‌طور بالقوه باعث ایجاد باگ‌های بسیار ظریف شود. مثال‌هایی که در آن‌ها این اتفاق می‌افتد، بعداً نشان داده خواهند شد."

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 "همه‌ی کلاس‌ها یک خطی‌سازیرا نمی‌پذیرند. در سلسله‌مراتب‌های پیچیده، مواردی وجود دارد که نمی‌توان کلاسی را مشتق کرد، به‌گونه‌ای که خطی‌سازیآن همه‌ی ویژگی‌های مطلوب را رعایت کند."

msgid "Here I give an example of this situation. Consider the hierarchy"

msgstr "در اینجا مثالی از این موقعیت ارائه می‌شود. سلسله‌مراتب را در نظر بگیرید"

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 "که می‌توان آن را با نمودار وراثت زیر نمایش داد، که در آن کلاس ``object`` را با O نشان داده‌ام، کلاسی که آغاز هر سلسله‌مراتبی برای کلاس‌های به‌سبک جدید است:"

msgid ""

msgstr ""

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 "در این حالت، نمی‌توان یک کلاس جدید C را از A و B مشتق کرد، زیرا X در A پیش از Y قرار دارد، اما Y در B پیش از X قرار دارد، بنابراین ترتیب حل متد (method resolution order) در C مبهم خواهد بود."

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 "پایتون 2.3 در این شرایط یک استثنا پرتاب می‌کند (TypeError: MRO conflict among bases Y, X) و برنامه‌نویس ناآگاه را از ایجاد سلسله‌مراتب‌های مبهم بازمی‌دارد. پایتون 2.2 در عوض استثنا پرتاب نمی‌کند، بلکه یک ترتیب *موردی* را انتخاب می‌کند (در این مورد CABXYO)."

msgid "The C3 Method Resolution Order"

msgstr "ترتیب حل متد C3"

msgid "Let me introduce a few simple notations which will be useful for the following discussion. I will use the shortcut notation::"

msgstr "اجازه دهید چند نمادگذاری ساده را معرفی کنم که برای بحث پیش رو مفید خواهند بود. من از نمادگذاری میان‌بر زیر استفاده خواهم کرد::"

msgid "C1 C2 ... CN"

msgstr "C1 C2 ... CN"

msgid "to indicate the list of classes [C1, C2, ... , CN]."

msgstr "برای نشان دادن فهرست کلاس‌ها [C1, C2, ... , CN]."

msgid "The *head* of the list is its first element::"

msgstr "*سر* فهرست، نخستین عنصر آن است::"

msgid "head = C1"

msgstr "head = C1"

msgid "whereas the *tail* is the rest of the list::"

msgstr "در حالی که *دم* باقی‌مانده‌ی فهرست است::"

msgid "tail = C2 ... CN."

msgstr "tail = C2 ... CN."

msgid "I shall also use the notation::"

msgstr "من همچنین از نمادگذاری زیر استفاده خواهم کرد::"

msgid "C + (C1 C2 ... CN) = C C1 C2 ... CN"

msgstr "C + (C1 C2 ... CN) = C C1 C2 ... CN"

msgid "to denote the sum of the lists [C] + [C1, C2, ... ,CN]."

msgstr "برای نشان دادن مجموع فهرست‌های [C] + [C1, C2, ... ,CN]."

msgid "Now I can explain how the MRO works in Python 2.3."

msgstr "اکنون می‌توانم توضیح دهم که MRO در پایتون 2.3 چگونه کار می‌کند."

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] را محاسبه کنیم. قاعده به این صورت است:"

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 "*خطی‌سازی C، حاصل‌جمع C به‌علاوه ادغام خطی‌سازی‌های والدین و فهرست والدین است.*"

msgid "In symbolic notation::"

msgstr "در نمادگذاری نمادین::"

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)"

msgid "In particular, if C is the ``object`` class, which has no parents, the linearization is trivial::"

msgstr "به‌ویژه، اگر C کلاس ``object`` باشد که هیچ والدی ندارد، خطی‌سازی بدیهی است::"

msgid "L[object] = object."

msgstr "L[object] = object."

msgid "However, in general one has to compute the merge according to the following prescription:"

msgstr "با این حال، به‌طور کلی باید ادغام را مطابق دستورالعمل زیر محاسبه کنید:"

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 classes 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 "*سرِ اولین فهرست را بردارید، یعنی L[B1][0]; اگر این سر در دم هیچ‌یک از سایر فهرست‌ها نباشد، آن را به خطی‌سازی C اضافه کنید و از فهرست‌ها در ادغام حذف کنید، در غیر این صورت به سرِ فهرست بعدی نگاه کنید و آن را بردارید، اگر سر خوبی باشد. سپس عملیات را تکرار کنید تا زمانی که تمام کلاس‌ها حذف شوند یا یافتن سرهای خوب غیرممکن شود. در این صورت، ساخت ادغام غیرممکن است، Python 2.3 از ایجاد کلاس C امتناع می‌کند و یک استثنا پرتاب می‌کند.*"

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 "این قاعده تضمین می‌کند که عملیات ادغام، ترتیب را *حفظ می‌کند*، اگر ترتیب قابل حفظ باشد. از سوی دیگر، اگر ترتیب قابل حفظ نباشد (مانند مثال اختلاف جدی در ترتیب که در بالا بحث شد)، آنگاه ادغام قابل محاسبه نیست."

msgid "The computation of the merge is trivial if C has only one parent (single inheritance); in this case::"

msgstr "اگر C تنها یک والد داشته باشد (وراثت تکی)، محاسبه‌ی ادغام بسیار ساده است؛ در این حالت::"

msgid "L[C(B)] = C + merge(L[B],B) = C + L[B]"

msgstr "L[C(B)] = C + merge(L[B],B) = C + L[B]"

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 "با این حال، در حالت وراثت چندگانه، موضوع پیچیده‌تر است و انتظار ندارم شما بتوانید قاعده را بدون چند مثال درک کنید ;-)"

msgid "Examples"

msgstr "مثال‌ها"

msgid "First example. Consider the following hierarchy:"

msgstr "مثال اول. سلسله‌مراتب زیر را در نظر بگیرید:"

msgid "In this case the inheritance graph can be drawn as:"

msgstr "در این حالت می‌توان نمودار وراثت را به این شکل رسم کرد:"

msgid ""

msgstr ""

msgid "The linearizations of O,D,E and F are trivial::"

msgstr "خطی‌سازی‌های O، D، E و F بدیهی هستند::"

msgid ""

msgstr ""

msgid "The linearization of B can be computed as::"

msgstr "خطی‌سازی B را می‌توان به‌صورت زیر محاسبه کرد::"

msgid "L[B] = B + merge(DO, EO, DE)"

msgstr "L[B] = B + merge(DO, EO, DE)"

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 "می‌بینیم که D یک سر مناسب است، بنابراین آن را برمی‌داریم و مسئله به محاسبه‌ی ``merge(O,EO,E)`` تقلیل می‌یابد. اکنون O یک سر مناسب نیست، زیرا در دم دنباله EO قرار دارد. در این حالت، قاعده می‌گوید که باید به دنباله بعدی برویم. سپس می‌بینیم که E یک سر مناسب است؛ آن را برمی‌داریم و مسئله به محاسبه‌ی ``merge(O,O)`` تقلیل می‌یابد که O را می‌دهد. بنابراین::"

msgid "L[B] = B D E O"

msgstr "L[B] = B D E O"

msgid "Using the same procedure one finds::"

msgstr "با استفاده از همان روش، می‌توان یافت::"

msgid ""

msgstr ""

msgid "Now we can compute::"

msgstr "اکنون می‌توانیم محاسبه کنیم::"

msgid ""

msgstr ""

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 "در این مثال، خطی‌سازیبه‌شکلی بسیار مناسب بر اساس سطح ارث‌بری مرتب شده است، به این معنا که سطوح پایین‌تر (یعنی کلاس‌های تخصصی‌تر) اولویت بالاتری دارند (به نمودار ارث‌بری مراجعه کنید). با این حال، این حالت کلی نیست."

msgid "I leave as an exercise for the reader to compute the linearization for my second example:"

msgstr "محاسبه‌ی خطی‌سازی دومین مثال خود را به‌عنوان تمرینی برای خواننده باقی می‌گذارم:"

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) است؛ با این حال حتی چنین تغییر کوچکی نیز به‌طور کامل ترتیب سلسله‌مراتب را تغییر می‌دهد:"

msgid ""

msgstr ""

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 است."

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 "یک برنامه‌نویس تنبل می‌تواند MRO را مستقیماً از Python 2.2 به دست آورد، زیرا در این حالت با خطی‌سازی Python 2.3 منطبق است. کافی است متد :meth:`~type.mro` کلاس A را فراخوانی کنید:"

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 ساده است:"

msgid ""

msgstr ""

msgid "However, it is impossible to compute the linearization for a class C that inherits from A and B::"

msgstr "با این حال، محاسبه‌ی خطی‌سازیبرای کلاس C که از A و B ارث‌بری می‌کند، غیرممکن است::"

msgid ""

msgstr ""

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 متوقف می‌شود. پایتون 2.3 خطایی پرتاب می‌کند و از ایجاد کلاس C سرباز می‌زند."

msgid "Bad Method Resolution Orders"

msgstr "ترتیب‌های نامعتبر حل متد"

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 زمانی *بد* است که ویژگی‌های بنیادی مانند ترتیب تقدم محلی و یک‌نوایی را نقض کند. در این بخش، نشان خواهم داد که هم MRO برای کلاس‌های کلاسیک و هم MRO برای کلاس‌های به‌سبک جدید در Python 2.2 بد هستند."

msgid "It is easier to start with the local precedence ordering. Consider the following example:"

msgstr "شروع با ترتیب اولویت محلی آسان‌تر است. مثال زیر را در نظر بگیرید:"

msgid "with inheritance diagram"

msgstr "با نمودار وراثت"

msgid ""

msgstr ""

msgid "We see that class G inherits from F and E, with F *before* E: therefore we would expect the attribute *G.remember2buy* to be inherited by *F.remember2buy* and not by *E.remember2buy*: nevertheless Python 2.2 gives"

msgstr "می‌بینیم که کلاس G از F و E ارث می‌برد، به‌طوری که F *قبل از* E قرار دارد: بنابراین انتظار داریم ویژگی *G.remember2buy* از *F.remember2buy* به‌ارث برده شود و نه از *E.remember2buy*: با این حال Python 2.2 می‌دهد"

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 در پایتون 2.2 حفظ نمی‌شود::"

msgid "L[G,P22]= G E F object # F *follows* E"

msgstr "L[G,P22]= G E F object # F *follows* E"

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 "می‌توان استدلال کرد که دلیل اینکه F در خطی‌سازیپایتون 2.2 پس از E قرار می‌گیرد، این است که F نسبت به E کمتر تخصصی است، زیرا F ابرکلاس E است؛ با این حال، نقض ترتیب تقدم محلی کاملاً غیرشهودی و مستعد خطا است. این موضوع به‌ویژه از آن رو درست است که با کلاس‌های قدیمی‌سبک متفاوت است:"

msgid "In this case the MRO is GFEF and the local precedence ordering is preserved."

msgstr "در این حالت، MRO برابر GFEF است و ترتیب اولویت محلی حفظ می‌شود."

msgid "As a general rule, hierarchies such as the previous one should be avoided, since it is unclear if F should override E or vice-versa. Python 2.3 solves the ambiguity by raising an exception in the creation of class G, effectively stopping the programmer from generating ambiguous hierarchies. The reason for that is that the C3 algorithm fails when the merge::"

msgstr "به‌عنوان یک قاعده‌ی کلی، باید از سلسله‌مراتب‌هایی مانند مورد قبلی اجتناب کرد، زیرا مشخص نیست که آیا F باید E را بازنویسی کند یا برعکس. پایتون 2.3 این ابهام را با پرتاب یک استثنا هنگام ایجاد کلاس G حل می‌کند و عملاً برنامه‌نویس را از تولید سلسله‌مراتب‌های مبهم باز می‌دارد. دلیل آن این است که الگوریتم C3 هنگام ادغام (merge) شکست می‌خورد::"

msgid "merge(FO,EFO,FE)"

msgstr "merge(FO,EFO,FE)"

msgid "cannot be computed, because F is in the tail of EFO and E is in the tail of FE."

msgstr "نمی‌تواند محاسبه شود، زیرا F در دم EFO و E در دم FE قرار دارد."

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 "راه‌حل واقعی این است که یک سلسله‌مراتب غیرمبهم طراحی کنید، یعنی G را از E و F (خاص‌تر در ابتدا) مشتق کنید، نه از F و E؛ در این حالت MRO بدون هیچ تردیدی GEF خواهد بود."

msgid ""

msgstr ""

msgid "Python 2.3 forces the programmer to write good hierarchies (or, at least, less error-prone ones)."

msgstr "پایتون 2.3 برنامه‌نویس را وادار می‌کند که سلسله‌مراتب‌های خوبی بنویسد (یا دست‌کم، سلسله‌مراتب‌های کمتر مستعد خطا)."

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 "در نکته‌ای مرتبط، اجازه دهید اشاره کنم که الگوریتم پایتون 2.3 به اندازه کافی هوشمند است تا اشتباهات آشکار را، مانند تکرار کلاس‌ها در فهرست والدین، تشخیص دهد:"

msgid "Python 2.2 (both for classic classes and new style classes) in this situation, would not raise any exception."

msgstr "پایتون 2.2 (هم برای کلاس‌های کلاسیک و هم برای کلاس‌های سبک جدید) در این موقعیت، هیچ استثنایی را پرتاب نمی‌کرد."

msgid "Finally, I would like to point out two lessons we have learned from this example:"

msgstr "در نهایت، مایلم به دو درسی که از این مثال آموخته‌ایم اشاره کنم:"

msgid "despite the name, the MRO determines the resolution order of attributes, not only of methods;"

msgstr "با وجود این نام، MRO ترتیب حل ویژگی‌ها را تعیین می‌کند، نه فقط متدها؛"

msgid "the default food for Pythonistas is spam ! (but you already knew that ;-)"

msgstr "غذای پیش‌فرض پایتونیست‌ها اسپم است! (اما شما از قبل این موضوع را می‌دانستید ;-)"

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 کلاس‌های کلاسیک یکنواخت است و نه MRO کلاس‌های سبک جدید Python 2.2."

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 "اثبات غیریک‌نواخت بودن ترتیب حل متد (MRO) برای کلاس‌های کلاسیک نسبتاً بدیهی است؛ کافی است به نمودار الماسی نگاه کنید:"

msgid ""

msgstr ""

msgid "One easily discerns the inconsistency::"

msgstr "به‌راحتی می‌توان ناسازگاری را تشخیص داد::"

msgid ""

msgstr ""

msgid "On the other hand, there are no problems with the Python 2.2 and 2.3 MROs, they give both::"

msgstr "از سوی دیگر، هیچ مشکلی با MROهای پایتون 2.2 و 2.3 وجود ندارد، آن‌ها هر دو را ارائه می‌دهند::"

msgid "L[D] = D A B C"

msgstr "L[D] = D A B C"

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 "گیدو در مقاله‌ی خود [#]_ اشاره می‌کند که MRO کلاسیک در عمل آن‌قدرها هم بد نیست، زیرا معمولاً می‌توان در کلاس‌های کلاسیک از الماس‌ها اجتناب کرد. اما همه‌ی کلاس‌های جدید از ``object`` ارث می‌برند، بنابراین الماس‌ها اجتناب‌ناپذیرند و ناهماهنگی‌ها در هر گراف وراثت چندگانه آشکار می‌شوند."

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 "MRO در پایتون 2.2 نقض یکنواختی را دشوار می‌سازد، اما آن را غیرممکن نمی‌کند. مثال زیر، که در اصل توسط Samuele Pedroni ارائه شده است، نشان می‌دهد که MRO در پایتون 2.2 یکنواخت نیست:"

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 آمده‌اند (شما باید این خطی‌سازی‌ها را به‌عنوان تمرین صحت‌سنجی کنید و نمودار وراثت را رسم کنید ;-) ::"

msgid ""

msgstr ""

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 "پایتون 2.2 دقیقاً همان خطی‌سازی‌ها را برای A، B، C، D، E، K1، K2 و K3 ارائه می‌دهد، اما خطی‌سازی متفاوتی برای Z::"

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"

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 "واضح است که این خطی‌سازی *نادرست* است، زیرا A پیش از D می‌آید، در حالی که در خطی‌سازی K3، A *پس از* D می‌آید. به بیان دیگر، در K3، متدهای مشتق‌شده از D، متدهای مشتق‌شده از A را بازتعریف می‌کنند، اما در Z، که همچنان زیرکلاسی از K3 است، متدهای مشتق‌شده از A، متدهای مشتق‌شده از D را بازتعریف می‌کنند! این نقض یکنواختی (monotonicity) است. علاوه بر این، خطی‌سازی Z در پایتون 2.2 نیز با ترتیب تقدم محلی (local precedence ordering) ناسازگار است، زیرا فهرست تقدم محلی کلاس Z [K1, K2, K3] است (K2 پیش از K3 می‌آید)، در حالی که در خطی‌سازی Z، K2 *پس از* K3 می‌آید. این مشکلات توضیح می‌دهند که چرا قانون 2.2 به نفع قانون C3 کنار گذاشته شده است."

msgid "The end"

msgstr "پایان"

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 "این بخش برای خواننده‌ی عجولی است که همه‌ی بخش‌های پیشین را رد کرده و بلافاصله به انتها پریده است. این بخش برای برنامه‌نویس تنبل نیز هست که نمی‌خواست مغز خود را ورزش دهد. سرانجام، این بخش برای برنامه‌نویسی است که کمی غرور دارد، وگرنه او مقاله‌ای درباره‌ی ترتیب حل متد C3 در سلسله‌مراتب‌های ارث‌بری چندگانه نمی‌خواند ;-) این سه فضیلت در کنار هم (و *نه* به‌طور جداگانه) شایسته‌ی یک جایزه هستند: جایزه یک اسکریپت کوتاه پایتون 2.2 است که به شما امکان می‌دهد MRO 2.3 را بدون خطر برای مغزتان محاسبه کنید. به‌سادگی خط آخر را تغییر دهید تا با مثال‌های مختلفی که در این مقاله به آن‌ها پرداخته‌ام بازی کنید.::"

msgid ""

msgstr ""

msgid "That's all folks,"

msgstr "همین و بس، دوستان،"

msgid "enjoy !"

msgstr "لذت ببرید!"

msgid "Resources"

msgstr "منابع"

msgid "The thread on python-dev started by Samuele Pedroni: https://mail.python.org/pipermail/python-dev/2002-October/029035.html"

msgstr "رشته‌ی python-dev که Samuele Pedroni آن را آغاز کرد: https://mail.python.org/pipermail/python-dev/2002-October/029035.html"

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"

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 "مقاله‌ی گیدو ون روسوم، *یکپارچه‌سازی نوع‌ها و کلاس‌ها در Python 2.2*: https://web.archive.org/web/20140210194412/http://www.python.org/download/releases/2.2.2/descrintro"