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

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

"POT-Creation-Date: 2026-11-09 04:12+0000\n"

"PO-Revision-Date: 2026-09-14 13:33+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 "Design and History FAQ"

msgstr "پرسش‌های متداول درباره‌ی طراحی و تاریخچه"

msgid "Why does Python use indentation for grouping of statements?"

msgstr "چرا پایتون از تورفتگی برای گروه‌بندی دستورها استفاده می‌کند؟"

msgid "Guido van Rossum believes that using indentation for grouping is extremely elegant and contributes a lot to the clarity of the average Python program. Most people learn to love this feature after a while."

msgstr "گیدو ون روسوم معتقد است که استفاده از تورفتگی برای گروه‌بندی بسیار ظریف است و سهم زیادی در وضوح برنامه‌های معمول پایتون دارد. بسیاری از افراد پس از مدتی به این ویژگی علاقه‌مند می‌شوند."

msgid "Since there are no begin/end brackets there cannot be a disagreement between grouping perceived by the parser and the human reader. Occasionally C programmers will encounter a fragment of code like this::"

msgstr "از آن‌جا که هیچ براکت آغاز/پایانی وجود ندارد، هیچ ناهماهنگی‌ای میان گروه‌بندی از دید پارسر و خواننده‌ی انسانی وجود نخواهد داشت. گاهی برنامه‌نویسان C با قطعه‌کدی مانند این مواجه می‌شوند::"

msgid ""

msgstr ""

msgid "Only the ``x++`` statement is executed if the condition is true, but the indentation leads many to believe otherwise. Even experienced C programmers will sometimes stare at it a long time wondering as to why ``y`` is being decremented even for ``x > y``."

msgstr "در صورت برقرار بودن شرط، تنها دستور ``x++`` اجرا می‌شود، اما تورفتگی باعث می‌شود بسیاری برداشت دیگری داشته باشند. حتی برنامه‌نویسان باتجربه‌ی C نیز گاهی مدت‌ها به آن خیره می‌شوند و از خود می‌پرسند که چرا ``y`` حتی برای ``x > y`` کاهش می‌یابد."

msgid "Because there are no begin/end brackets, Python is much less prone to coding-style conflicts. In C there are many different ways to place the braces. After becoming used to reading and writing code using a particular style, it is normal to feel somewhat uneasy when reading (or being required to write) in a different one."

msgstr "چون براکت‌های آغاز/پایان وجود ندارند، پایتون بسیار کمتر در معرض تعارض‌های سبک کدنویسی است. در C روش‌های مختلفی برای قرار دادن آکولادها وجود دارد. پس از آنکه به خواندن و نوشتن کد با یک سبک خاص عادت کردید، طبیعی است که هنگام خواندن (یا ملزم بودن به نوشتن) با سبکی متفاوت، تا حدی احساس ناراحتی کنید."

msgid "Many coding styles place begin/end brackets on a line by themselves. This makes programs considerably longer and wastes valuable screen space, making it harder to get a good overview of a program. Ideally, a function should fit on one screen (say, 20--30 lines). 20 lines of Python can do a lot more work than 20 lines of C. This is not solely due to the lack of begin/end brackets -- the lack of declarations and the high-level data types are also responsible -- but the indentation-based syntax certainly helps."

msgstr "سبک‌های کدنویسی بسیاری، براکت‌های begin/end را در یک خط جداگانه قرار می‌دهند. این کار برنامه‌ها را به‌طور قابل‌توجهی طولانی‌تر می‌کند و فضای ارزشمند صفحه را هدر می‌دهد و در نتیجه داشتن دید کلی خوب از برنامه را دشوارتر می‌سازد. در حالت ایده‌آل، یک تابع باید در یک صفحه جا شود (مثلاً ۲۰ تا ۳۰ خط). ۲۰ خط پایتون می‌تواند کار بسیار بیشتری نسبت به ۲۰ خط C انجام دهد. این موضوع تنها به دلیل نبود براکت‌های begin/end نیست — نبود اعلان‌ها و انواع داده سطح بالا نیز در آن نقش دارند — اما سینتکس مبتنی بر تورفتگی قطعاً کمک می‌کند."

msgid "Why am I getting strange results with simple arithmetic operations?"

msgstr "چرا هنگام انجام عملیات حسابی ساده، نتایج عجیبی دریافت می‌کنم؟"

msgid "See the next question."

msgstr "پرسش بعدی را ببینید."

msgid "Why are floating-point calculations so inaccurate?"

msgstr "چرا محاسبات ممیز شناور این‌قدر نادقیق هستند؟"

msgid "Users are often surprised by results like this::"

msgstr "کاربران اغلب از نتایجی مانند این شگفت‌زده می‌شوند::"

msgid ""

msgstr ""

msgid "and think it is a bug in Python. It's not. This has little to do with Python, and much more to do with how the underlying platform handles floating-point numbers."

msgstr "و فکر می‌کنند که این یک باگ در پایتون است. این‌طور نیست. این موضوع ارتباط کمی با پایتون دارد و ارتباط بسیار بیشتری با نحوه‌ی مدیریت اعداد ممیز شناور توسط پلتفرم زیرین دارد."

msgid "The :class:`float` type in CPython uses a C ``double`` for storage. A :class:`float` object's value is stored in binary floating-point with a fixed precision (typically 53 bits) and Python uses C operations, which in turn rely on the hardware implementation in the processor, to perform floating-point operations. This means that as far as floating-point operations are concerned, Python behaves like many popular languages including C and Java."

msgstr "نوع :class:`float` در CPython برای ذخیره‌سازی از یک ``double`` در C استفاده می‌کند. مقدار یک شیء :class:`float` به‌صورت ممیز شناور دودویی با دقت ثابت (معمولاً ۵۳ بیت) ذخیره می‌شود و پایتون برای انجام عملیات ممیز شناور از عملیات C استفاده می‌کند، که خود به پیاده‌سازی سخت‌افزاری در پردازنده متکی هستند. این بدان معناست که تا جایی که به عملیات ممیز شناور مربوط می‌شود، پایتون مانند بسیاری از زبان‌های محبوب از جمله C و Java رفتار می‌کند."

msgid "Many numbers that can be written easily in decimal notation cannot be expressed exactly in binary floating point. For example, after::"

msgstr "بسیاری از اعدادی که به‌راحتی می‌توان آن‌ها را در نماد دهدهی نوشت، نمی‌توانند دقیقاً در قالب ممیز شناور دودویی بیان شوند. برای مثال، پس از::"

msgid ">>> x = 1.2"

msgstr ">>> x = 1.2"

msgid "the value stored for ``x`` is a (very good) approximation to the decimal value ``1.2``, but is not exactly equal to it. On a typical machine, the actual stored value is::"

msgstr "مقدار ذخیره‌شده برای ``x`` تقریبی (بسیار خوب) از مقدار دهدهی ``1.2`` است، اما دقیقاً برابر با آن نیست. در یک ماشین معمول، مقدار ذخیره‌شده واقعی عبارت است از::"

msgid "1.0011001100110011001100110011001100110011001100110011 (binary)"

msgstr "1.0011001100110011001100110011001100110011001100110011 (دودویی)"

msgid "which is exactly::"

msgstr "که دقیقاً به‌صورت زیر است::"

msgid "1.1999999999999999555910790149937383830547332763671875 (decimal)"

msgstr "1.1999999999999999555910790149937383830547332763671875 (دهدهی)"

msgid "The typical precision of 53 bits provides Python floats with 15--16 decimal digits of accuracy."

msgstr "دقت معمول ۵۳ بیتی، برای اعداد اعشاری پایتون ۱۵ تا ۱۶ رقم اعشاری دقت فراهم می‌کند."

msgid "For a fuller explanation, please see the :ref:`floating-point arithmetic <tut-fp-issues>` chapter in the Python tutorial."

msgstr "برای توضیح کامل‌تر، لطفاً فصل :ref:`حساب ممیز شناور <tut-fp-issues>` در آموزش پایتون را ببینید."

msgid "Why are Python strings immutable?"

msgstr "چرا رشته‌های پایتون تغییرناپذیر هستند؟"

msgid "There are several advantages."

msgstr "چندین مزیت وجود دارد."

msgid "One is performance: knowing that a string is immutable means we can allocate space for it at creation time, and the storage requirements are fixed and unchanging. This is also one of the reasons for the distinction between tuples and lists."

msgstr "یکی از آن‌ها کارایی است: دانستن اینکه یک رشته تغییرناپذیر است به این معناست که می‌توانیم فضای آن را در زمان ایجاد تخصیص دهیم، و نیازهای ذخیره‌سازی ثابت و بدون تغییر هستند. این نیز یکی از دلایل تمایز بین تاپل‌ها و فهرست‌ها است."

msgid "Another advantage is that strings in Python are considered as \"elemental\" as numbers. No amount of activity will change the value 8 to anything else, and in Python, no amount of activity will change the string \"eight\" to anything else."

msgstr "مزیت دیگر این است که رشته‌ها در پایتون به همان اندازه‌ی اعداد «بنیادی» محسوب می‌شوند. هیچ میزان فعالیتی مقدار ۸ را به چیز دیگری تغییر نخواهد داد، و در پایتون، هیچ میزان فعالیتی رشته‌ی \"eight\" را به چیز دیگری تغییر نخواهد داد."

msgid "Why must 'self' be used explicitly in method definitions and calls?"

msgstr "چرا باید از 'self' به‌صراحت در تعاریف و فراخوانی‌های متد استفاده شود؟"

msgid "The idea was borrowed from Modula-3. It turns out to be very useful, for a variety of reasons."

msgstr "این ایده از Modula-3 اقتباس شده است. به دلایل گوناگونی، بسیار مفید است."

msgid "First, it's more obvious that you are using a method or instance attribute instead of a local variable. Reading ``self.x`` or ``self.meth()`` makes it absolutely clear that an instance variable or method is used even if you don't know the class definition by heart. In C++, you can sort of tell by the lack of a local variable declaration (assuming globals are rare or easily recognizable) -- but in Python, there are no local variable declarations, so you'd have to look up the class definition to be sure. Some C++ and Java coding standards call for instance attributes to have an ``m_`` prefix, so this explicitness is still useful in those languages, too."

msgstr "اول، آشکارتر است که شما به‌جای یک متغیر محلی از یک متد یا ویژگی نمونه استفاده می‌کنید. خواندن ``self.x`` یا ``self.meth()`` کاملاً روشن می‌سازد که از یک متغیر نمونه یا متد استفاده شده است، حتی اگر تعریف کلاس را از حفظ ندانید. در C++، تا حدی می‌توان از نبود اعلان متغیر محلی این موضوع را تشخیص داد (با فرض اینکه متغیرهای سراسری نادر یا به‌راحتی قابل‌تشخیص باشند) — اما در پایتون، هیچ اعلان متغیر محلی وجود ندارد، بنابراین برای اطمینان باید به تعریف کلاس مراجعه کنید. برخی استانداردهای کدنویسی C++ و Java مقرر می‌دارند که ویژگی‌های نمونه دارای پیشوند ``m_`` باشند، بنابراین این صراحت در آن زبان‌ها نیز همچنان مفید است."

msgid "Second, it means that no special syntax is necessary if you want to explicitly reference or call the method from a particular class. In C++, if you want to use a method from a base class which is overridden in a derived class, you have to use the ``::`` operator -- in Python you can write ``baseclass.methodname(self, <argument list>)``. This is particularly useful for :meth:`~object.__init__` methods, and in general in cases where a derived class method wants to extend the base class method of the same name and thus has to call the base class method somehow."

msgstr "دوم، این بدان معناست که اگر بخواهید به‌صراحت به متدی از یک کلاس خاص ارجاع دهید یا آن را فراخوانی کنید، نیازی به سینتکس خاصی نیست. در C++، اگر بخواهید از متدی از کلاس پایه استفاده کنید که در یک کلاس مشتق‌شده بازنویسی شده است، باید از عملگر ``::`` استفاده کنید — در پایتون می‌توانید ``baseclass.methodname(self, <argument list>)`` را بنویسید. این موضوع به‌ویژه برای متدهای :meth:`~object.__init__` مفید است، و به‌طور کلی در مواردی که متد کلاس مشتق‌شده بخواهد متد کلاس پایه با همین نام را گسترش دهد و از این رو لازم باشد متد کلاس پایه را به‌نحوی فراخوانی کند."

msgid "Finally, for instance variables it solves a syntactic problem with assignment: since local variables in Python are (by definition!) those variables to which a value is assigned in a function body (and that aren't explicitly declared global), there has to be some way to tell the interpreter that an assignment was meant to assign to an instance variable instead of to a local variable, and it should preferably be syntactic (for efficiency reasons). C++ does this through declarations, but Python doesn't have declarations and it would be a pity having to introduce them just for this purpose. Using the explicit ``self.var`` solves this nicely. Similarly, for using instance variables, having to write ``self.var`` means that references to unqualified names inside a method don't have to search the instance's directories. To put it another way, local variables and instance variables live in two different namespaces, and you need to tell Python which namespace to use."

msgstr "در نهایت، برای متغیرهای نمونه، این موضوع یک مشکل نحوی در انتساب را حل می‌کند: از آن‌جا که متغیرهای محلی در پایتون (طبق تعریف!) آن متغیرهایی هستند که مقداری در بدنه یک تابع به آن‌ها انتساب داده می‌شود (و به‌صراحت سراسری اعلام نشده‌اند)، باید راهی وجود داشته باشد تا به مفسر بگوییم که منظور از یک انتساب، انتساب به یک متغیر نمونه است نه به یک متغیر محلی، و ترجیحاً باید نحوی باشد (به دلایل کارایی). C++ این کار را از طریق اعلان‌ها انجام می‌دهد، اما پایتون اعلان ندارد و حیف است که فقط برای این هدف مجبور شویم آن‌ها را معرفی کنیم. استفاده صریح از ``self.var`` این مشکل را به‌خوبی حل می‌کند. به‌طور مشابه، برای استفاده از متغیرهای نمونه، این که باید ``self.var`` نوشته شود به این معناست که ارجاع‌ها به نام‌های ناکامل در داخل یک متد نیازی به جستجوی پوشه‌های آن نمونه ندارند. به بیان دیگر، متغیرهای محلی و متغیرهای نمونه در دو فضای نام متفاوت قرار دارند و شما باید به پایتون بگویید که از کدام فضای نام استفاده کند."

msgid "Why can't I use an assignment in an expression?"

msgstr "چرا نمی‌توانم در یک عبارت از انتساب استفاده کنم؟"

msgid "Starting in Python 3.8, you can!"

msgstr "از پایتون 3.8 به بعد، می‌توانید!"

msgid "Assignment expressions using the walrus operator ``:=`` assign a variable in an expression::"

msgstr "عبارات انتسابی که از عملگر والروس (walrus operator) ``:=`` استفاده می‌کنند، متغیری را در یک عبارت انتساب می‌دهند::"

msgid ""

msgstr ""

msgid "See :pep:`572` for more information."

msgstr "برای اطلاعات بیشتر، :pep:`572` را ببینید."

msgid "Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?"

msgstr "چرا پایتون برای برخی قابلیت‌ها از متدها استفاده می‌کند (مثلاً list.index()) اما برای برخی دیگر از توابع (مثلاً len(list))؟"

msgid "As Guido said:"

msgstr "همان‌طور که گایدو گفت:"

msgid "(a) For some operations, prefix notation just reads better than postfix -- prefix (and infix!) operations have a long tradition in mathematics which likes notations where the visuals help the mathematician thinking about a problem. Compare the easy with which we rewrite a formula like x*(a+b) into x*a + x*b to the clumsiness of doing the same thing using a raw OO notation."

msgstr "(a) برای برخی عملیات، نمادگذاری پیشوندی به‌سادگی خواناتر از پسوندی است — عملیات پیشوندی (و میانوندی!) در ریاضیات سابقه‌ای طولانی دارند؛ ریاضیات نمادگذاری‌هایی را می‌پسندد که در آن‌ها جنبه‌های بصری به ریاضی‌دان کمک می‌کنند تا درباره‌ی یک مسئله بیندیشد. سهولتی را که با آن فرمولی مانند x*(a+b) را به x*a + x*b بازنویسی می‌کنیم، با ناشیانه بودن انجام همان کار با استفاده از یک نمادگذاری خام شیء‌گرا (OO) مقایسه کنید."

msgid "(b) When I read code that says len(x) I *know* that it is asking for the length of something. This tells me two things: the result is an integer, and the argument is some kind of container. To the contrary, when I read x.len(), I have to already know that x is some kind of container implementing an interface or inheriting from a class that has a standard len(). Witness the confusion we occasionally have when a class that is not implementing a mapping has a get() or keys() method, or something that isn't a file has a write() method."

msgstr "(ب) هنگامی که کدی را می‌خوانم که len(x) دارد، *می‌دانم* که درخواست طول چیزی را دارد. این موضوع دو چیز را به من می‌گوید: نتیجه یک عدد صحیح است و آرگومان نوعی ظرف است. در مقابل، هنگامی که x.len() را می‌خوانم، باید از قبل بدانم که x نوعی ظرف است که یک رابط را پیاده‌سازی می‌کند یا از کلاسی ارث می‌برد که یک len() استاندارد دارد. به سردرگمی‌ای که گاهی با آن مواجه می‌شویم توجه کنید، هنگامی که کلاسی که یک نگاشت را پیاده‌سازی نمی‌کند دارای متد get() یا keys() است، یا چیزی که پرونده نیست متد write() دارد."

msgid "https://mail.python.org/pipermail/python-3000/2006-November/004643.html"

msgstr "https://mail.python.org/pipermail/python-3000/2006-November/004643.html"

msgid "Why is join() a string method instead of a list or tuple method?"

msgstr "چرا join() یک متد رشته است، نه یک متد فهرست یا تاپل؟"

msgid "Strings became much more like other standard types starting in Python 1.6, when methods were added which give the same functionality that has always been available using the functions of the string module. Most of these new methods have been widely accepted, but the one which appears to make some programmers feel uncomfortable is::"

msgstr "رشته‌ها از پایتون 1.6 بسیار شبیه‌تر به سایر انواع استاندارد شدند، زمانی که متدهایی افزوده شدند که همان عملکردی را ارائه می‌دهند که همواره از طریق توابع ماژول string در دسترس بوده است. بیشتر این متدهای جدید به‌طور گسترده پذیرفته شده‌اند، اما آن متدی که به نظر می‌رسد باعث ناراحتی برخی برنامه‌نویسان می‌شود، این است::"

msgid "\", \".join(['1', '2', '4', '8', '16'])"

msgstr "\", \".join(['1', '2', '4', '8', '16'])"

msgid "which gives the result::"

msgstr "که نتیجه زیر را می‌دهد::"

msgid "\"1, 2, 4, 8, 16\""

msgstr "1, 2, 4, 8, 16"

msgid "There are two common arguments against this usage."

msgstr "دو آرگومان رایج در مخالفت با این کاربرد وجود دارد."

msgid "The first runs along the lines of: \"It looks really ugly using a method of a string literal (string constant)\", to which the answer is that it might, but a string literal is just a fixed value. If the methods are to be allowed on names bound to strings there is no logical reason to make them unavailable on literals."

msgstr "مورد اول این‌گونه است: «استفاده از یک متدِ رشته‌ی لفظی (ثابت رشته‌ای) واقعاً زشت به نظر می‌رسد»، پاسخ این است که شاید چنین باشد، اما یک رشته‌ی لفظی صرفاً یک مقدار ثابت است. اگر متدها روی نام‌های مقید به رشته‌ها مجاز باشند، هیچ دلیل منطقی برای در دسترس نبودن آن‌ها روی رشته‌های لفظی وجود ندارد."

msgid "The second objection is typically cast as: \"I am really telling a sequence to join its members together with a string constant\". Sadly, you aren't. For some reason there seems to be much less difficulty with having :meth:`~str.split` as a string method, since in that case it is easy to see that ::"

msgstr "اعتراض دوم معمولاً به این صورت بیان می‌شود: «من در واقع به یک دنباله می‌گویم که اعضای خود را با یک ثابت رشته‌ای به هم بپیوندد». متأسفانه، شما این کار را نمی‌کنید. به دلایلی، داشتن :meth:`~str.split` به‌عنوان یک متد رشته‌ای بسیار کمتر دشوار به نظر می‌رسد، زیرا در آن حالت به‌راحتی می‌توان دید که ::"

msgid "\"1, 2, 4, 8, 16\".split(\", \")"

msgstr "\"1, 2, 4, 8, 16\".split(\", \")"

msgid "is an instruction to a string literal to return the substrings delimited by the given separator (or, by default, arbitrary runs of white space)."

msgstr "دستوری به یک رشته‌ی لفظی برای بازگرداندن زیررشته‌هایی است که با جداکننده‌ی داده‌شده جدا شده‌اند (یا به‌طور پیش‌فرض، دنباله‌های دلخواه فضای خالی)."

msgid ":meth:`~str.join` is a string method because in using it you are telling the separator string to iterate over a sequence of strings and insert itself between adjacent elements. This method can be used with any argument which obeys the rules for sequence objects, including any new classes you might define yourself. Similar methods exist for bytes and bytearray objects."

msgstr ":meth:`~str.join` یک متد رشته است، زیرا هنگام استفاده از آن، شما به رشته‌ی جداکننده می‌گویید که دنباله‌ای از رشته‌ها را پیمایش کند و خود را بین عناصر مجاور درج کند. این متد را می‌توان با هر آرگومانی که از قوانین اشیاء دنباله‌ای پیروی می‌کند، استفاده کرد؛ از جمله هر کلاس جدیدی که ممکن است خودتان تعریف کنید. متدهای مشابهی برای اشیاء bytes و bytearray وجود دارند."

msgid "How fast are exceptions?"

msgstr "استثناها چقدر سریع هستند؟"

msgid "A :keyword:`try`/:keyword:`except` block is extremely efficient if no exceptions are raised. Actually catching an exception is expensive. In versions of Python prior to 2.0 it was common to use this idiom::"

msgstr "یک بلوک :keyword:`try`/:keyword:`except` اگر هیچ استثنایی پرتاب نشود، بسیار کارآمد است. در واقع، گرفتن یک استثنا پرهزینه است. در نسخه‌های پیش از 2.0 پایتون، استفاده از این اصطلاح رایج بود::"

msgid ""

msgstr ""

msgid "This only made sense when you expected the dict to have the key almost all the time. If that wasn't the case, you coded it like this::"

msgstr "این تنها زمانی منطقی بود که انتظار داشتید دیکشنری تقریباً همیشه کلید را داشته باشد. اگر این‌طور نبود، آن را این‌گونه کدنویسی می‌کردید::"

msgid ""

msgstr ""

msgid "For this specific case, you could also use ``value = dict.setdefault(key, getvalue(key))``, but only if the ``getvalue()`` call is cheap enough because it is evaluated in all cases."

msgstr "برای این مورد خاص، می‌توانید از ``value = dict.setdefault(key, getvalue(key))`` نیز استفاده کنید، اما تنها در صورتی که فراخوانی ``getvalue()`` به‌اندازه کافی کم‌هزینه باشد، زیرا در همه موارد ارزیابی می‌شود."

msgid "Why isn't there a switch or case statement in Python?"

msgstr "چرا در پایتون دستور switch یا case وجود ندارد؟"

msgid "In general, structured switch statements execute one block of code when an expression has a particular value or set of values. Since Python 3.10 one can easily match literal values, or constants within a namespace, with a ``match ... case`` statement. See :ref:`the specification <match>` and :ref:`the tutorial <tut-match>` for more information about :keyword:`match` statements. An older alternative is a sequence of ``if... elif... elif... else``."

msgstr "به‌طور کلی، دستورهای switch ساختاریافته یک بلوک کد را هنگامی اجرا می‌کنند که یک عبارت دارای یک مقدار خاص یا مجموعه‌ای از مقادیر باشد. از پایتون 3.10، می‌توانید به‌راحتی مقادیر لفظی یا ثابت‌های درون یک فضای نام را با دستور ``match ... case`` تطبیق دهید. برای اطلاعات بیشتر درباره دستورهای :keyword:`match`، :ref:`مشخصات <match>` و :ref:`آموزش <tut-match>` را ببینید. یک جایگزین قدیمی‌تر، دنباله‌ای از ``if... elif... elif... else`` است."

msgid "For cases where you need to choose from a very large number of possibilities, you can create a dictionary mapping case values to functions to call. For example::"

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

msgid ""

msgstr ""

msgid "For calling methods on objects, you can simplify yet further by using the :func:`getattr` built-in to retrieve methods with a particular name::"

msgstr "برای فراخوانی متدها روی اشیاء، می‌توانید این کار را با استفاده از تابع توکار :func:`getattr` برای واکشی متدهایی با نامی خاص، باز هم ساده‌تر کنید::"

msgid ""

msgstr ""

msgid "It's suggested that you use a prefix for the method names, such as ``visit_`` in this example. Without such a prefix, if values are coming from an untrusted source, an attacker would be able to call any method on your object."

msgstr "پیشنهاد می‌شود از یک پیشوند برای نام متدها استفاده کنید، مانند ``visit_`` در این مثال. بدون چنین پیشوندی، اگر مقادیر از منبعی غیرقابل‌اعتماد دریافت شوند، یک مهاجم می‌تواند هر متدی را روی شیء شما فراخوانی کند."

msgid "Imitating switch with fallthrough, as with C's switch-case-default, is possible, much harder, and less needed."

msgstr "تقلید switch با fallthrough، مانند switch-case-default در C، امکان‌پذیر است، بسیار دشوارتر است و کمتر مورد نیاز است."

msgid "Can't you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?"

msgstr "آیا نمی‌توانید به جای تکیه بر یک پیاده‌سازی نخ مختص سیستم‌عامل، نخ‌ها را در مفسر شبیه‌سازی کنید؟"

msgid "Answer 1: Unfortunately, the interpreter pushes at least one C stack frame for each Python stack frame. Also, extensions can call back into Python at almost random moments. Therefore, a complete threads implementation requires thread support for C."

msgstr "پاسخ ۱: متأسفانه، مفسر برای هر فریم پشته‌ی پایتون، حداقل یک فریم پشته‌ی C را روی پشته قرار می‌دهد. همچنین، افزونه‌ها می‌توانند در لحظاتی تقریباً تصادفی فراخوانی بازگشتی به پایتون داشته باشند. بنابراین، یک پیاده‌سازی کامل نخ‌ها به پشتیبانی از نخ برای C نیاز دارد."

msgid "Answer 2: Fortunately, there is `Stackless Python <https://github.com/stackless-dev/stackless/wiki>`_, which has a completely redesigned interpreter loop that avoids the C stack."

msgstr "پاسخ ۲: خوشبختانه، `Stackless Python <https://github.com/stackless-dev/stackless/wiki>`_ وجود دارد که حلقه مفسر آن به‌طور کامل بازطراحی شده است و از پشته‌ی C اجتناب می‌کند."

msgid "Why can't lambda expressions contain statements?"

msgstr "چرا عبارت‌های لامبدا نمی‌توانند شامل دستورها باشند؟"

msgid "Python lambda expressions cannot contain statements because Python's syntactic framework can't handle statements nested inside expressions. However, in Python, this is not a serious problem. Unlike lambda forms in other languages, where they add functionality, Python lambdas are only a shorthand notation if you're too lazy to define a function."

msgstr "عبارت‌های lambda پایتون نمی‌توانند شامل دستور باشند، زیرا چارچوب نحوی پایتون نمی‌تواند دستورهای تودرتو درون عبارت‌ها را مدیریت کند. با این حال، در پایتون، این مشکل جدی‌ای نیست. برخلاف فرم‌های lambda در زبان‌های دیگر، که قابلیت‌هایی اضافه می‌کنند، lambdaهای پایتون تنها یک نمادگذاری خلاصه هستند، اگر حوصله‌ی تعریف یک تابع را نداشته باشید."

msgid "Functions are already first class objects in Python, and can be declared in a local scope. Therefore the only advantage of using a lambda instead of a locally defined function is that you don't need to invent a name for the function -- but that's just a local variable to which the function object (which is exactly the same type of object that a lambda expression yields) is assigned!"

msgstr "توابع در پایتون از پیش اشیای درجه‌یک هستند و می‌توانند در یک محدوده محلی تعریف شوند. بنابراین تنها مزیت استفاده از لامبدا به جای یک تابع تعریف‌شده به‌صورت محلی این است که نیازی نیست برای تابع نامی ابداع کنید -- اما آن فقط یک متغیر محلی است که شیء تابع (که دقیقاً همان نوع شیء‌ای است که یک عبارت لامبدا برمی‌گرداند) به آن انتساب داده می‌شود!"

msgid "Can Python be compiled to machine code, C or some other language?"

msgstr "آیا پایتون می‌تواند به کد ماشین، C یا زبان دیگری کامپایل شود؟"

msgid "`Cython <https://cython.org/>`_ compiles a modified version of Python with optional annotations into C extensions. `Nuitka <https://nuitka.net/>`_ is an up-and-coming compiler of Python into C++ code, aiming to support the full Python language."

msgstr "`Cython <https://cython.org/>`_ نسخه‌ای اصلاح‌شده از پایتون را با حاشیه‌نویسی‌های اختیاری به افزونه‌های C کامپایل می‌کند. `Nuitka <https://nuitka.net/>`_ یک کامپایلر نوظهور برای کامپایل پایتون به کد C++ است که هدف آن پشتیبانی از کل زبان پایتون است."

msgid "How does Python manage memory?"

msgstr "پایتون چگونه حافظه را مدیریت می‌کند؟"

msgid "The details of Python memory management depend on the implementation. The standard implementation of Python, :term:`CPython`, uses reference counting to detect inaccessible objects, and another mechanism to collect reference cycles, periodically executing a cycle detection algorithm which looks for inaccessible cycles and deletes the objects involved. The :mod:`gc` module provides functions to perform a garbage collection, obtain debugging statistics, and tune the collector's parameters."

msgstr "جزئیات مدیریت حافظه پایتون به پیاده‌سازی بستگی دارد. پیاده‌سازی استاندارد پایتون، :term:`CPython`، از شمارش ارجاع برای تشخیص اشیای دسترس‌ناپذیر و از سازوکار دیگری برای جمع‌آوری چرخه‌های ارجاع استفاده می‌کند و به‌صورت دوره‌ای یک الگوریتم تشخیص چرخه را اجرا می‌کند که چرخه‌های دسترس‌ناپذیر را جستجو می‌کند و اشیای درگیر را حذف می‌کند. ماژول :mod:`gc` توابعی برای انجام زباله‌روبی، به‌دست آوردن آمار اشکال‌زدایی و تنظیم پارامترهای جمع‌کننده ارائه می‌دهد."

msgid "Other implementations (such as `Jython <https://www.jython.org>`_ or `PyPy <https://pypy.org>`_), however, can rely on a different mechanism such as a full-blown garbage collector. This difference can cause some subtle porting problems if your Python code depends on the behavior of the reference counting implementation."

msgstr "با این حال، سایر پیاده‌سازی‌ها (مانند `Jython <https://www.jython.org>`_ یا `PyPy <https://pypy.org>`_) می‌توانند به مکانیزم متفاوتی مانند یک زباله‌رو (garbage collector) کامل متکی باشند. این تفاوت می‌تواند در صورتی که کد پایتون شما به رفتار پیاده‌سازی شمارش ارجاع وابسته باشد، باعث برخی مشکلات ظریف در انتقال شود."

msgid "In some Python implementations, the following code (which is fine in CPython) will probably run out of file descriptors::"

msgstr "در برخی پیاده‌سازی‌های پایتون، کد زیر (که در CPython مشکلی ندارد) احتمالاً با اتمام توصیف‌گرهای پرونده مواجه می‌شود::"

msgid ""

msgstr ""

msgid "Indeed, using CPython's reference counting and destructor scheme, each new assignment to ``f`` closes the previous file. With a traditional GC, however, those file objects will only get collected (and closed) at varying and possibly long intervals."

msgstr "در واقع، با استفاده از طرح‌واره شمارش ارجاع و تخریب‌کننده‌ی CPython، هر انتساب جدید به ``f`` پرونده پیشین را می‌بندد. با این حال، با یک زباله‌روبی سنتی، آن اشیای پرونده تنها در فاصله‌های متغیر و احتمالاً طولانی جمع‌آوری (و بسته) می‌شوند."

msgid "If you want to write code that will work with any Python implementation, you should explicitly close the file or use the :keyword:`with` statement; this will work regardless of memory management scheme::"

msgstr "اگر می‌خواهید کدی بنویسید که با هر پیاده‌سازی پایتون کار کند، باید پرونده را به‌طور صریح ببندید یا از دستور :keyword:`with` استفاده کنید؛ این صرف‌نظر از طرح‌واره مدیریت حافظه کار خواهد کرد::"

msgid ""

msgstr ""

msgid "Why doesn't CPython use a more traditional garbage collection scheme?"

msgstr "چرا CPython از یک روش زباله‌روبی سنتی‌تر استفاده نمی‌کند؟"

msgid "For one thing, this is not a C standard feature and hence it's not portable. (Yes, we know about the Boehm GC library. It has bits of assembler code for *most* common platforms, not for all of them, and although it is mostly transparent, it isn't completely transparent; patches are required to get Python to work with it.)"

msgstr "برای نمونه، این یک ویژگی استاندارد C نیست و بنابراین قابل‌حمل نیست. (بله، ما در مورد کتابخانه Boehm GC می‌دانیم. این کتابخانه بخش‌هایی از کد اسمبلر را برای *بیشتر* سکوهای رایج دارد، نه برای همه‌ی آن‌ها، و اگرچه عمدتاً شفاف است، کاملاً شفاف نیست؛ برای اینکه پایتون بتواند با آن کار کند، به وصله‌ها نیاز است.)"

msgid "Traditional GC also becomes a problem when Python is embedded into other applications. While in a standalone Python it's fine to replace the standard ``malloc()`` and ``free()`` with versions provided by the GC library, an application embedding Python may want to have its *own* substitute for ``malloc()`` and ``free()``, and may not want Python's. Right now, CPython works with anything that implements ``malloc()`` and ``free()`` properly."

msgstr "زباله‌روبی سنتی نیز هنگامی که پایتون در برنامه‌های دیگر تعبیه می‌شود، به یک مشکل تبدیل می‌شود. در حالی که در یک پایتون مستقل، جایگزین کردن ``malloc()`` و ``free()`` استاندارد با نسخه‌های ارائه‌شده توسط کتابخانه زباله‌روبی مشکلی ندارد، برنامه‌ای که پایتون را تعبیه می‌کند ممکن است بخواهد جایگزین *خود* را برای ``malloc()`` و ``free()`` داشته باشد و ممکن است جایگزین پایتون را نخواهد. در حال حاضر، CPython با هر چیزی که ``malloc()`` و ``free()`` را به‌درستی پیاده‌سازی کند، کار می‌کند."

msgid "Why isn't all memory freed when CPython exits?"

msgstr "چرا هنگام خروج CPython، تمام حافظه آزاد نمی‌شود؟"

msgid "Objects referenced from the global namespaces of Python modules are not always deallocated when Python exits. This may happen if there are circular references. There are also certain bits of memory that are allocated by the C library that are impossible to free (e.g. a tool like Purify will complain about these). Python is, however, aggressive about cleaning up memory on exit and does try to destroy every single object."

msgstr "اشیایی که از فضای نام های سراسری ماژول‌های پایتون به آن‌ها ارجاع داده شده‌اند، همیشه هنگام خروج پایتون آزاد نمی‌شوند. ممکن است این اتفاق در صورت وجود ارجاع‌های چرخه‌ای رخ دهد. همچنین بخش‌هایی از حافظه وجود دارند که توسط کتابخانه C تخصیص داده شده‌اند و آزاد کردن آن‌ها غیرممکن است (برای مثال، ابزاری مانند Purify درباره‌ی این موارد شکایت خواهد کرد). با این حال، پایتون در پاک‌سازی حافظه هنگام خروج بسیار جدی است و واقعاً تلاش می‌کند تک‌تک اشیاء را نابود کند."

msgid "If you want to force Python to delete certain things on deallocation use the :mod:`atexit` module to run a function that will force those deletions."

msgstr "اگر می‌خواهید پایتون را وادار به حذف موارد مشخصی در زمان آزادسازی حافظه کنید، از ماژول :mod:`atexit` برای اجرای تابعی استفاده کنید که آن حذف‌ها را اجباری خواهد کرد."

msgid "Why are there separate tuple and list data types?"

msgstr "چرا انواع داده‌ی جداگانه‌ای برای تاپل و فهرست وجود دارند؟"

msgid "Lists and tuples, while similar in many respects, are generally used in fundamentally different ways. Tuples can be thought of as being similar to Pascal ``records`` or C ``structs``; they're small collections of related data which may be of different types which are operated on as a group. For example, a Cartesian coordinate is appropriately represented as a tuple of two or three numbers."

msgstr "فهرست‌ها و تاپل‌ها، با وجود شباهت‌های زیاد، معمولاً به‌طور بنیادین به شیوه‌های متفاوتی استفاده می‌شوند. می‌توان تاپل‌ها را مشابه ``records`` در پاسکال یا ``structs`` در C در نظر گرفت؛ آن‌ها مجموعه‌های کوچکی از داده‌های مرتبط هستند که ممکن است از انواع مختلفی باشند و به‌عنوان یک گروه بر روی آن‌ها عملیات انجام می‌شود. برای مثال، یک مختصات دکارتی به‌طور مناسب به‌صورت یک تاپل از ۲ یا ۳ عدد نمایش داده می‌شود."

msgid "Lists, on the other hand, are more like arrays in other languages. They tend to hold a varying number of objects all of which have the same type and which are operated on one-by-one. For example, :func:`os.listdir('.') <os.listdir>` returns a list of strings representing the files in the current directory. Functions which operate on this output would generally not break if you added another file or two to the directory."

msgstr "از سوی دیگر، فهرست‌ها بیشتر به آرایه‌ها در زبان‌های دیگر شبیه‌اند. آن‌ها معمولاً تعداد متغیری از شیءها را نگه می‌دارند که همگی نوع یکسانی دارند و یکی‌یکی روی آن‌ها عمل می‌شود. برای مثال، :func:`os.listdir('.') <os.listdir>` فهرستی از رشته‌ها را برمی‌گرداند که پرونده‌های پوشه جاری را نشان می‌دهند. توابعی که روی این خروجی عمل می‌کنند، معمولاً اگر یک یا دو پرونده دیگر به پوشه اضافه کنید، از کار نمی‌افتند."

msgid "Tuples are :term:`immutable`, meaning that once a tuple has been created, you can't replace any of its elements with a new value. Lists are :term:`mutable`, meaning that you can always change a list's elements. Only :term:`hashable` objects can be used as dictionary keys. Most immutable types are hashable, which is why tuples, but not lists, can be used as keys. Note, however, that a tuple is only hashable if all of its elements are hashable."

msgstr "تاپل‌ها :term:`تغییرناپذیر <immutable>` هستند، به این معنا که پس از ایجاد یک تاپل، نمی‌توانید هیچ‌یک از عناصر آن را با مقدار جدیدی جایگزین کنید. فهرست‌ها :term:`تغییرپذیر <mutable>` هستند، یعنی همیشه می‌توانید عناصر یک فهرست را تغییر دهید. فقط اشیاء :term:`هش‌پذیر <hashable>` می‌توانند به عنوان کلیدهای دیکشنری استفاده شوند. بیشتر انواع تغییرناپذیر هش‌پذیر هستند، و به همین دلیل است که تاپل‌ها (اما نه فهرست‌ها) می‌توانند به عنوان کلید استفاده شوند. با این حال، توجه داشته باشید که یک تاپل تنها زمانی هش‌پذیر است که تمام عناصر آن هش‌پذیر باشند."

msgid "How are lists implemented in CPython?"

msgstr "فهرست‌ها در CPython چگونه پیاده‌سازی شده‌اند؟"

msgid "CPython's lists are really variable-length arrays, not Lisp-style linked lists. The implementation uses a contiguous array of references to other objects, and keeps a pointer to this array and the array's length in a list head structure."

msgstr "فهرست‌های CPython در واقع آرایه‌هایی با طول متغیر هستند، نه فهرست‌های پیوندی به‌سبک Lisp. پیاده‌سازی از آرایه‌ای پیوسته از ارجاع‌ها به اشیاء دیگر استفاده می‌کند و یک اشاره‌گر به این آرایه و طول آرایه را در یک ساختار سر فهرست نگه می‌دارد."

msgid "This makes indexing a list ``a[i]`` an operation whose cost is independent of the size of the list or the value of the index."

msgstr "این باعث می‌شود که اندیس‌دهی به یک فهرست ``a[i]`` عملیاتی باشد که هزینه‌ی آن مستقل از اندازه‌ی فهرست یا مقدار اندیس است."

msgid "When items are appended or inserted, the array of references is resized. Some cleverness is applied to improve the performance of appending items repeatedly; when the array must be grown, some extra space is allocated so the next few times don't require an actual resize."

msgstr "هنگامی که آیتم‌ها افزوده یا درج می‌شوند، اندازه‌ی آرایه‌ی ارجاع‌ها تغییر می‌کند. تمهیداتی به کار گرفته شده است تا عملکرد افزودن مکرر آیتم‌ها بهبود یابد؛ هنگامی که آرایه باید بزرگ شود، مقداری فضای اضافی تخصیص داده می‌شود تا چند بار بعدی نیازی به تغییر اندازه‌ی واقعی نباشد."

msgid "See :ref:`time-complexity` for the costs of the various list operations."

msgstr "برای هزینه‌های عملیات‌های مختلف فهرست، به :ref:`time-complexity` مراجعه کنید."

msgid "How are dictionaries implemented in CPython?"

msgstr "دیکشنری‌ها در CPython چگونه پیاده‌سازی شده‌اند؟"

msgid "CPython's dictionaries are implemented as resizable hash tables. Compared to B-trees, this gives better performance for lookup (the most common operation by far) under most circumstances, and the implementation is simpler."

msgstr "دیکشنری‌های CPython به‌صورت جدول‌های هش با قابلیت تغییر اندازه پیاده‌سازی شده‌اند. در مقایسه با درخت‌های B، این روش در بیشتر شرایط عملکرد بهتری برای جستجو (رایج‌ترین عملیات با اختلاف زیاد) ارائه می‌دهد و پیاده‌سازی ساده‌تری دارد."

msgid "Dictionaries work by computing a hash code for each key stored in the dictionary using the :func:`hash` built-in function. The hash code varies widely depending on the key and a per-process seed; for example, ``'Python'`` could hash to ``-539294296`` while ``'python'``, a string that differs by a single bit, could hash to ``1142331976``. The hash code is then used to calculate a location in an internal array where the value will be stored. Assuming that you're storing keys that all have different hash values, this means that dictionaries take constant time -- *O*\\ (1), in Big-O notation -- to retrieve a key."

msgstr "دیکشنری‌ها با محاسبه‌ی کد هش (hash code) برای هر کلید ذخیره‌شده در دیکشنری، از طریق تابع توکار :func:`hash` کار می‌کنند. کد هش بسته به کلید و یک بذر به‌ازای هر فرایند، تفاوت زیادی دارد؛ برای مثال، کد هش ``'Python'`` می‌تواند ``-539294296`` باشد، در حالی که کد هش ``'python'``، رشته‌ای که تنها یک بیت تفاوت دارد، می‌تواند ``1142331976`` باشد. سپس از کد هش برای محاسبه‌ی محلی در یک آرایه‌ی داخلی استفاده می‌شود که مقدار در آن ذخیره خواهد شد. با فرض این‌که شما کلیدهایی را ذخیره می‌کنید که همگی مقادیر هش متفاوتی دارند، این بدان معناست که دیکشنری‌ها برای بازیابی یک کلید به زمان ثابت -- *O*\\ (1)، در نمادگذاری Big-O -- نیاز دارند."

msgid "See :ref:`time-complexity` for the costs of the various dictionary operations."

msgstr "برای هزینه‌های عملیات‌های مختلف دیکشنری، به :ref:`time-complexity` مراجعه کنید."

msgid "Why must dictionary keys be immutable?"

msgstr "چرا کلیدهای دیکشنری باید تغییرناپذیر باشند؟"

msgid "The hash table implementation of dictionaries uses a hash value calculated from the key value to find the key. If the key were a mutable object, its value could change, and thus its hash could also change. But since whoever changes the key object can't tell that it was being used as a dictionary key, it can't move the entry around in the dictionary. Then, when you try to look up the same object in the dictionary it won't be found because its hash value is different. If you tried to look up the old value it wouldn't be found either, because the value of the object found in that hash bin would be different."

msgstr "پیاده‌سازی جدول هش دیکشنری‌ها از یک مقدار هش محاسبه‌شده از مقدار کلید برای پیدا کردن کلید استفاده می‌کند. اگر کلید یک شیء تغییرپذیر باشد، ممکن است مقدار آن تغییر کند و در نتیجه هش آن نیز ممکن است تغییر کند. اما از آنجا که هرکسی که شیء کلید را تغییر می‌دهد نمی‌تواند تشخیص دهد که از آن به‌عنوان کلید دیکشنری استفاده می‌شده است، نمی‌تواند آیتم را در دیکشنری جابه‌جا کند. سپس، وقتی سعی کنید همان شیء را در دیکشنری جستجو کنید، پیدا نخواهد شد، زیرا مقدار هش آن متفاوت است. اگر سعی کنید مقدار قدیمی را جستجو کنید، آن هم پیدا نخواهد شد، زیرا مقدار شیء یافت‌شده در آن سطل هش (hash bin) متفاوت خواهد بود."

msgid "If you want a dictionary indexed with a list, simply convert the list to a tuple first; the function ``tuple(L)`` creates a tuple with the same entries as the list ``L``. Tuples are immutable and can therefore be used as dictionary keys."

msgstr "اگر دیکشنری‌ای می‌خواهید که با فهرست اندیس‌دهی شده باشد، کافی است ابتدا فهرست را به تاپل تبدیل کنید؛ تابع ``tuple(L)`` تاپلی با همان آیتم‌های فهرست ``L`` می‌سازد. تاپل‌ها تغییرناپذیرند و بنابراین می‌توانند به‌عنوان کلیدهای دیکشنری استفاده شوند."

msgid "Some unacceptable solutions that have been proposed:"

msgstr "برخی راه‌حل‌های غیرقابل‌قبول که پیشنهاد شده‌اند:"

msgid "Hash lists by their address (object ID). This doesn't work because if you construct a new list with the same value it won't be found; e.g.::"

msgstr "هش کردن فهرست‌ها بر اساس نشانی‌شان (شناسه‌ی شیء). این روش کار نمی‌کند، زیرا اگر فهرست جدیدی با همان مقدار ایجاد کنید، پیدا نخواهد شد؛ برای مثال::"

msgid ""

msgstr ""

msgid "would raise a :exc:`KeyError` exception because the id of the ``[1, 2]`` used in the second line differs from that in the first line. In other words, dictionary keys should be compared using ``==``, not using :keyword:`is`."

msgstr "استثنای :exc:`KeyError` را پرتاب می‌کند، زیرا شناسه‌ی ``[1, 2]`` استفاده‌شده در خط دوم با شناسه‌ی آن در خط اول متفاوت است. به عبارت دیگر، کلیدهای دیکشنری باید با استفاده از ``==`` مقایسه شوند، نه با استفاده از :keyword:`is`."

msgid "Make a copy when using a list as a key. This doesn't work because the list, being a mutable object, could contain a reference to itself, and then the copying code would run into an infinite loop."

msgstr "هنگام استفاده از یک فهرست به‌عنوان کلید، یک کپی بسازید. این روش کار نمی‌کند، زیرا فهرست به‌عنوان یک شیء تغییرپذیر می‌تواند شامل ارجاعی به خودش باشد و در آن صورت کد کپی‌سازی وارد یک حلقه بی‌پایان می‌شود."

msgid "Allow lists as keys but tell the user not to modify them. This would allow a class of hard-to-track bugs in programs when you forgot or modified a list by accident. It also invalidates an important invariant of dictionaries: every value in ``d.keys()`` is usable as a key of the dictionary."

msgstr "اجازه دهید فهرست‌ها به‌عنوان کلید استفاده شوند، اما به کاربر بگویید آن‌ها را تغییر ندهد. هنگامی که فراموش کنید یا فهرستی را به‌اشتباه تغییر دهید، این کار موجب ایجاد دسته‌ای از باگ‌ها در برنامه‌ها می‌شود که پیگیری آن‌ها دشوار است. همچنین یک ناوردا مهم دیکشنری‌ها را باطل می‌کند: هر مقدار موجود در ``d.keys()`` را می‌توان به‌عنوان کلید دیکشنری استفاده کرد."

msgid "Mark lists as read-only once they are used as a dictionary key. The problem is that it's not just the top-level object that could change its value; you could use a tuple containing a list as a key. Entering anything as a key into a dictionary would require marking all objects reachable from there as read-only -- and again, self-referential objects could cause an infinite loop."

msgstr "فهرست‌ها را به‌محض استفاده از آن‌ها به‌عنوان کلید دیکشنری، فقط‌خواندنی علامت‌گذاری کنید. مشکل این است که تنها شیء سطح‌بالا نیست که ممکن است مقدارش تغییر کند؛ شما می‌توانید از یک تاپل حاوی یک فهرست به‌عنوان کلید استفاده کنید. وارد کردن هر چیز به‌عنوان کلید در یک دیکشنری، مستلزم علامت‌گذاری تمام اشیای قابل‌دسترس از آنجا به‌عنوان فقط‌خواندنی است — و باز هم، اشیای خودارجاع می‌توانند باعث ایجاد یک حلقه بی‌پایان شوند."

msgid "There is a trick to get around this if you need to, but use it at your own risk: You can wrap a mutable structure inside a class instance which has both a :meth:`~object.__eq__` and a :meth:`~object.__hash__` method. You must then make sure that the hash value for all such wrapper objects that reside in a dictionary (or other hash based structure), remain fixed while the object is in the dictionary (or other structure). ::"

msgstr "ترفندی برای دور زدن این موضوع وجود دارد که در صورت نیاز می‌توانید از آن استفاده کنید، اما با مسئولیت خودتان: می‌توانید یک ساختار تغییرپذیر را درون یک نمونه کلاس بپیچید که هر دو متد :meth:`~object.__eq__` و :meth:`~object.__hash__` را دارد. سپس باید اطمینان حاصل کنید که مقدار هش برای همه اشیاء پوششی از این قبیل که در یک دیکشنری (یا ساختار مبتنی بر هش دیگر) قرار دارند، تا زمانی که شیء در دیکشنری (یا ساختار دیگر) است، ثابت بماند. ::"

msgid ""

msgstr ""

msgid "Note that the hash computation is complicated by the possibility that some members of the list may be unhashable and also by the possibility of arithmetic overflow."

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

msgid "Furthermore it must always be the case that if ``o1 == o2`` (ie ``o1.__eq__(o2) is True``) then ``hash(o1) == hash(o2)`` (ie, ``o1.__hash__() == o2.__hash__()``), regardless of whether the object is in a dictionary or not. If you fail to meet these restrictions dictionaries and other hash based structures will misbehave."

msgstr "علاوه بر این، همیشه باید اگر ``o1 == o2`` (یعنی ``o1.__eq__(o2) is True``)، آنگاه ``hash(o1) == hash(o2)`` (یعنی ``o1.__hash__() == o2.__hash__()``) برقرار باشد، صرف‌نظر از این‌که شیء در یک دیکشنری باشد یا نه. اگر این محدودیت‌ها را رعایت نکنید، دیکشنری‌ها و سایر ساختارهای مبتنی بر هش به‌درستی کار نخواهند کرد."

msgid "In the case of :class:`!ListWrapper`, whenever the wrapper object is in a dictionary the wrapped list must not change to avoid anomalies. Don't do this unless you are prepared to think hard about the requirements and the consequences of not meeting them correctly. Consider yourself warned."

msgstr "در مورد :class:`!ListWrapper`، هر گاه شیء پوششی در یک دیکشنری باشد، فهرست پوشیده‌شده نباید تغییر کند تا از ناهنجاری‌ها جلوگیری شود. این کار را انجام ندهید مگر آنکه آماده باشید تا درباره الزامات و پیامدهای برآورده نکردن صحیح آن‌ها به‌دقت بیندیشید. خود را هشدار داده‌شده بدانید."

msgid "Why doesn't list.sort() return the sorted list?"

msgstr "چرا list.sort() فهرست مرتب‌شده را برنمی‌گرداند؟"

msgid "In situations where performance matters, making a copy of the list just to sort it would be wasteful. Therefore, :meth:`list.sort` sorts the list in place. In order to remind you of that fact, it does not return the sorted list. This way, you won't be fooled into accidentally overwriting a list when you need a sorted copy but also need to keep the unsorted version around."

msgstr "در موقعیت‌هایی که کارایی اهمیت دارد، ساختن یک کپی از فهرست صرفاً برای مرتب‌سازی آن، اتلاف منابع خواهد بود. بنابراین، :meth:`list.sort` فهرست را درجا مرتب می‌کند. برای یادآوری همین موضوع، فهرست مرتب‌شده را برنمی‌گرداند. به این ترتیب، وقتی به یک کپی مرتب‌شده نیاز دارید اما همزمان باید نسخه‌ی مرتب‌نشده را نیز نگه دارید، دچار این اشتباه نخواهید شد که به‌طور تصادفی یک فهرست را بازنویسی کنید."

msgid "If you want to return a new list, use the built-in :func:`sorted` function instead. This function creates a new list from a provided iterable, sorts it and returns it. For example, here's how to iterate over the keys of a dictionary in sorted order::"

msgstr "اگر می‌خواهید یک فهرست جدید برگردانید، به‌جای آن از تابع توکار :func:`sorted` استفاده کنید. این تابع از یک پیمایش‌پذیر ارائه‌شده یک فهرست جدید ایجاد می‌کند، آن را مرتب می‌کند و برمی‌گرداند. برای مثال، در اینجا چگونگی پیمایش روی کلیدهای یک دیکشنری با ترتیب مرتب‌شده آمده است::"

msgid ""

msgstr ""

msgid "How do you specify and enforce an interface spec in Python?"

msgstr "چگونه مشخصات یک رابط را در پایتون تعیین و اعمال می‌کنید؟"

msgid "An interface specification for a module as provided by languages such as C++ and Java describes the prototypes for the methods and functions of the module. Many feel that compile-time enforcement of interface specifications helps in the construction of large programs."

msgstr "مشخصات رابط برای یک ماژول، همان‌طور که توسط زبان‌هایی مانند C++ و Java ارائه می‌شود، پیش‌نمونه‌های متدها و توابع آن ماژول را توصیف می‌کند. بسیاری بر این باورند که اعمال مشخصات رابط در زمان کامپایل، به ساخت برنامه‌های بزرگ کمک می‌کند."

msgid "Python 2.6 adds an :mod:`abc` module that lets you define Abstract Base Classes (ABCs). You can then use :func:`isinstance` and :func:`issubclass` to check whether an instance or a class implements a particular ABC. The :mod:`collections.abc` module defines a set of useful ABCs such as :class:`~collections.abc.Iterable`, :class:`~collections.abc.Container`, and :class:`~collections.abc.MutableMapping`."

msgstr "پایتون 2.6 ماژول :mod:`abc` را اضافه می‌کند که به شما امکان می‌دهد کلاس‌های پایه انتزاعی (ABCs) را تعریف کنید. سپس می‌توانید از :func:`isinstance` و :func:`issubclass` برای بررسی اینکه آیا یک نمونه یا کلاس یک ABC خاص را پیاده‌سازی می‌کند، استفاده کنید. ماژول :mod:`collections.abc` مجموعه‌ای از ABCهای مفید را تعریف می‌کند، مانند :class:`~collections.abc.Iterable`، :class:`~collections.abc.Container` و :class:`~collections.abc.MutableMapping`."

msgid "For Python, many of the advantages of interface specifications can be obtained by an appropriate test discipline for components."

msgstr "در پایتون، بسیاری از مزایای مشخصات رابط را می‌توان با نظم آزمون مناسب برای کامپوننت‌ها به دست آورد."

msgid "A good test suite for a module can both provide a regression test and serve as a module interface specification and a set of examples. Many Python modules can be run as a script to provide a simple \"self test.\" Even modules which use complex external interfaces can often be tested in isolation using trivial \"stub\" emulations of the external interface. The :mod:`doctest` and :mod:`unittest` modules or third-party test frameworks can be used to construct exhaustive test suites that exercise every line of code in a module."

msgstr "یک بدنه آزمون خوب برای یک ماژول می‌تواند هم یک آزمون رگرسیون فراهم کند و هم به‌عنوان مشخصات رابط ماژول و مجموعه‌ای از مثال‌ها عمل کند. بسیاری از ماژول‌های پایتون می‌توانند به‌صورت یک اسکریپت اجرا شوند تا یک «خودآزمایی» ساده فراهم کنند. حتی ماژول‌هایی که از رابط‌های خارجی پیچیده استفاده می‌کنند، اغلب می‌توانند با استفاده از stub ساده برای رابط خارجی، به‌صورت مجزا آزمون شوند. می‌توان از ماژول‌های :mod:`doctest` و :mod:`unittest` یا چارچوب‌های آزمون شخص ثالث برای ساخت بدنه‌های آزمون جامعی استفاده کرد که هر خط از کد یک ماژول را اجرا می‌کنند."

msgid "An appropriate testing discipline can help build large complex applications in Python as well as having interface specifications would. In fact, it can be better because an interface specification cannot test certain properties of a program. For example, the :meth:`list.append` method is expected to add new elements to the end of some internal list; an interface specification cannot test that your :meth:`list.append` implementation will actually do this correctly, but it's trivial to check this property in a test suite."

msgstr "یک رویه مناسب آزمون، همان‌طور که داشتن مشخصات رابط کمک می‌کند، می‌تواند به ساخت برنامه‌های بزرگ و پیچیده در پایتون کمک کند. در واقع، می‌تواند بهتر باشد، زیرا مشخصات رابط نمی‌تواند برخی از ویژگی‌های یک برنامه را آزمون کند. برای مثال، انتظار می‌رود متد :meth:`list.append` عناصر جدید را به انتهای یک فهرست داخلی اضافه کند؛ مشخصات رابط نمی‌تواند آزمون کند که پیاده‌سازی :meth:`list.append` شما واقعاً این کار را به‌درستی انجام خواهد داد، اما بررسی این ویژگی در یک بدنه آزمون بسیار ساده است."

msgid "Writing test suites is very helpful, and you might want to design your code to make it easily tested. One increasingly popular technique, test-driven development, calls for writing parts of the test suite first, before you write any of the actual code. Of course Python allows you to be sloppy and not write test cases at all."

msgstr "نوشتن بدنه‌های آزمون بسیار مفید است، و شاید بخواهید کد خود را به‌گونه‌ای طراحی کنید که به‌راحتی آزمون شود. یکی از تکنیک‌هایی که به‌طور فزاینده‌ای محبوب شده است، توسعه آزمون‌محور است که ایجاب می‌کند ابتدا بخش‌هایی از بدنه آزمون را بنویسید، پیش از آنکه هیچ‌یک از کد واقعی را بنویسید. البته پایتون به شما اجازه می‌دهد که سهل‌انگار باشید و اصلاً هیچ مورد آزمونی ننویسید."

msgid "Why is there no goto?"

msgstr "چرا goto وجود ندارد؟"

msgid "In the 1970s people realized that unrestricted goto could lead to messy \"spaghetti\" code that was hard to understand and revise. In a high-level language, it is also unneeded as long as there are ways to branch (in Python, with :keyword:`if` statements and :keyword:`or`, :keyword:`and`, and :keyword:`if`/:keyword:`else` expressions) and loop (with :keyword:`while` and :keyword:`for` statements, possibly containing :keyword:`continue` and :keyword:`break`)."

msgstr "در دهه‌ی ۱۹۷۰، مشخص شد که goto بدون محدودیت می‌توانست به کد آشفته‌ی «اسپاگتی» منجر شود که درک و اصلاح آن دشوار بود. در یک زبان سطح بالا نیز، تا زمانی که راه‌هایی برای انشعاب (در پایتون، با دستورهای :keyword:`if` و عبارت‌های :keyword:`or`، :keyword:`and` و :keyword:`if`/:keyword:`else`) و حلقه (با دستورهای :keyword:`while` و :keyword:`for`، که ممکن است شامل :keyword:`continue` و :keyword:`break` باشند) وجود داشته باشد، نیازی به آن نیست."

msgid "One can also use exceptions to provide a \"structured goto\" that works even across function calls. Many feel that exceptions can conveniently emulate all reasonable uses of the ``go`` or ``goto`` constructs of C, Fortran, and other languages. For example::"

msgstr "همچنین می‌توان از استثناها برای فراهم کردن یک «goto ساختاریافته» استفاده کرد که حتی میان فراخوانی‌های تابع نیز کار می‌کند. بسیاری بر این باورند که استثناها می‌توانند به‌راحتی تمام استفاده‌های معقول از ساختارهای ``go`` یا ``goto`` در C، Fortran و زبان‌های دیگر را شبیه‌سازی کنند. برای مثال::"

msgid ""

msgstr ""

msgid "This doesn't allow you to jump into the middle of a loop, but that's usually considered an abuse of ``goto`` anyway. Use sparingly."

msgstr "این به شما اجازه نمی‌دهد به وسط یک حلقه بپرید، اما به هر حال چنین کاری معمولاً سوءاستفاده از ``goto`` تلقی می‌شود. با احتیاط استفاده کنید."

msgid "Why can't raw strings (r-strings) end with a backslash?"

msgstr "چرا رشته‌های خام (r-strings) نمی‌توانند با بک‌اسلش پایان یابند؟"

msgid "More precisely, they can't end with an odd number of backslashes: the unpaired backslash at the end escapes the closing quote character, leaving an unterminated string."

msgstr "دقیق‌تر، آن‌ها نمی‌توانند با تعداد فردی از بک‌اسلش‌ها پایان یابند: بک‌اسلش جفت‌نشده در انتها، نویسه‌ی علامت نقل‌قول پایانی را خنثی می‌کند و باعث می‌شود رشته‌ای پایان‌نیافته باقی بماند."

msgid "Raw strings were designed to ease creating input for processors (chiefly regular expression engines) that want to do their own backslash escape processing. Such processors consider an unmatched trailing backslash to be an error anyway, so raw strings disallow that. In return, they allow you to pass on the string quote character by escaping it with a backslash. These rules work well when r-strings are used for their intended purpose."

msgstr "رشته‌های خام برای آسان‌تر کردن ایجاد ورودی برای پردازنده‌هایی (عمدتاً موتورهای عبارت باقاعده) طراحی شده‌اند که می‌خواهند پردازش خنثی‌سازی بک‌اسلش خودشان را انجام دهند. این پردازنده‌ها در هر حال یک بک‌اسلش انتهایی بدون تطابق را خطا می‌دانند، بنابراین رشته‌های خام آن را مجاز نمی‌شمارند. در عوض، به شما اجازه می‌دهند که نویسه‌ی نقل‌قول رشته را با خنثی کردن آن به‌وسیله‌ی یک بک‌اسلش منتقل کنید. این قوانین زمانی که رشته‌های r برای هدف مورد نظرشان استفاده شوند، به‌خوبی کار می‌کنند."

msgid "If you're trying to build Windows pathnames, note that all Windows system calls accept forward slashes too::"

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

msgid "f = open(\"/mydir/file.txt\") # works fine!"

msgstr "f = open(\"/mydir/file.txt\") # به‌درستی کار می‌کند!"

msgid "If you're trying to build a pathname for a DOS command, try e.g. one of ::"

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

msgid ""

msgstr ""

msgid "Why doesn't Python have a \"with\" statement for attribute assignments?"

msgstr "چرا پایتون یک دستور \"with\" برای انتساب ویژگی‌ها ندارد؟"

msgid "Python has a :keyword:`with` statement that wraps the execution of a block, calling code on the entrance and exit from the block. Some languages have a construct that looks like this::"

msgstr "پایتون یک دستور :keyword:`with` دارد که اجرای یک بلوک را دربر می‌گیرد و کدی را در هنگام ورود به بلوک و خروج از آن فراخوانی می‌کند. برخی زبان‌ها ساختاری دارند که به این شکل است::"

msgid ""

msgstr ""

msgid "In Python, such a construct would be ambiguous."

msgstr "در پایتون، چنین ساختاری مبهم خواهد بود."

msgid "Other languages, such as Object Pascal, Delphi, and C++, use static types, so it's possible to know, in an unambiguous way, what member is being assigned to. This is the main point of static typing -- the compiler *always* knows the scope of every variable at compile time."

msgstr "زبان‌های دیگر، مانند Object Pascal، Delphi و C++، از انواع ایستا استفاده می‌کنند، بنابراین می‌توان به‌شکلی بدون ابهام دانست که به کدام عضو انتساب صورت می‌گیرد. این نکته اصلی نوع‌دهی ایستا است — کامپایلر *همیشه* محدوده هر متغیر را در زمان کامپایل می‌داند."

msgid "Python uses dynamic types. It is impossible to know in advance which attribute will be referenced at runtime. Member attributes may be added or removed from objects on the fly. This makes it impossible to know, from a simple reading, what attribute is being referenced: a local one, a global one, or a member attribute?"

msgstr "پایتون از انواع پویا استفاده می‌کند. نمی‌توان از قبل دانست که در ران‌تایم به کدام ویژگی ارجاع داده خواهد شد. ویژگی‌های عضو ممکن است در لحظه به شیء‌ها اضافه یا از آن‌ها حذف شوند. این موضوع باعث می‌شود نتوان از یک خواندن ساده فهمید که به کدام ویژگی ارجاع داده می‌شود: یک ویژگی محلی، یک ویژگی سراسری، یا یک ویژگی عضو؟"

msgid "For instance, take the following incomplete snippet::"

msgstr "برای مثال، قطعه‌کد ناقص زیر را در نظر بگیرید::"

msgid ""

msgstr ""

msgid "The snippet assumes that ``a`` must have a member attribute called ``x``. However, there is nothing in Python that tells the interpreter this. What should happen if ``a`` is, let us say, an integer? If there is a global variable named ``x``, will it be used inside the :keyword:`with` block? As you see, the dynamic nature of Python makes such choices much harder."

msgstr "این قطعه کد فرض می‌کند که ``a`` باید یک ویژگی عضو به نام ``x`` داشته باشد. با این حال، هیچ چیزی در پایتون وجود ندارد که این موضوع را به مفسر بگوید. اگر ``a``، مثلاً، یک عدد صحیح باشد، چه اتفاقی باید بیفتد؟ اگر یک متغیر سراسری به نام ``x`` وجود داشته باشد، آیا در داخل بلوک :keyword:`with` از آن استفاده خواهد شد؟ همان‌طور که می‌بینید، ماهیت پویای پایتون چنین انتخاب‌هایی را بسیار دشوارتر می‌کند."

msgid "The primary benefit of :keyword:`with` and similar language features (reduction of code volume) can, however, easily be achieved in Python by assignment. Instead of::"

msgstr "با این حال، مزیت اصلی :keyword:`with` و ویژگی‌های زبانی مشابه (کاهش حجم کد) را می‌توان به‌راحتی در پایتون با انتساب به دست آورد. به‌جای::"

msgid ""

msgstr ""

msgid "write this::"

msgstr "این را بنویسید::"

msgid ""

msgstr ""

msgid "This also has the side-effect of increasing execution speed because name bindings are resolved at run-time in Python, and the second version only needs to perform the resolution once."

msgstr "این موضوع همچنین اثر جانبی افزایش سرعت اجرا را دارد، زیرا پیوندهای نام (name bindings) در پایتون در ران‌تایم حل می‌شوند و نسخه دوم تنها لازم است این حل را یک بار انجام دهد."

msgid "Similar proposals that would introduce syntax to further reduce code volume, such as using a 'leading dot', have been rejected in favour of explicitness (see https://mail.python.org/pipermail/python-ideas/2016-May/040070.html)."

msgstr "پیشنهادهای مشابهی که سینتکسی را برای کاهش بیشتر حجم کد معرفی می‌کردند، مانند استفاده از «نقطه آغازین»، به نفع صراحت رد شده‌اند (به https://mail.python.org/pipermail/python-ideas/2016-May/040070.html مراجعه کنید)."

msgid "Why don't generators support the with statement?"

msgstr "چرا تولیدگرها از دستور with پشتیبانی نمی‌کنند؟"

msgid "For technical reasons, a generator used directly as a context manager would not work correctly. When, as is most common, a generator is used as an iterator run to completion, no closing is needed. When it is, wrap it as :func:`contextlib.closing(generator) <contextlib.closing>` in the :keyword:`with` statement."

msgstr "به دلایل فنی، تولیدگری که به‌طور مستقیم به‌عنوان مدیر زمینه استفاده شود، به‌درستی کار نخواهد کرد. هنگامی که، همان‌طور که رایج‌ترین حالت است، یک تولیدگر به‌عنوان پیمایش‌گری استفاده می‌شود که تا پایان اجرا می‌شود، نیازی به بستن نیست. هرگاه لازم باشد، آن را در دستور :keyword:`with` به‌صورت :func:`contextlib.closing(generator) <contextlib.closing>` قرار دهید."

msgid "Why are colons required for the if/while/def/class statements?"

msgstr "چرا دونقطه‌ها برای دستورات if/while/def/class الزامی هستند؟"

msgid "The colon is required primarily to enhance readability (one of the results of the experimental ABC language). Consider this::"

msgstr "دونقطه عمدتاً برای افزایش خوانایی لازم است (یکی از نتایج زبان آزمایشی ABC). این را در نظر بگیرید::"

msgid ""

msgstr ""

msgid "versus ::"

msgstr "در مقایسه با ::"

msgid ""

msgstr ""

msgid "Notice how the second one is slightly easier to read. Notice further how a colon sets off the example in this FAQ answer; it's a standard usage in English."

msgstr "توجه کنید که چگونه مورد دوم کمی آسان‌تر خوانده می‌شود. همچنین توجه کنید که چگونه یک دونقطه مثال را در این پاسخِ پرسش‌های متداول جدا می‌کند؛ این یک کاربرد استاندارد در زبان انگلیسی است."

msgid "Another minor reason is that the colon makes it easier for editors with syntax highlighting; they can look for colons to decide when indentation needs to be increased instead of having to do a more elaborate parsing of the program text."

msgstr "دلیل فرعی دیگر این است که دونقطه کار را برای ویرایشگرهای دارای برجسته‌سازی سینتکس آسان‌تر می‌کند؛ آن‌ها می‌توانند به‌دنبال دونقطه‌ها بگردند تا تشخیص دهند چه زمانی تورفتگی باید افزایش یابد، به‌جای این‌که مجبور باشند تجزیه پیچیده‌تری از متن برنامه انجام دهند."

msgid "Why does Python allow commas at the end of lists and tuples?"

msgstr "چرا پایتون اجازه می‌دهد در انتهای فهرست‌ها و تاپل‌ها کاما وجود داشته باشد؟"

msgid "Python lets you add a trailing comma at the end of lists, tuples, and dictionaries::"

msgstr "پایتون به شما امکان می‌دهد یک کامای پایانی را در انتهای فهرست‌ها، تاپل‌ها و دیکشنری‌ها اضافه کنید::"

msgid ""

msgstr ""

msgid "There are several reasons to allow this."

msgstr "دلایل متعددی برای مجاز دانستن این وجود دارد."

msgid "When you have a literal value for a list, tuple, or dictionary spread across multiple lines, it's easier to add more elements because you don't have to remember to add a comma to the previous line. The lines can also be reordered without creating a syntax error."

msgstr "هنگامی که یک مقدار لفظی برای فهرست، تاپل یا دیکشنری دارید که در چند خط پخش شده است، افزودن عناصر بیشتر آسان‌تر است، زیرا لازم نیست به خاطر بسپارید که باید یک ویرگول به خط قبلی اضافه کنید. همچنین می‌توان سطرها را بدون ایجاد خطای سینتکسی جابه‌جا کرد."

msgid "Accidentally omitting the comma can lead to errors that are hard to diagnose. For example::"

msgstr "حذف تصادفی کاما می‌تواند منجر به خطاهایی شود که اشکال‌زدایی آن‌ها دشوار است. برای مثال::"

msgid ""

msgstr ""

msgid "This list looks like it has four elements, but it actually contains three: \"fee\", \"fiefoo\" and \"fum\". Always adding the comma avoids this source of error."

msgstr "این فهرست به نظر می‌رسد چهار عنصر دارد، اما در واقع شامل سه عنصر است: \"fee\"، \"fiefoo\" و \"fum\". افزودن همیشگی ویرگول از این منبع خطا جلوگیری می‌کند."

msgid "Allowing the trailing comma may also make programmatic code generation easier."

msgstr "مجاز بودن کامای پایانی همچنین ممکن است تولید کد به‌صورت برنامه‌ای را آسان‌تر کند."