2.2.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001 Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
# Translators:
# Alireza Shabani (Revisto) <theRevisto@gmail.com>, 2025
# Danial Behzadi <dani.behzi@ubuntu.com>, 2025
# Rafael Fontenelle <rffontenelle@gmail.com>, 2025
# Sepehr Rasouli <sepehrrasouli06@gmail.com>, 2026
#
msgid ""
msgstr ""
"Project-Id-Version: Python 3.14\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-09-16 12:56+0000\n"
"PO-Revision-Date: 2026-09-14 13:45+0330\n"
"Last-Translator: Sepehr Rasouli <sepehrrasouli06@gmail.com>, 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 "What's New in Python 2.2"
msgstr "تازه‌های پایتون 2.2"

msgid "Author"
msgstr "نویسنده"

msgid "A.M. Kuchling"
msgstr "A.M. Kuchling"

msgid "Introduction"
msgstr "مقدمه"

msgid "This article explains the new features in Python 2.2.2, released on October 14, 2002.  Python 2.2.2 is a bugfix release of Python 2.2, originally released on December 21, 2001."
msgstr "این مقاله قابلیت‌های جدید پایتون 2.2.2 را که در ۱۴ اکتبر ۲۰۰۲ منتشر شده است، توضیح می‌دهد. پایتون 2.2.2 یک نسخه‌ی رفع اشکال از پایتون 2.2 است که نخستین‌بار در ۲۱ دسامبر ۲۰۰۱ منتشر شد."

msgid "Python 2.2 can be thought of as the \"cleanup release\".  There are some features such as generators and iterators that are completely new, but most of the changes, significant and far-reaching though they may be, are aimed at cleaning up irregularities and dark corners of the language design."
msgstr "می‌توان پایتون 2.2 را «نسخه‌ی پاک‌سازی» دانست. برخی قابلیت‌ها مانند تولیدگرها و پیمایش‌گرها کاملاً جدید هستند، اما بیشترِ تغییرات، هرچند مهم و گسترده باشند، با هدف پاک‌سازی ناهنجاری‌ها و گوشه‌های تاریک طراحی زبان صورت گرفته‌اند."

msgid "This article doesn't attempt to provide a complete specification of the new features, but instead provides a convenient overview.  For full details, you should refer to the documentation for Python 2.2, such as the `Python Library Reference <https://docs.python.org/2.2/lib/lib.html>`_ and the `Python Reference Manual <https://docs.python.org/2.2/ref/ref.html>`_.  If you want to understand the complete implementation and design rationale for a change, refer to the PEP for a particular new feature."
msgstr "این مقاله تلاش نمی‌کند مشخصات کاملی از ویژگی‌های جدید ارائه دهد، بلکه در عوض مروری مناسب ارائه می‌کند. برای جزئیات کامل، باید به مستندات پایتون 2.2 مانند `مرجع کتابخانه پایتون <https://docs.python.org/2.2/lib/lib.html>`_ و `راهنمای مرجع پایتون <https://docs.python.org/2.2/ref/ref.html>`_ مراجعه کنید. اگر می‌خواهید پیاده‌سازی کامل و منطق طراحی یک تغییر را درک کنید، به PEP (پیشنهاد بهبود پایتون) مربوط به ویژگی جدید مورد نظر مراجعه کنید."

msgid "PEPs 252 and 253: Type and Class Changes"
msgstr "PEP‌های 252 و 253: تغییرات نوع و کلاس"

msgid "The largest and most far-reaching changes in Python 2.2 are to Python's model of objects and classes.  The changes should be backward compatible, so it's likely that your code will continue to run unchanged, but the changes provide some amazing new capabilities. Before beginning this, the longest and most complicated section of this article, I'll provide an overview of the changes and offer some comments."
msgstr "بزرگ‌ترین و فراگیرترین تغییرات در پایتون 2.2 مربوط به مدل شیءها و کلاس‌های پایتون است. این تغییرات باید سازگار به عقب باشند، بنابراین به احتمال زیاد کد شما بدون تغییر به کار خود ادامه خواهد داد، اما این تغییرات چند قابلیت جدید شگفت‌انگیز فراهم می‌کنند. پیش از شروع این بخش — طولانی‌ترین و پیچیده‌ترین بخش این مقاله — مروری کلی بر تغییرات ارائه خواهم داد و چند نکته نیز مطرح خواهم کرد."

msgid "A long time ago I wrote a web page listing flaws in Python's design.  One of the most significant flaws was that it's impossible to subclass Python types implemented in C.  In particular, it's not possible to subclass built-in types, so you can't just subclass, say, lists in order to add a single useful method to them. The :mod:`!UserList` module provides a class that supports all of the methods of lists and that can be subclassed further, but there's lots of C code that expects a regular Python list and won't accept a :class:`~collections.UserList` instance."
msgstr "مدت‌ها پیش صفحه‌ای وب نوشتم که فهرستی از ایرادهای طراحی پایتون را در بر می‌گرفت. یکی از مهم‌ترین این ایرادها این بود که زیرکلاس‌سازی نوع‌های پایتون که در C پیاده‌سازی شده‌اند ناممکن است. به‌طور خاص، زیرکلاس‌سازی نوع‌های توکار ممکن نیست، بنابراین نمی‌توانید به‌سادگی مثلاً از فهرست‌ها زیرکلاس بگیرید تا تنها یک متد مفید به آن‌ها بیفزایید. ماژول :mod:`!UserList` کلاسی فراهم می‌کند که از تمام متدهای فهرست‌ها پشتیبانی می‌کند و می‌توان از آن زیرکلاس‌های بیشتری ساخت، اما کدهای C زیادی وجود دارند که انتظار یک فهرست معمولی پایتون را دارند و نمونه‌ی :class:`~collections.UserList` را نمی‌پذیرند."

msgid "Python 2.2 fixes this, and in the process adds some exciting new capabilities. A brief summary:"
msgstr "پایتون 2.2 این مشکل را برطرف می‌کند و در این فرایند، چند قابلیت جدید و هیجان‌انگیز اضافه می‌کند. خلاصه‌ای کوتاه:"

msgid "You can subclass built-in types such as lists and even integers, and your subclasses should work in every place that requires the original type."
msgstr "می‌توانید از انواع توکار مانند فهرست‌ها و حتی اعداد صحیح زیرکلاس بسازید، و زیرکلاس‌های شما باید در هر جایی که به نوع اصلی نیاز است، کار کنند."

msgid "It's now possible to define static and class methods, in addition to the instance methods available in previous versions of Python."
msgstr "اکنون می‌توان علاوه بر متد‌های نمونه که در نسخه‌های قبلی پایتون در دسترس بودند، متد‌های ایستا و متد‌های کلاس را نیز تعریف کرد."

msgid "It's also possible to automatically call methods on accessing or setting an instance attribute by using a new mechanism called :dfn:`properties`.  Many uses of :meth:`~object.__getattr__` can be rewritten to use properties instead, making the resulting code simpler and faster.  As a small side benefit, attributes can now have docstrings, too."
msgstr "همچنین می‌توان با استفاده از سازوکار جدیدی به نام :dfn:`پراپرتی‌ها (properties)`، متدها را هنگام دسترسی به یک ویژگی نمونه یا تنظیم آن به‌طور خودکار فراخوانی کرد.  بسیاری از کاربردهای :meth:`~object.__getattr__` را می‌توان بازنویسی کرد تا در عوض از پراپرتی‌ها استفاده کنند، که این امر کد حاصل را ساده‌تر و سریع‌تر می‌کند.  به‌عنوان یک مزیت جانبی کوچک، ویژگی‌ها اکنون می‌توانند رشته‌های مستند نیز داشته باشند."

msgid "The list of legal attributes for an instance can be limited to a particular set using :dfn:`slots`, making it possible to safeguard against typos and perhaps make more optimizations possible in future versions of Python."
msgstr "فهرست ویژگی‌های مجاز برای یک نمونه را می‌توان با استفاده از :dfn:`slots` به مجموعه‌ای خاص محدود کرد، که این امر هم امکان محافظت در برابر غلط‌های تایپی را فراهم می‌کند و هم شاید بهینه‌سازی‌های بیشتری را در نسخه‌های آینده‌ی پایتون ممکن می‌سازد."

msgid "Some users have voiced concern about all these changes.  Sure, they say, the new features are neat and lend themselves to all sorts of tricks that weren't possible in previous versions of Python, but they also make the language more complicated.  Some people have said that they've always recommended Python for its simplicity, and feel that its simplicity is being lost."
msgstr "برخی از کاربران درباره‌ی همه‌ی این تغییرات ابراز نگرانی کرده‌اند. البته، به گفته‌ی آن‌ها، قابلیت‌های جدید جالب هستند و امکان انجام انواع ترفندهایی را فراهم می‌کنند که در نسخه‌های قبلی پایتون ممکن نبود، اما در عین حال زبان را پیچیده‌تر نیز می‌کنند. برخی از افراد گفته‌اند که همیشه پایتون را به دلیل سادگی‌اش توصیه کرده‌اند و احساس می‌کنند که این سادگی در حال از دست رفتن است."

msgid "Personally, I think there's no need to worry.  Many of the new features are quite esoteric, and you can write a lot of Python code without ever needed to be aware of them.  Writing a simple class is no more difficult than it ever was, so you don't need to bother learning or teaching them unless they're actually needed.  Some very complicated tasks that were previously only possible from C will now be possible in pure Python, and to my mind that's all for the better."
msgstr "شخصاً فکر می‌کنم نیازی به نگرانی نیست. بسیاری از قابلیت‌های جدید کاملاً تخصصی و خاص هستند، و شما می‌توانید مقدار زیادی کد پایتون بنویسید بدون اینکه هرگز نیازی به آگاهی از آن‌ها داشته باشید. نوشتن یک کلاس ساده هیچ سخت‌تر از گذشته نیست، بنابراین لازم نیست زحمت یادگیری یا آموزش آن‌ها را بکشید، مگر اینکه واقعاً به آن‌ها نیاز باشد. برخی از کارهای بسیار پیچیده که پیش‌تر تنها از طریق C ممکن بودند، اکنون در پایتون خالص امکان‌پذیر خواهند بود، و به باور من، همه‌ی این‌ها چیز خوبی است."

msgid "I'm not going to attempt to cover every single corner case and small change that were required to make the new features work.  Instead this section will paint only the broad strokes.  See section :ref:`sect-rellinks`, \"Related Links\", for further sources of information about Python 2.2's new object model."
msgstr "قصد ندارم تلاش کنم تا تک‌تک حالت‌های گوشه‌ای (corner case) و تغییرات کوچکی را که برای کار کردن قابلیت‌های جدید لازم بودند، پوشش دهم. در عوض، این بخش تنها سطرهای کلی را ترسیم خواهد کرد. برای منابع اطلاعاتی بیشتر درباره‌ی مدل شیء جدید پایتون 2.2، بخش :ref:`sect-rellinks` با عنوان «پیوندهای مرتبط» را ببینید."

msgid "Old and New Classes"
msgstr "کلاس‌های قدیمی و جدید"

msgid "First, you should know that Python 2.2 really has two kinds of classes: classic or old-style classes, and new-style classes.  The old-style class model is exactly the same as the class model in earlier versions of Python.  All the new features described in this section apply only to new-style classes. This divergence isn't intended to last forever; eventually old-style classes will be dropped, possibly in Python 3.0."
msgstr "نخست باید بدانید که پایتون 2.2 در واقع دو نوع کلاس دارد: کلاس‌های کلاسیک یا سبک قدیمی، و کلاس‌های سبک جدید. مدل کلاس‌های سبک قدیمی دقیقاً همان مدل کلاس در نسخه‌های پیشین پایتون است. تمامی ویژگی‌های جدیدی که در این بخش شرح داده شده‌اند، تنها بر کلاس‌های سبک جدید اعمال می‌شوند. این واگرایی قرار نیست برای همیشه ادامه یابد؛ در نهایت کلاس‌های سبک قدیمی حذف خواهند شد، احتمالاً در پایتون 3.0."

msgid "So how do you define a new-style class?  You do it by subclassing an existing new-style class.  Most of Python's built-in types, such as integers, lists, dictionaries, and even files, are new-style classes now.  A new-style class named :class:`object`, the base class for all built-in types, has also been added so if no built-in type is suitable, you can just subclass :class:`object`::"
msgstr "پس چگونه یک کلاس سبک جدید تعریف می‌کنید؟ این کار را با زیرکلاس گرفتن از یک کلاس سبک جدید موجود انجام می‌دهید. بیشتر نوع‌های توکار پایتون، مانند اعداد صحیح، فهرست‌ها، دیکشنری‌ها و حتی پرونده‌ها، اکنون کلاس‌های سبک جدید هستند. یک کلاس سبک جدید با نام :class:`object`، که کلاس پایه‌ی همه‌ی نوع‌های توکار است، نیز اضافه شده است تا در صورتی که هیچ نوع توکاری مناسب نباشد، بتوانید به‌سادگی از :class:`object` زیرکلاس بگیرید::"

msgid ""
"class C(object):\n"
"    def __init__ (self):\n"
"        ...\n"
"    ..."
msgstr ""
"class C(object):\n"
"    def __init__ (self):\n"
"        ...\n"
"    ..."

msgid "This means that :keyword:`class` statements that don't have any base classes are always classic classes in Python 2.2.  (Actually you can also change this by setting a module-level variable named :attr:`!__metaclass__` --- see :pep:`253` for the details --- but it's easier to just subclass :class:`object`.)"
msgstr "این بدان معناست که دستورهای :keyword:`class` که هیچ کلاس پایه‌ای ندارند، در پایتون 2.2 همیشه کلاس‌های کلاسیک هستند.  (در واقع می‌توانید با تنظیم متغیری در سطح ماژول به نام :attr:`!__metaclass__` این موضوع را نیز تغییر دهید --- برای جزئیات به :pep:`253` مراجعه کنید --- اما آسان‌تر این است که صرفاً زیرکلاسی از :class:`object` بسازید.)"

msgid "The type objects for the built-in types are available as built-ins, named using a clever trick.  Python has always had built-in functions named :func:`int`, :func:`float`, and :func:`str`.  In 2.2, they aren't functions any more, but type objects that behave as factories when called. ::"
msgstr "اشیاء نوع برای نوع‌های توکار به‌صورت توکار در دسترس هستند و با استفاده از ترفندی هوشمندانه نام‌گذاری شده‌اند. پایتون همیشه توابع توکار با نام‌های :func:`int`، :func:`float` و :func:`str` داشته است. در نسخه‌ی 2.2، آن‌ها دیگر توابع نیستند، بلکه اشیاء نوع هستند که هنگام فراخوانی مانند کارخانه رفتار می‌کنند. ::"

msgid ""
">>> int\n"
"<type 'int'>\n"
">>> int('123')\n"
"123"
msgstr ""
">>> int\n"
"<type 'int'>\n"
">>> int('123')\n"
"123"

msgid "To make the set of types complete, new type objects such as :func:`dict` and :func:`!file` have been added.  Here's a more interesting example, adding a :meth:`!lock` method to file objects::"
msgstr "برای کامل شدن مجموعه‌ی انواع، اشیاء نوع جدیدی مانند :func:`dict` و :func:`!file` اضافه شده‌اند. در اینجا مثال جالب‌تری را می‌بینید که متد :meth:`!lock` را به اشیاء پرونده اضافه می‌کند::"

msgid ""
"class LockableFile(file):\n"
"    def lock (self, operation, length=0, start=0, whence=0):\n"
"        import fcntl\n"
"        return fcntl.lockf(self.fileno(), operation,\n"
"                           length, start, whence)"
msgstr ""
"class LockableFile(file):\n"
"    def lock (self, operation, length=0, start=0, whence=0):\n"
"        import fcntl\n"
"        return fcntl.lockf(self.fileno(), operation,\n"
"                           length, start, whence)"

msgid "The now-obsolete :mod:`!posixfile` module contained a class that emulated all of a file object's methods and also added a :meth:`!lock` method, but this class couldn't be passed to internal functions that expected a built-in file, something which is possible with our new :class:`!LockableFile`."
msgstr "ماژول :mod:`!posixfile` که اکنون منسوخ شده است، کلاسی داشت که تمام متدهای یک شیء پرونده را شبیه‌سازی می‌کرد و همچنین یک متد :meth:`!lock` اضافه می‌کرد، اما این کلاس را نمی‌شد به توابع داخلی‌ای که انتظار یک پرونده توکار را داشتند، پاس داد؛ امری که با :class:`!LockableFile` جدید ما امکان‌پذیر است."

msgid "Descriptors"
msgstr "توصیف‌گرها"

msgid "In previous versions of Python, there was no consistent way to discover what attributes and methods were supported by an object. There were some informal conventions, such as defining :attr:`!__members__` and :attr:`!__methods__` attributes that were lists of names, but often the author of an extension type or a class wouldn't bother to define them.  You could fall back on inspecting the :attr:`~object.__dict__` of an object, but when class inheritance or an arbitrary :meth:`!__getattr__` hook were in use this could still be inaccurate."
msgstr "در نسخه‌های پیشین پایتون، هیچ راه منسجمی برای کشف اینکه یک شیء از چه ویژگی‌ها و متدهایی پشتیبانی می‌کرد وجود نداشت. برخی قراردادهای غیررسمی وجود داشت، مانند تعریف ویژگی‌های :attr:`!__members__` و :attr:`!__methods__` که فهرست‌هایی از نام‌ها بودند، اما اغلب نویسنده‌ی یک نوع توسعه‌ای یا یک کلاس زحمت تعریف آن‌ها را به خود نمی‌داد. می‌توانستید به بررسی :attr:`~object.__dict__` یک شیء روی بیاورید، اما وقتی وراثت کلاسی یا یک قلاب دلخواه :meth:`!__getattr__` به کار می‌رفت، این روش همچنان می‌توانست نادرست باشد."

msgid "The one big idea underlying the new class model is that an API for describing the attributes of an object using :dfn:`descriptors` has been formalized. Descriptors specify the value of an attribute, stating whether it's a method or a field.  With the descriptor API, static methods and class methods become possible, as well as more exotic constructs."
msgstr "ایده‌ی بزرگ بنیادین مدل جدید کلاس این است که API‌ای برای توصیف ویژگی‌های یک شیء با استفاده از :dfn:`توصیف‌گرها (descriptors)` صورت‌بندی شده است. توصیف‌گرها مقدار یک ویژگی را مشخص می‌کنند و بیان می‌کنند که آیا این ویژگی یک متد است یا یک فیلد. با API توصیف‌گر، متدهای ایستا و متدهای کلاس، و همچنین ساختارهای غیرمعمول‌تری ممکن می‌شوند."

msgid "Attribute descriptors are objects that live inside class objects, and have a few attributes of their own:"
msgstr "توصیف‌گرهای ویژگی، اشیاءی هستند که درون اشیاء کلاس قرار می‌گیرند و چند ویژگی مخصوص به خود دارند:"

msgid ":attr:`~definition.__name__` is the attribute's name."
msgstr ":attr:`~definition.__name__` نام ویژگی است."

msgid ":attr:`~definition.__doc__` is the attribute's docstring."
msgstr ":attr:`~definition.__doc__` رشته مستند این ویژگی است."

msgid "``__get__(object)`` is a method that retrieves the attribute value from *object*."
msgstr "``__get__(object)`` متدی است که مقدار ویژگی را از *شیء* بازیابی می‌کند."

msgid "``__set__(object, value)`` sets the attribute on *object* to *value*."
msgstr "``__set__(object, value)`` ویژگی روی *object* را به *value* تنظیم می‌کند."

msgid "``__delete__(object, value)`` deletes the *value*  attribute of *object*."
msgstr "``__delete__(object, value)`` ویژگی *value* از *object* را حذف می‌کند."

msgid "For example, when you write ``obj.x``, the steps that Python actually performs are::"
msgstr "برای مثال، هنگامی که ``obj.x`` را می‌نویسید، گام‌هایی که پایتون در واقع انجام می‌دهد عبارت‌اند از::"

msgid ""
"descriptor = obj.__class__.x\n"
"descriptor.__get__(obj)"
msgstr ""
"descriptor = obj.__class__.x\n"
"descriptor.__get__(obj)"

msgid "For methods, :meth:`descriptor.__get__ <object.__get__>` returns a temporary object that's callable, and wraps up the instance and the method to be called on it. This is also why static methods and class methods are now possible; they have descriptors that wrap up just the method, or the method and the class.  As a brief explanation of these new kinds of methods, static methods aren't passed the instance, and therefore resemble regular functions.  Class methods are passed the class of the object, but not the object itself.  Static and class methods are defined like this::"
msgstr "برای متدها، :meth:`descriptor.__get__ <object.__get__>` یک شیء موقت فراخوانی‌پذیر برمی‌گرداند که نمونه و متدی را که باید روی آن فراخوانی شود دربر می‌گیرد. این همچنین توضیح می‌دهد که چرا متدهای ایستا و متدهای کلاس اکنون ممکن هستند؛ آن‌ها توصیف‌گرهایی دارند که فقط متد، یا متد و کلاس را دربر می‌گیرند. به‌عنوان توضیحی مختصر درباره‌ی این نوع‌های جدید متد، به متدهای ایستا نمونه ارسال نمی‌شود و بنابراین آن‌ها شبیه توابع معمولی هستند. به متدهای کلاس، کلاس شیء ارسال می‌شود، اما نه خودِ شیء. متدهای ایستا و متدهای کلاس به این صورت تعریف می‌شوند::"

msgid ""
"class C(object):\n"
"    def f(arg1, arg2):\n"
"        ...\n"
"    f = staticmethod(f)\n"
"\n"
"    def g(cls, arg1, arg2):\n"
"        ...\n"
"    g = classmethod(g)"
msgstr ""
"class C(object):\n"
"    def f(arg1, arg2):\n"
"        ...\n"
"    f = staticmethod(f)\n"
"\n"
"    def g(cls, arg1, arg2):\n"
"        ...\n"
"    g = classmethod(g)"

msgid "The :func:`staticmethod` function takes the function :func:`!f`, and returns it wrapped up in a descriptor so it can be stored in the class object.  You might expect there to be special syntax for creating such methods (``def static f``, ``defstatic f()``, or something like that) but no such syntax has been defined yet; that's been left for future versions of Python."
msgstr "تابع :func:`staticmethod` تابع :func:`!f` را می‌گیرد و آن را درون یک توصیف‌گر دربرگرفته برمی‌گرداند تا بتوان آن را در شیء کلاس ذخیره کرد. شاید انتظار داشته باشید که سینتکس ویژه‌ای برای ایجاد چنین متدهایی وجود داشته باشد (``def static f``، ``defstatic f()`` یا چیزی شبیه به آن)، اما چنین نحوی هنوز تعریف نشده است؛ این موضوع به نسخه‌های آینده‌ی پایتون موکول شده است."

msgid "More new features, such as slots and properties, are also implemented as new kinds of descriptors, and it's not difficult to write a descriptor class that does something novel.  For example, it would be possible to write a descriptor class that made it possible to write Eiffel-style preconditions and postconditions for a method.  A class that used this feature might be defined like this::"
msgstr "قابلیت‌های جدید دیگری مانند جایگاه‌ها و پراپرتی‌ها نیز به‌صورت گونه‌های جدیدی از توصیف‌گر پیاده‌سازی شده‌اند، و نوشتن کلاس توصیف‌گری که کاری نو انجام دهد دشوار نیست. برای مثال، می‌توان کلاس توصیف‌گری نوشت که امکان نوشتن پیش‌شرط‌ها و پس‌شرط‌ها به سبک Eiffel برای یک متد را فراهم کند. کلاسی که از این قابلیت استفاده می‌کند، ممکن است به این صورت تعریف شود::"

msgid ""
"from eiffel import eiffelmethod\n"
"\n"
"class C(object):\n"
"    def f(self, arg1, arg2):\n"
"        # The actual function\n"
"        ...\n"
"    def pre_f(self):\n"
"        # Check preconditions\n"
"        ...\n"
"    def post_f(self):\n"
"        # Check postconditions\n"
"        ...\n"
"\n"
"    f = eiffelmethod(f, pre_f, post_f)"
msgstr ""
"from eiffel import eiffelmethod\n"
"\n"
"class C(object):\n"
"    def f(self, arg1, arg2):\n"
"        # The actual function\n"
"        ...\n"
"    def pre_f(self):\n"
"        # Check preconditions\n"
"        ...\n"
"    def post_f(self):\n"
"        # Check postconditions\n"
"        ...\n"
"\n"
"    f = eiffelmethod(f, pre_f, post_f)"

msgid "Note that a person using the new :func:`!eiffelmethod` doesn't have to understand anything about descriptors.  This is why I think the new features don't increase the basic complexity of the language. There will be a few wizards who need to know about it in order to write :func:`!eiffelmethod` or the ZODB or whatever, but most users will just write code on top of the resulting libraries and ignore the implementation details."
msgstr "توجه داشته باشید که کسی که از :func:`!eiffelmethod` جدید استفاده می‌کند، لازم نیست هیچ چیز درباره‌ی توصیف‌گرها بداند. به همین دلیل است که به نظرم قابلیت‌های جدید، پیچیدگی پایه‌ای زبان را افزایش نمی‌دهند. تعداد کمی متخصص خبره خواهند بود که برای نوشتن :func:`!eiffelmethod` یا ZODB یا هر چیز دیگری از این دست باید درباره‌ی آن بدانند، اما بیشتر کاربران صرفاً کد خود را بر پایه‌ی کتابخانه‌های حاصل می‌نویسند و جزئیات پیاده‌سازی را نادیده می‌گیرند."

msgid "Multiple Inheritance: The Diamond Rule"
msgstr "وراثت چندگانه: قانون لوزی"

msgid "Multiple inheritance has also been made more useful through changing the rules under which names are resolved.  Consider this set of classes (diagram taken from :pep:`253` by Guido van Rossum)::"
msgstr "وراثت چندگانه نیز با تغییر قواعدی که نام‌ها بر اساس آن‌ها حل می‌شوند، کاربردی‌تر شده است. این مجموعه از کلاس‌ها را در نظر بگیرید (نمودار برگرفته از :pep:`253` نوشته‌ی Guido van Rossum)::"

msgid ""
"      class A:\n"
"        ^ ^  def save(self): ...\n"
"       /   \\\n"
"      /     \\\n"
"     /       \\\n"
"    /         \\\n"
"class B     class C:\n"
"    ^         ^  def save(self): ...\n"
"     \\       /\n"
"      \\     /\n"
"       \\   /\n"
"        \\ /\n"
"      class D"
msgstr ""
"      class A:\n"
"        ^ ^  def save(self): ...\n"
"       /   \\\n"
"      /     \\\n"
"     /       \\\n"
"    /         \\\n"
"class B     class C:\n"
"    ^         ^  def save(self): ...\n"
"     \\       /\n"
"      \\     /\n"
"       \\   /\n"
"        \\ /\n"
"      class D"

msgid "The lookup rule for classic classes is simple but not very smart; the base classes are searched depth-first, going from left to right.  A reference to :meth:`!D.save` will search the classes :class:`!D`, :class:`!B`, and then :class:`!A`, where :meth:`!save` would be found and returned.  :meth:`!C.save` would never be found at all.  This is bad, because if :class:`!C`'s :meth:`!save` method is saving some internal state specific to :class:`!C`, not calling it will result in that state never getting saved."
msgstr "قاعده‌ی جستجو برای کلاس‌های کلاسیک ساده اما نه چندان هوشمند است؛ کلاس‌های پایه به‌صورت اول‌عمق و از چپ به راست جستجو می‌شوند. ارجاع به :meth:`!D.save` کلاس‌های :class:`!D`، :class:`!B` و سپس :class:`!A` را جستجو می‌کند که در آن :meth:`!save` یافته و بازگردانده می‌شود. :meth:`!C.save` به‌هیچ‌وجه یافت نخواهد شد. این امر بد است، زیرا اگر متد :meth:`!save` کلاس :class:`!C` در حال ذخیره‌ی وضعیت داخلی مختص :class:`!C` باشد، عدم فراخوانی آن باعث می‌شود که آن وضعیت هرگز ذخیره نشود."

msgid "New-style classes follow a different algorithm that's a bit more complicated to explain, but does the right thing in this situation. (Note that Python 2.3 changes this algorithm to one that produces the same results in most cases, but produces more useful results for really complicated inheritance graphs.)"
msgstr "کلاس‌های سبک جدید الگوریتم متفاوتی را دنبال می‌کنند که توضیح آن کمی پیچیده‌تر است، اما در این وضعیت کار درست را انجام می‌دهد. (توجه داشته باشید که Python 2.3 این الگوریتم را به الگوریتمی تغییر می‌دهد که در بیشتر موارد نتایج یکسانی تولید می‌کند، اما برای گراف‌های وراثت واقعاً پیچیده، نتایج مفیدتری تولید می‌کند.)"

msgid "List all the base classes, following the classic lookup rule and include a class multiple times if it's visited repeatedly.  In the above example, the list of visited classes is [:class:`!D`, :class:`!B`, :class:`!A`, :class:`!C`, :class:`!A`]."
msgstr "تمام کلاس‌های پایه را با پیروی از قاعده‌ی جستجوی کلاسیک فهرست کنید و در صورتی که کلاسی به‌طور مکرر بازدید شود، آن را چند بار در فهرست قرار دهید.  در مثال بالا، فهرست کلاس‌های بازدید‌شده [:class:`!D`, :class:`!B`, :class:`!A`, :class:`!C`, :class:`!A`] است."

msgid "Scan the list for duplicated classes.  If any are found, remove all but one occurrence, leaving the *last* one in the list.  In the above example, the list becomes [:class:`!D`, :class:`!B`, :class:`!C`, :class:`!A`] after dropping duplicates."
msgstr "فهرست را برای کلاس‌های تکراری بررسی کنید. اگر کلاس تکراری‌ای یافت شد، همه‌ی موارد به‌جز یکی را حذف کنید تا *آخرین* مورد در فهرست باقی بماند. در مثال بالا، فهرست پس از حذف موارد تکراری به [:class:`!D`, :class:`!B`, :class:`!C`, :class:`!A`] تبدیل می‌شود."

msgid "Following this rule, referring to :meth:`!D.save` will return :meth:`!C.save`, which is the behaviour we're after.  This lookup rule is the same as the one followed by Common Lisp.  A new built-in function, :func:`super`, provides a way to get at a class's superclasses without having to reimplement Python's algorithm. The most commonly used form will be  ``super(class, obj)``, which returns  a bound superclass object (not the actual class object).  This form will be used in methods to call a method in the superclass; for example, :class:`!D`'s :meth:`!save` method would look like this::"
msgstr "بر اساس این قاعده، ارجاع به :meth:`!D.save`، :meth:`!C.save` را برمی‌گرداند که همان رفتاری است که به دنبال آن هستیم. این قاعده‌ی جستجو همان قاعده‌ای است که Common Lisp از آن پیروی می‌کند. یک تابع توکار جدید، :func:`super`، راهی برای دسترسی به کلاس‌های والد یک کلاس فراهم می‌کند، بدون آن‌که لازم باشد الگوریتم پایتون را دوباره پیاده‌سازی کنید. رایج‌ترین شکل استفاده، ``super(class, obj)`` خواهد بود که یک شیء مقید از کلاس والد را برمی‌گرداند (نه شیء کلاس واقعی). از این شکل در متدها برای فراخوانی متدی در کلاس والد استفاده خواهد شد؛ برای مثال، متد :meth:`!save` کلاس :class:`!D` به این شکل خواهد بود::"

msgid ""
"class D (B,C):\n"
"    def save (self):\n"
"        # Call superclass .save()\n"
"        super(D, self).save()\n"
"        # Save D's private information here\n"
"        ..."
msgstr ""
"class D (B,C):\n"
"    def save (self):\n"
"        # Call superclass .save()\n"
"        super(D, self).save()\n"
"        # Save D's private information here\n"
"        ..."

msgid ":func:`super` can also return unbound superclass objects when called as ``super(class)`` or ``super(class1, class2)``, but this probably won't often be useful."
msgstr ":func:`super` هنگامی که به‌صورت ``super(class)`` یا ``super(class1, class2)`` فراخوانی شود، می‌تواند شیءهای غیرمقید کلاس والد (superclass) را نیز بازگرداند، اما این احتمالاً اغلب مفید نخواهد بود."

msgid "Attribute Access"
msgstr "دسترسی به ویژگی"

msgid "A fair number of sophisticated Python classes define hooks for attribute access using :meth:`~object.__getattr__`; most commonly this is done for convenience, to make code more readable by automatically mapping an attribute access such as ``obj.parent`` into a method call such as ``obj.get_parent``.  Python 2.2 adds some new ways of controlling attribute access."
msgstr "تعداد قابل‌توجهی از کلاس‌های پیشرفته پایتون با استفاده از :meth:`~object.__getattr__` قلاب‌هایی برای دسترسی به ویژگی تعریف می‌کنند؛ در بیشتر موارد این کار برای سهولت انجام می‌شود تا کد با نگاشت خودکار دسترسی به ویژگی‌ای مانند ``obj.parent`` به فراخوانی متدی مانند ``obj.get_parent`` خواناتر شود. پایتون 2.2 چند روش جدید برای کنترل دسترسی به ویژگی اضافه می‌کند."

msgid "First, ``__getattr__(attr_name)`` is still supported by new-style classes, and nothing about it has changed.  As before, it will be called when an attempt is made to access ``obj.foo`` and no attribute named ``foo`` is found in the instance's dictionary."
msgstr "نخست، ``__getattr__(attr_name)`` همچنان توسط کلاس‌های سبک جدید (new-style) پشتیبانی می‌شود و هیچ‌چیز درباره‌ی آن تغییر نکرده است.  مانند قبل، هنگامی فراخوانی می‌شود که تلاشی برای دسترسی به ``obj.foo`` صورت گیرد و ویژگی‌ای با نام ``foo`` در دیکشنری نمونه یافت نشود."

msgid "New-style classes also support a new method, ``__getattribute__(attr_name)``.  The difference between the two methods is that :meth:`~object.__getattribute__` is *always* called whenever any attribute is accessed, while the old :meth:`~object.__getattr__` is only called if ``foo`` isn't found in the instance's dictionary."
msgstr "کلاس‌های سبک جدید همچنین از یک متد جدید، ``__getattribute__(attr_name)`` پشتیبانی می‌کنند. تفاوت بین این دو متد این است که :meth:`~object.__getattribute__` *همیشه* هر زمان که به هر ویژگی‌ای دسترسی شود فراخوانی می‌شود، در حالی که :meth:`~object.__getattr__` قدیمی تنها زمانی فراخوانی می‌شود که ``foo`` در دیکشنری نمونه پیدا نشود."

msgid "However, Python 2.2's support for :dfn:`properties` will often be a simpler way to trap attribute references.  Writing a :meth:`!__getattr__` method is complicated because to avoid recursion you can't use regular attribute accesses inside them, and instead have to mess around with the contents of :attr:`~object.__dict__`. :meth:`~object.__getattr__` methods also end up being called by Python when it checks for other methods such as :meth:`~object.__repr__` or :meth:`!__coerce__`, and so have to be written with this in mind. Finally, calling a function on every attribute access results in a sizable performance loss."
msgstr "با این حال، پشتیبانی پایتون 2.2 از :dfn:`پراپرتی‌ها (properties)` اغلب راهی ساده‌تر برای رهگیری ارجاع‌های ویژگی خواهد بود. نوشتن متد :meth:`!__getattr__` پیچیده است، زیرا برای پرهیز از بازگشت نمی‌توانید درون آن‌ها از دسترسی‌های عادی به ویژگی استفاده کنید و در عوض باید محتوای :attr:`~object.__dict__` را دستکاری کنید. متدهای :meth:`~object.__getattr__` همچنین هنگامی که پایتون متدهای دیگر مانند :meth:`~object.__repr__` یا :meth:`!__coerce__` را بررسی می‌کند، در نهایت توسط پایتون فراخوانی می‌شوند و بنابراین باید با در نظر گرفتن این موضوع نوشته شوند. در آخر، فراخوانی یک تابع به ازای هر دسترسی به ویژگی، به افت کارایی قابل‌توجهی منجر می‌شود."

msgid ":class:`property` is a new built-in type that packages up three functions that get, set, or delete an attribute, and a docstring.  For example, if you want to define a :attr:`!size` attribute that's computed, but also settable, you could write::"
msgstr ":class:`property` نوع توکار جدیدی است که سه تابع — که یک ویژگی را دریافت، تنظیم یا حذف می‌کنند — و یک رشته مستند را بسته‌بندی می‌کند. برای مثال، اگر بخواهید ویژگی :attr:`!size` را تعریف کنید که محاسبه می‌شود، اما قابل تنظیم نیز هست، می‌توانید بنویسید::"

msgid ""
"class C(object):\n"
"    def get_size (self):\n"
"        result = ... computation ...\n"
"        return result\n"
"    def set_size (self, size):\n"
"        ... compute something based on the size\n"
"        and set internal state appropriately ...\n"
"\n"
"    # Define a property.  The 'delete this attribute'\n"
"    # method is defined as None, so the attribute\n"
"    # can't be deleted.\n"
"    size = property(get_size, set_size,\n"
"                    None,\n"
"                    \"Storage size of this instance\")"
msgstr ""
"class C(object):\n"
"    def get_size (self):\n"
"        result = ... computation ...\n"
"        return result\n"
"    def set_size (self, size):\n"
"        ... compute something based on the size\n"
"        and set internal state appropriately ...\n"
"\n"
"    # Define a property.  The 'delete this attribute'\n"
"    # method is defined as None, so the attribute\n"
"    # can't be deleted.\n"
"    size = property(get_size, set_size,\n"
"                    None,\n"
"                    \"Storage size of this instance\")"

msgid "That is certainly clearer and easier to write than a pair of :meth:`!__getattr__`/:meth:`!__setattr__` methods that check for the :attr:`!size` attribute and handle it specially while retrieving all other attributes from the instance's :attr:`~object.__dict__`.  Accesses to :attr:`!size` are also the only ones which have to perform the work of calling a function, so references to other attributes run at their usual speed."
msgstr "این کار قطعاً از یک جفت متد :meth:`!__getattr__`/:meth:`!__setattr__` — که ویژگی :attr:`!size` را بررسی می‌کنند و آن را به‌طور خاص مدیریت می‌کنند، در حالی که تمام ویژگی‌های دیگر را از :attr:`~object.__dict__` نمونه بازیابی می‌کنند — روشن‌تر است و نوشتن آن نیز آسان‌تر است. دسترسی‌های به :attr:`!size` همچنین تنها مواردی هستند که باید کار فراخوانی یک تابع را انجام دهند؛ بنابراین ارجاع‌های به ویژگی‌های دیگر با سرعت معمول خود اجرا می‌شوند."

msgid "Finally, it's possible to constrain the list of attributes that can be referenced on an object using the new :attr:`~object.__slots__` class attribute. Python objects are usually very dynamic; at any time it's possible to define a new attribute on an instance by just doing ``obj.new_attr=1``.   A new-style class can define a class attribute named :attr:`~object.__slots__` to limit the legal attributes  to a particular set of names.  An example will make this clear::"
msgstr "در نهایت، می‌توان با استفاده از ویژگی کلاس جدید :attr:`~object.__slots__` فهرست ویژگی‌هایی را که می‌توان روی یک شیء به آن‌ها ارجاع داد، محدود کرد. اشیاء پایتون معمولاً بسیار پویا هستند؛ در هر لحظه می‌توان صرفاً با انجام ``obj.new_attr=1`` یک ویژگی جدید روی یک نمونه تعریف کرد. یک کلاس به سبک جدید می‌تواند ویژگی کلاسی به نام :attr:`~object.__slots__` تعریف کند تا ویژگی‌های مجاز را به مجموعه‌ای خاص از نام‌ها محدود کند. یک مثال این موضوع را روشن می‌کند::"

msgid ""
">>> class C(object):\n"
"...     __slots__ = ('template', 'name')\n"
"...\n"
">>> obj = C()\n"
">>> print obj.template\n"
"None\n"
">>> obj.template = 'Test'\n"
">>> print obj.template\n"
"Test\n"
">>> obj.newattr = None\n"
"Traceback (most recent call last):\n"
"  File \"<stdin>\", line 1, in ?\n"
"AttributeError: 'C' object has no attribute 'newattr'"
msgstr ""
">>> class C(object):\n"
"...     __slots__ = ('template', 'name')\n"
"...\n"
">>> obj = C()\n"
">>> print obj.template\n"
"None\n"
">>> obj.template = 'Test'\n"
">>> print obj.template\n"
"Test\n"
">>> obj.newattr = None\n"
"Traceback (most recent call last):\n"
"  File \"<stdin>\", line 1, in ?\n"
"AttributeError: 'C' object has no attribute 'newattr'"

msgid "Note how you get an :exc:`AttributeError` on the attempt to assign to an attribute not listed in :attr:`~object.__slots__`."
msgstr "توجه کنید که چگونه هنگام تلاش برای انتساب به ویژگی‌ای که در :attr:`~object.__slots__` فهرست نشده است، با خطای :exc:`AttributeError` مواجه می‌شوید."

msgid "Related Links"
msgstr "پیوندهای مرتبط"

msgid "This section has just been a quick overview of the new features, giving enough of an explanation to start you programming, but many details have been simplified or ignored.  Where should you go to get a more complete picture?"
msgstr "این بخش صرفاً مروری سریع بر ویژگی‌های جدید بود که توضیحی به‌اندازه‌ی کافی برای آغاز برنامه‌نویسی شما ارائه می‌دهد، اما بسیاری از جزئیات ساده‌سازی شده‌اند یا نادیده گرفته شده‌اند. برای به‌دست‌آوردن تصویری کامل‌تر، باید به کجا بروید؟"

msgid "The :ref:`descriptorhowto` is a lengthy tutorial introduction to the descriptor features, written by Guido van Rossum. If my description has whetted your appetite, go read this tutorial next, because it goes into much more detail about the new features while still remaining quite easy to read."
msgstr ":ref:`descriptorhowto` یک مقدمه‌ی آموزشی مفصل درباره‌ی قابلیت‌های توصیف‌گرها است که توسط گیدو ون‌روسوم نوشته‌شده است. اگر شرح من اشتهای شما را برانگیخته است، در گام بعدی این آموزش را بخوانید، زیرا به جزئیات بسیار بیشتری درباره‌ی قابلیت‌های جدید می‌پردازد و در عین حال همچنان خواندن آن بسیار آسان است."

msgid "Next, there are two relevant PEPs, :pep:`252` and :pep:`253`.  :pep:`252` is titled \"Making Types Look More Like Classes\", and covers the descriptor API. :pep:`253` is titled \"Subtyping Built-in Types\", and describes the changes to type objects that make it possible to subtype built-in objects.  :pep:`253` is the more complicated PEP of the two, and at a few points the necessary explanations of types and meta-types may cause your head to explode.  Both PEPs were written and implemented by Guido van Rossum, with substantial assistance from the rest of the Zope Corp. team."
msgstr "در ادامه، دو PEP (پیشنهاد بهبود پایتون) مرتبط وجود دارد: :pep:`252` و :pep:`253`. :pep:`252` با عنوان «Making Types Look More Like Classes» است و به API توصیف‌گر می‌پردازد. :pep:`253` با عنوان «Subtyping Built-in Types» است و تغییراتی را که در اشیاء نوع ایجاد شده‌اند و زیرنوع‌سازی اشیاء توکار را ممکن می‌سازند، شرح می‌دهد. از میان این دو PEP، :pep:`253` پیچیده‌تر است و در چند نقطه، توضیحات ضروری درباره‌ی نوع‌ها و فرانوع‌ها ممکن است سر شما را منفجر کند. هر دو PEP توسط گیدو ون روسوم، با کمک قابل‌توجه سایر اعضای تیم Zope Corp. نوشته و پیاده‌سازی شده‌اند."

msgid "Finally, there's the ultimate authority: the source code.  Most of the machinery for the type handling is in :file:`Objects/typeobject.c`, but you should only resort to it after all other avenues have been exhausted, including posting a question to python-list or python-dev."
msgstr "در نهایت، مرجع نهایی وجود دارد: کد منبع. بخش عمده‌ی سازوکارهای مربوط به مدیریت نوع در :file:`Objects/typeobject.c` قرار دارد، اما شما باید تنها پس از آنکه تمام راه‌های دیگر، از جمله ارسال پرسش به python-list یا python-dev، به پایان رسیده باشند، به آن رجوع کنید."

msgid "PEP 234: Iterators"
msgstr "PEP 234: پیمایش‌گرها"

msgid "Another significant addition to 2.2 is an iteration interface at both the C and Python levels.  Objects can define how they can be looped over by callers."
msgstr "افزوده مهم دیگر در 2.2، یک رابط پیمایش در هر دو سطح C و پایتون است. اشیاء می‌توانند تعریف کنند که چگونه می‌توانند توسط فراخواننده‌ها پیمایش شوند."

msgid "In Python versions up to 2.1, the usual way to make ``for item in obj`` work is to define a :meth:`~object.__getitem__` method that looks something like this::"
msgstr "در نسخه‌های پایتون تا 2.1، روش معمول برای این‌که ``for item in obj`` کار کند، تعریف متد :meth:`~object.__getitem__` است که چیزی شبیه به این است::"

msgid ""
"def __getitem__(self, index):\n"
"    return <next item>"
msgstr ""
"def __getitem__(self, index):\n"
"    return <next item>"

msgid ":meth:`~object.__getitem__` is more properly used to define an indexing operation on an object so that you can write ``obj[5]`` to retrieve the sixth element.  It's a bit misleading when you're using this only to support :keyword:`for` loops. Consider some file-like object that wants to be looped over; the *index* parameter is essentially meaningless, as the class probably assumes that a series of :meth:`~object.__getitem__` calls will be made with *index* incrementing by one each time.  In other words, the presence of the :meth:`~object.__getitem__` method doesn't mean that using ``file[5]``  to randomly access the sixth element will work, though it really should."
msgstr ":meth:`~object.__getitem__` به‌طور صحیح‌تری برای تعریف عملیات اندیس‌گذاری روی یک شیء به کار می‌رود تا بتوانید برای بازیابی ششمین عنصر، ``obj[5]`` بنویسید. وقتی تنها از آن برای پشتیبانی از حلقه‌های :keyword:`for` استفاده می‌کنید، کمی گمراه‌کننده است. یک شیء شبه‌پرونده را در نظر بگیرید که می‌خواهد پیمایش شود؛ پارامتر *اندیس* اساساً بی‌معناست، زیرا کلاس احتمالاً فرض می‌کند که مجموعه‌ای از فراخوانی‌های :meth:`~object.__getitem__` انجام خواهد شد که در آن هر بار *اندیس* یک واحد افزایش می‌یابد. به عبارت دیگر، وجود متد :meth:`~object.__getitem__` به این معنا نیست که استفاده از ``file[5]`` برای دسترسی تصادفی به ششمین عنصر کار خواهد کرد، هرچند واقعاً باید چنین باشد."

msgid "In Python 2.2, iteration can be implemented separately, and :meth:`~object.__getitem__` methods can be limited to classes that really do support random access.  The basic idea of iterators is  simple.  A new built-in function, ``iter(obj)`` or ``iter(C, sentinel)``, is used to get an iterator. ``iter(obj)`` returns an iterator for the object *obj*, while ``iter(C, sentinel)`` returns an iterator that will invoke the callable object *C* until it returns *sentinel* to signal that the iterator is done."
msgstr "در پایتون 2.2، پیمایش می‌تواند به‌صورت جداگانه پیاده‌سازی شود و متدهای :meth:`~object.__getitem__` می‌توانند به کلاس‌هایی محدود شوند که واقعاً از دسترسی تصادفی پشتیبانی می‌کنند. ایده‌ی بنیادی پیمایش‌گرها ساده است. تابع توکار جدیدی، ``iter(obj)`` یا ``iter(C, sentinel)``، برای به دست آوردن یک پیمایش‌گر به کار می‌رود. ``iter(obj)`` پیمایش‌گری برای شیء *obj* برمی‌گرداند، در حالی که ``iter(C, sentinel)`` پیمایش‌گری برمی‌گرداند که شیء فراخوانی‌پذیر *C* را فراخوانی می‌کند تا زمانی که *sentinel* را برگرداند تا نشان دهد که کار پیمایش‌گر به پایان رسیده است."

msgid "Python classes can define an :meth:`!__iter__` method, which should create and return a new iterator for the object; if the object is its own iterator, this method can just return ``self``.  In particular, iterators will usually be their own iterators.  Extension types implemented in C can implement a :c:member:`~PyTypeObject.tp_iter` function in order to return an iterator, and extension types that want to behave as iterators can define a :c:member:`~PyTypeObject.tp_iternext` function."
msgstr "کلاس‌های پایتون می‌توانند متدی به نام :meth:`!__iter__` تعریف کنند که باید یک پیمایش‌گر جدید برای آن شیء ایجاد کرده و آن را بازگرداند؛ اگر شیء پیمایش‌گر خودش باشد، این متد می‌تواند صرفاً ``self`` را برگرداند.  به‌طور خاص، پیمایش‌گرها معمولاً پیمایش‌گرهای خودشان هستند.  نوع‌های توسعه‌ای پیاده‌سازی‌شده در C می‌توانند برای بازگرداندن یک پیمایش‌گر، تابع :c:member:`~PyTypeObject.tp_iter` را پیاده‌سازی کنند، و نوع‌های توسعه‌ای که می‌خواهند مانند پیمایش‌گرها رفتار کنند می‌توانند تابع :c:member:`~PyTypeObject.tp_iternext` را تعریف کنند."

msgid "So, after all this, what do iterators actually do?  They have one required method, :meth:`next`, which takes no arguments and returns the next value.  When there are no more values to be returned, calling :meth:`next` should raise the :exc:`StopIteration` exception. ::"
msgstr "پس، بعد از همه‌ی این موارد، پیمایش‌گرها در واقع چه کاری انجام می‌دهند؟ آن‌ها یک متد الزامی به نام :meth:`next` دارند که هیچ آرگومانی نمی‌گیرد و مقدار بعدی را برمی‌گرداند. وقتی دیگر مقداری برای بازگرداندن وجود ندارد، فراخوانی :meth:`next` باید استثنای :exc:`StopIteration` را ایجاد کند. ::"

msgid ""
">>> L = [1,2,3]\n"
">>> i = iter(L)\n"
">>> print i\n"
"<iterator object at 0x8116870>\n"
">>> i.next()\n"
"1\n"
">>> i.next()\n"
"2\n"
">>> i.next()\n"
"3\n"
">>> i.next()\n"
"Traceback (most recent call last):\n"
"  File \"<stdin>\", line 1, in ?\n"
"StopIteration\n"
">>>"
msgstr ""
">>> L = [1,2,3]\n"
">>> i = iter(L)\n"
">>> print i\n"
"<iterator object at 0x8116870>\n"
">>> i.next()\n"
"1\n"
">>> i.next()\n"
"2\n"
">>> i.next()\n"
"3\n"
">>> i.next()\n"
"Traceback (most recent call last):\n"
"  File \"<stdin>\", line 1, in ?\n"
"StopIteration\n"
">>>"

msgid "In 2.2, Python's :keyword:`for` statement no longer expects a sequence; it expects something for which :func:`iter` will return an iterator. For backward compatibility and convenience, an iterator is automatically constructed for sequences that don't implement :meth:`!__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so ``for i in [1,2,3]`` will still work.  Wherever the Python interpreter loops over a sequence, it's been changed to use the iterator protocol.  This means you can do things like this::"
msgstr "در نسخه 2.2، دستور :keyword:`for` پایتون دیگر انتظار یک دنباله را ندارد؛ بلکه انتظار چیزی را دارد که :func:`iter` برای آن یک پیمایش‌گر برگرداند. برای سازگاری با نسخه‌های قبلی و برای راحتی، یک پیمایش‌گر به‌طور خودکار برای دنباله‌هایی ساخته می‌شود که :meth:`!__iter__` یا جایگاه :c:member:`~PyTypeObject.tp_iter` را پیاده‌سازی نمی‌کنند، بنابراین ``for i in [1,2,3]`` همچنان کار خواهد کرد. در هر جایی که مفسر پایتون بر روی یک دنباله حلقه می‌زند، به‌گونه‌ای تغییر کرده است که از پروتکل پیمایش‌گر استفاده کند. این بدان معناست که می‌توانید کارهایی مانند این انجام دهید::"

msgid ""
">>> L = [1,2,3]\n"
">>> i = iter(L)\n"
">>> a,b,c = i\n"
">>> a,b,c\n"
"(1, 2, 3)"
msgstr ""
">>> L = [1,2,3]\n"
">>> i = iter(L)\n"
">>> a,b,c = i\n"
">>> a,b,c\n"
"(1, 2, 3)"

msgid "Iterator support has been added to some of Python's basic types.   Calling :func:`iter` on a dictionary will return an iterator which loops over its keys::"
msgstr "پشتیبانی از پیمایش‌گر به برخی از نوع‌های پایه‌ی پایتون اضافه‌شده است. فراخوانی :func:`iter` روی یک دیکشنری، پیمایش‌گری را برمی‌گرداند که روی کلید‌های آن حلقه می‌زند::"

msgid ""
">>> m = {'Jan': 1, 'Feb': 2, 'Mar': 3, 'Apr': 4, 'May': 5, 'Jun': 6,\n"
"...      'Jul': 7, 'Aug': 8, 'Sep': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12}\n"
">>> for key in m: print key, m[key]\n"
"...\n"
"Mar 3\n"
"Feb 2\n"
"Aug 8\n"
"Sep 9\n"
"May 5\n"
"Jun 6\n"
"Jul 7\n"
"Jan 1\n"
"Apr 4\n"
"Nov 11\n"
"Dec 12\n"
"Oct 10"
msgstr ""
">>> m = {'Jan': 1, 'Feb': 2, 'Mar': 3, 'Apr': 4, 'May': 5, 'Jun': 6,\n"
"...      'Jul': 7, 'Aug': 8, 'Sep': 9, 'Oct': 10, 'Nov': 11, 'Dec': 12}\n"
">>> for key in m: print key, m[key]\n"
"...\n"
"Mar 3\n"
"Feb 2\n"
"Aug 8\n"
"Sep 9\n"
"May 5\n"
"Jun 6\n"
"Jul 7\n"
"Jan 1\n"
"Apr 4\n"
"Nov 11\n"
"Dec 12\n"
"Oct 10"

msgid "That's just the default behaviour.  If you want to iterate over keys, values, or key/value pairs, you can explicitly call the :meth:`!iterkeys`, :meth:`!itervalues`, or :meth:`!iteritems` methods to get an appropriate iterator. In a minor related change, the :keyword:`in` operator now works on dictionaries, so ``key in dict`` is now equivalent to ``dict.has_key(key)``."
msgstr "این صرفاً رفتار پیش‌فرض است. اگر می‌خواهید بر روی کلیدها، مقادیر یا جفت‌های کلید/مقدار پیمایش کنید، می‌توانید متدهای :meth:`!iterkeys`، :meth:`!itervalues` یا :meth:`!iteritems` را به‌طور صریح فراخوانی کنید تا یک پیمایش‌گر مناسب به دست آورید. در یک تغییر جزئی مرتبط، عملگر :keyword:`in` اکنون بر روی دیکشنری‌ها کار می‌کند، بنابراین ``key in dict`` اکنون معادل ``dict.has_key(key)`` است."

msgid "Files also provide an iterator, which calls the :meth:`readline` method until there are no more lines in the file.  This means you can now read each line of a file using code like this::"
msgstr "پرونده‌ها همچنین یک پیمایش‌گر فراهم می‌کنند که متد :meth:`readline` را تا زمانی که دیگر سطری در پرونده نباشد فراخوانی می‌کند. این بدان معناست که اکنون می‌توانید هر سطر از یک پرونده را با کدی مانند این بخوانید::"

msgid ""
"for line in file:\n"
"    # do something for each line\n"
"    ..."
msgstr ""
"for line in file:\n"
"    # do something for each line\n"
"    ..."

msgid "Note that you can only go forward in an iterator; there's no way to get the previous element, reset the iterator, or make a copy of it. An iterator object could provide such additional capabilities, but the iterator protocol only requires a :meth:`next` method."
msgstr "توجه داشته باشید که در یک پیمایش‌گر تنها می‌توانید به جلو حرکت کنید؛ هیچ راهی برای دریافت عنصر قبلی، بازنشانی پیمایش‌گر یا ساخت رونوشتی از آن وجود ندارد. شیء پیمایش‌گر می‌تواند چنین قابلیت‌های اضافی‌ای را فراهم کند، اما پروتکل پیمایش‌گر تنها به یک متد :meth:`next` نیاز دارد."

msgid ":pep:`234` - Iterators"
msgstr ":pep:`234` - پیمایش‌گرها"

msgid "Written by Ka-Ping Yee and GvR; implemented  by the Python Labs crew, mostly by GvR and Tim Peters."
msgstr "نوشته‌ی Ka-Ping Yee و GvR؛ پیاده‌سازی‌شده توسط گروه Python Labs، عمدتاً توسط GvR و Tim Peters."

msgid "PEP 255: Simple Generators"
msgstr "PEP 255: تولیدگرهای ساده"

msgid "Generators are another new feature, one that interacts with the introduction of iterators."
msgstr "تولیدگرها ویژگی جدید دیگری هستند که با معرفی پیمایش‌گرها برهم‌کنش دارد."

msgid "You're doubtless familiar with how function calls work in Python or C.  When you call a function, it gets a private namespace where its local variables are created.  When the function reaches a :keyword:`return` statement, the local variables are destroyed and the resulting value is returned to the caller.  A later call to the same function will get a fresh new set of local variables. But, what if the local variables weren't thrown away on exiting a function? What if you could later resume the function where it left off?  This is what generators provide; they can be thought of as resumable functions."
msgstr "بی‌شک با نحوه‌ی کار فراخوانی توابع در پایتون یا C آشنایی دارید. وقتی تابعی را فراخوانی می‌کنید، تابع یک فضای نام خصوصی می‌گیرد که متغیرهای محلی‌اش در آن ایجاد می‌شوند. وقتی تابع به دستور :keyword:`return` می‌رسد، متغیرهای محلی نابود می‌شوند و مقدار حاصل به فراخوانی‌کننده بازگردانده می‌شود. فراخوانی بعدی همان تابع، مجموعه‌ای تازه و جدید از متغیرهای محلی به دست می‌آورد. اما، اگر متغیرهای محلی هنگام خروج از تابع دور ریخته نمی‌شدند چه؟ اگر می‌توانستید بعداً تابع را از همان‌جایی که متوقف شده بود از سر بگیرید چه؟ این همان چیزی است که تولیدگر‌ها فراهم می‌کنند؛ می‌توان آن‌ها را توابعی قابل ازسرگیری در نظر گرفت."

msgid "Here's the simplest example of a generator function::"
msgstr "این ساده‌ترین مثال یک تابع تولیدگر است::"

msgid ""
"def generate_ints(N):\n"
"    for i in range(N):\n"
"        yield i"
msgstr ""
"def generate_ints(N):\n"
"    for i in range(N):\n"
"        yield i"

msgid "A new keyword, :keyword:`yield`, was introduced for generators.  Any function containing a :keyword:`!yield` statement is a generator function; this is detected by Python's bytecode compiler which compiles the function specially as a result.  Because a new keyword was introduced, generators must be explicitly enabled in a module by including a ``from __future__ import generators`` statement near the top of the module's source code.  In Python 2.3 this statement will become unnecessary."
msgstr "کلیدواژه‌ی جدیدی با نام :keyword:`yield` برای تولیدگرها معرفی شد. هر تابعی که شامل دستور :keyword:`!yield` باشد، یک تابع تولیدگر است؛ کامپایلر بایت‌کد پایتون این موضوع را تشخیص می‌دهد و در نتیجه، تابع را به‌طور خاص کامپایل می‌کند. از آنجا که کلیدواژه‌ی جدیدی معرفی شده است، تولیدگرها باید به‌طور صریح در یک ماژول با گنجاندن دستور ``from __future__ import generators`` نزدیک به ابتدای کد منبع ماژول فعال شوند. در پایتون 2.3 این دستور دیگر لازم نخواهد بود."

msgid "When you call a generator function, it doesn't return a single value; instead it returns a generator object that supports the iterator protocol.  On executing the :keyword:`yield` statement, the generator outputs the value of ``i``, similar to a :keyword:`return` statement.  The big difference between :keyword:`!yield` and a :keyword:`!return` statement is that on reaching a :keyword:`!yield` the generator's state of execution is suspended and local variables are preserved.  On the next call to the generator's ``next()`` method, the function will resume executing immediately after the :keyword:`!yield` statement.  (For complicated reasons, the :keyword:`!yield` statement isn't allowed inside the :keyword:`!try` block of a :keyword:`try`...\\ :keyword:`finally` statement; read :pep:`255` for a full explanation of the interaction between :keyword:`!yield` and exceptions.)"
msgstr "هنگامی که یک تابع تولیدگر را فراخوانی می‌کنید، این تابع یک مقدار واحد بازنمی‌گرداند؛ در عوض، شیء تولیدگری را برمی‌گرداند که از پروتکل پیمایش‌گر پشتیبانی می‌کند. هنگام اجرای دستور :keyword:`yield`، تولیدگر مقدار ``i`` را خروجی می‌دهد، مشابه دستور :keyword:`return`. تفاوت بزرگ بین :keyword:`!yield` و دستور :keyword:`!return` این است که هنگام رسیدن به :keyword:`!yield`، وضعیت اجرای تولیدگر معلق می‌شود و متغیرهای محلی حفظ می‌شوند. در فراخوانی بعدی متد ``next()`` تولیدگر، تابع بلافاصله پس از دستور :keyword:`!yield` اجرا را از سر می‌گیرد. (به دلایل پیچیده، دستور :keyword:`!yield` در بلوک :keyword:`!try` یک دستور :keyword:`try`...\\ :keyword:`finally` مجاز نیست؛ برای توضیح کامل تعامل بین :keyword:`!yield` و استثناها، :pep:`255` را بخوانید.)"

msgid "Here's a sample usage of the :func:`!generate_ints` generator::"
msgstr "در ادامه نمونه‌ای از استفاده از تولیدگر :func:`!generate_ints` آمده است::"

msgid ""
">>> gen = generate_ints(3)\n"
">>> gen\n"
"<generator object at 0x8117f90>\n"
">>> gen.next()\n"
"0\n"
">>> gen.next()\n"
"1\n"
">>> gen.next()\n"
"2\n"
">>> gen.next()\n"
"Traceback (most recent call last):\n"
"  File \"<stdin>\", line 1, in ?\n"
"  File \"<stdin>\", line 2, in generate_ints\n"
"StopIteration"
msgstr ""
">>> gen = generate_ints(3)\n"
">>> gen\n"
"<generator object at 0x8117f90>\n"
">>> gen.next()\n"
"0\n"
">>> gen.next()\n"
"1\n"
">>> gen.next()\n"
"2\n"
">>> gen.next()\n"
"Traceback (most recent call last):\n"
"  File \"<stdin>\", line 1, in ?\n"
"  File \"<stdin>\", line 2, in generate_ints\n"
"StopIteration"

msgid "You could equally write ``for i in generate_ints(5)``, or ``a,b,c = generate_ints(3)``."
msgstr "می‌توانید به همان خوبی ``for i in generate_ints(5)`` بنویسید، یا ``a,b,c = generate_ints(3)``."

msgid "Inside a generator function, the :keyword:`return` statement can only be used without a value, and signals the end of the procession of values; afterwards the generator cannot return any further values. :keyword:`!return` with a value, such as ``return 5``, is a syntax error inside a generator function.  The end of the generator's results can also be indicated by raising :exc:`StopIteration` manually, or by just letting the flow of execution fall off the bottom of the function."
msgstr "درون یک تابع تولیدگر، دستور :keyword:`return` تنها می‌تواند بدون مقدار استفاده شود و پایان جریان مقادیر را اعلام می‌کند؛ پس از آن تولیدگر نمی‌تواند مقادیر بیشتری را بازگرداند. :keyword:`!return` همراه با مقدار، مانند ``return 5``، درون تابع تولیدگر یک خطای نحوی است.  پایان نتایج تولیدگر را همچنین می‌توان با پرتاب دستی :exc:`StopIteration` یا صرفاً با اجازه دادن به جریان اجرا برای خروج از انتهای تابع مشخص کرد."

msgid "You could achieve the effect of generators manually by writing your own class and storing all the local variables of the generator as instance variables.  For example, returning a list of integers could be done by setting ``self.count`` to 0, and having the :meth:`next` method increment ``self.count`` and return it. However, for a moderately complicated generator, writing a corresponding class would be much messier. :file:`Lib/test/test_generators.py` contains a number of more interesting examples.  The simplest one implements an in-order traversal of a tree using generators recursively. ::"
msgstr "می‌توانید با نوشتن کلاس خودتان و ذخیره‌سازی تمام متغیرهای محلی تولیدگر به‌عنوان متغیرهای نمونه، اثر تولیدگرها را به‌صورت دستی به دست آورید. برای مثال، برگرداندن فهرستی از اعداد صحیح را می‌توان با قرار دادن ``self.count`` برابر با ۰ و افزایش دادن ``self.count`` و برگرداندن آن در متد :meth:`next` انجام داد. با این حال، برای یک تولیدگر نسبتاً پیچیده، نوشتن کلاس متناظر بسیار به‌هم‌ریخته‌تر خواهد بود. :file:`Lib/test/test_generators.py` شامل تعدادی مثال جالب‌تر است. ساده‌ترین آن‌ها پیمایش میان‌ترتیب یک درخت را با استفاده از تولیدگرها به‌صورت بازگشتی پیاده‌سازی می‌کند. ::"

msgid ""
"# A recursive generator that generates Tree leaves in in-order.\n"
"def inorder(t):\n"
"    if t:\n"
"        for x in inorder(t.left):\n"
"            yield x\n"
"        yield t.label\n"
"        for x in inorder(t.right):\n"
"            yield x"
msgstr ""
"# A recursive generator that generates Tree leaves in in-order.\n"
"def inorder(t):\n"
"    if t:\n"
"        for x in inorder(t.left):\n"
"            yield x\n"
"        yield t.label\n"
"        for x in inorder(t.right):\n"
"            yield x"

msgid "Two other examples in :file:`Lib/test/test_generators.py` produce solutions for the N-Queens problem (placing $N$ queens on an $NxN$ chess board so that no queen threatens another) and the Knight's Tour (a route that takes a knight to every square of an $NxN$ chessboard without visiting any square twice)."
msgstr "دو نمونه‌ی دیگر در :file:`Lib/test/test_generators.py` راه‌حل‌هایی برای مسئله‌ی N وزیر (قرار دادن $N$ وزیر روی یک صفحه‌ی شطرنج $NxN$ به‌طوری‌که هیچ وزیری دیگری را تهدید نکند) و مسیر اسب (مسیری که اسب را به همه‌ی خانه‌های یک صفحه‌ی شطرنج $NxN$ می‌برد، بدون اینکه از هیچ خانه‌ای دو بار عبور کند) تولید می‌کنند."

msgid "The idea of generators comes from other programming languages, especially Icon (https://www2.cs.arizona.edu/icon/), where the idea of generators is central.  In Icon, every expression and function call behaves like a generator.  One example from \"An Overview of the Icon Programming Language\" at https://www2.cs.arizona.edu/icon/docs/ipd266.htm gives an idea of what this looks like::"
msgstr "ایده‌ی تولیدگرها از زبان‌های برنامه‌نویسی دیگر برخاسته است، به‌ویژه از Icon (https://www2.cs.arizona.edu/icon/)، که در آن ایده‌ی تولیدگرها نقشی محوری دارد. در Icon، هر عبارت و هر فراخوانی تابع مانند یک تولیدگر رفتار می‌کند. یک نمونه از «An Overview of the Icon Programming Language» در https://www2.cs.arizona.edu/icon/docs/ipd266.htm تصویری از چگونگی این موضوع به دست می‌دهد::"

msgid ""
"sentence := \"Store it in the neighboring harbor\"\n"
"if (i := find(\"or\", sentence)) > 5 then write(i)"
msgstr ""
"sentence := \"Store it in the neighboring harbor\"\n"
"if (i := find(\"or\", sentence)) > 5 then write(i)"

msgid "In Icon the :func:`!find` function returns the indexes at which the substring \"or\" is found: 3, 23, 33.  In the :keyword:`if` statement, ``i`` is first assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon retries it with the second value of 23.  23 is greater than 5, so the comparison now succeeds, and the code prints the value 23 to the screen."
msgstr "در Icon، تابع :func:`!find` اندیس‌هایی را که زیررشته‌ی \"or\" در آن‌ها یافت می‌شود برمی‌گرداند: ۳، ۲۳، ۳۳.  در دستور :keyword:`if`، ابتدا مقدار ۳ به ``i`` انتساب داده می‌شود، اما ۳ کمتر از ۵ است، بنابراین مقایسه شکست می‌خورد و Icon آن را با مقدار دوم یعنی ۲۳ دوباره امتحان می‌کند.  ۲۳ بزرگ‌تر از ۵ است، بنابراین این بار مقایسه موفق می‌شود و کد مقدار ۲۳ را روی صفحه چاپ می‌کند."

msgid "Python doesn't go nearly as far as Icon in adopting generators as a central concept.  Generators are considered a new part of the core Python language, but learning or using them isn't compulsory; if they don't solve any problems that you have, feel free to ignore them. One novel feature of Python's interface as compared to Icon's is that a generator's state is represented as a concrete object (the iterator) that can be passed around to other functions or stored in a data structure."
msgstr "پایتون به هیچ‌وجه به اندازه‌ی Icon در پذیرش تولیدگرها به‌عنوان یک مفهوم مرکزی پیش نمی‌رود. تولیدگرها بخش جدیدی از هسته‌ی زبان پایتون محسوب می‌شوند، اما یادگیری یا استفاده از آن‌ها اجباری نیست؛ اگر هیچ‌یک از مشکلات شما را حل نمی‌کنند، می‌توانید با خیال راحت آن‌ها را نادیده بگیرید. یکی از ویژگی‌های نوآورانه‌ی رابط پایتون در مقایسه با رابط Icon این است که وضعیت یک تولیدگر به‌صورت یک شیء مشخص (پیمایش‌گر) نمایش داده می‌شود که می‌توان آن را به توابع دیگر پاس داد یا در یک ساختار داده ذخیره کرد."

msgid ":pep:`255` - Simple Generators"
msgstr ":pep:`255` - تولیدگرهای ساده"

msgid "Written by Neil Schemenauer, Tim Peters, Magnus Lie Hetland.  Implemented mostly by Neil Schemenauer and Tim Peters, with other fixes from the Python Labs crew."
msgstr "نوشته‌ی Neil Schemenauer، Tim Peters و Magnus Lie Hetland. پیاده‌سازی آن عمدتاً توسط Neil Schemenauer و Tim Peters انجام شده است، همراه با اصلاحات دیگر از سوی گروه Python Labs."

msgid "PEP 237: Unifying Long Integers and Integers"
msgstr "PEP 237: یکسان‌سازی اعداد صحیح بلند و اعداد صحیح"

msgid "In recent versions, the distinction between regular integers, which are 32-bit values on most machines, and long integers, which can be of arbitrary size, was becoming an annoyance.  For example, on platforms that support files larger than ``2**32`` bytes, the :meth:`!tell` method of file objects has to return a long integer. However, there were various bits of Python that expected plain integers and would raise an error if a long integer was provided instead.  For example, in Python 1.5, only regular integers could be used as a slice index, and ``'abc'[1L:]`` would raise a :exc:`TypeError` exception with the message 'slice index must be int'."
msgstr "در نسخه‌های اخیر، تمایز بین اعداد صحیح معمولی، که در بیشتر رایانه‌ها مقادیر ۳۲ بیتی هستند، و اعداد صحیح بلند، که می‌توانند اندازه دلخواه داشته باشند، در حال تبدیل شدن به یک مزاحمت بود. برای مثال، در پلتفرم‌هایی که از پرونده‌های بزرگ‌تر از ``2**32`` بایت پشتیبانی می‌کنند، متد :meth:`!tell` اشیای پرونده باید یک عدد صحیح بلند را بازگرداند. با این حال، بخش‌های مختلفی از پایتون وجود داشتند که انتظار اعداد صحیح ساده را داشتند و اگر به جای آن یک عدد صحیح بلند ارائه می‌شد، خطا ایجاد می‌کردند. برای مثال، در پایتون 1.5، فقط اعداد صحیح معمولی می‌توانستند به عنوان اندیس اسلایس استفاده شوند و ``'abc'[1L:]`` استثنای :exc:`TypeError` را با پیام 'slice index must be int' ایجاد می‌کرد."

msgid "Python 2.2 will shift values from short to long integers as required. The 'L' suffix is no longer needed to indicate a long integer literal, as now the compiler will choose the appropriate type.  (Using the 'L' suffix will be discouraged in future 2.x versions of Python, triggering a warning in Python 2.4, and probably dropped in Python 3.0.)  Many operations that used to raise an :exc:`OverflowError` will now return a long integer as their result.  For example::"
msgstr "پایتون 2.2 در صورت نیاز مقادیر را از اعداد صحیح کوتاه به اعداد صحیح بلند تبدیل می‌کند. پسوند 'L' دیگر برای نشان دادن یک مقدار لفظی عدد صحیح بلند لازم نیست، زیرا اکنون کامپایلر نوع مناسب را انتخاب می‌کند.  (استفاده از پسوند 'L' در نسخه‌های 2.x آینده پایتون توصیه نخواهد شد، در پایتون 2.4 هشداری صادر می‌کند و احتمالاً در پایتون 3.0 حذف خواهد شد.)  بسیاری از عملیاتی که پیش‌تر استثنای :exc:`OverflowError` ایجاد می‌کردند، اکنون یک عدد صحیح بلند را به‌عنوان نتیجه برمی‌گردانند.  برای مثال::"

msgid ""
">>> 1234567890123\n"
"1234567890123L\n"
">>> 2 ** 64\n"
"18446744073709551616L"
msgstr ""
">>> 1234567890123\n"
"1234567890123L\n"
">>> 2 ** 64\n"
"18446744073709551616L"

msgid "In most cases, integers and long integers will now be treated identically.  You can still distinguish them with the :func:`type` built-in function, but that's rarely needed."
msgstr "در بیشتر موارد، اعداد صحیح و اعداد صحیح بلند از این پس به‌طور یکسان در نظر گرفته می‌شوند. شما همچنان می‌توانید آن‌ها را با تابع توکار :func:`type` از هم تشخیص دهید، اما این کار به‌ندرت لازم است."

msgid ":pep:`237` - Unifying Long Integers and Integers"
msgstr ":pep:`237` - یکسان‌سازی اعداد صحیح بلند و اعداد صحیح"

msgid "Written by Moshe Zadka and Guido van Rossum.  Implemented mostly by Guido van Rossum."
msgstr "نوشته‌شده توسط Moshe Zadka و Guido van Rossum.  پیاده‌سازی‌شده عمدتاً توسط Guido van Rossum."

msgid "PEP 238: Changing the Division Operator"
msgstr "PEP 238: تغییر عملگر تقسیم"

msgid "The most controversial change in Python 2.2 heralds the start of an effort to fix an old design flaw that's been in Python from the beginning. Currently Python's division operator, ``/``, behaves like C's division operator when presented with two integer arguments: it returns an integer result that's truncated down when there would be a fractional part.  For example, ``3/2`` is 1, not 1.5, and ``(-1)/2`` is -1, not -0.5.  This means that the results of division can vary unexpectedly depending on the type of the two operands and because Python is dynamically typed, it can be difficult to determine the possible types of the operands."
msgstr "جنجالی‌ترین تغییر در پایتون 2.2، آغازگر تلاشی برای رفع نقص طراحی قدیمی‌ای است که از ابتدا در پایتون وجود داشته است. در حال حاضر، عملگر تقسیم پایتون، ``/``، هنگامی که با دو آرگومان عدد صحیح روبه‌رو شود، مانند عملگر تقسیم C رفتار می‌کند: نتیجه‌ای از نوع عدد صحیح برمی‌گرداند که در صورت وجود بخش کسری، به سمت پایین گرد می‌شود. برای مثال، ``3/2`` برابر با ۱ است، نه ۱٫۵، و ``(-1)/2`` برابر با -۱ است، نه -۰٫۵. این بدان معناست که نتایج تقسیم می‌توانند بسته به نوع دو عملوند، به‌طور غیرمنتظره‌ای متفاوت باشند و از آنجا که پایتون به صورت پویا نوع‌دهی می‌شود، تعیین انواع ممکن عملوندها می‌تواند دشوار باشد."

msgid "(The controversy is over whether this is *really* a design flaw, and whether it's worth breaking existing code to fix this.  It's caused endless discussions on python-dev, and in July 2001 erupted into a storm of acidly sarcastic postings on :newsgroup:`comp.lang.python`. I won't argue for either side here and will stick to describing what's  implemented in 2.2.  Read :pep:`238` for a summary of arguments and counter-arguments.)"
msgstr "(مناقشه بر سر این است که آیا این *واقعاً* یک نقص طراحی است و آیا رفع این موضوع ارزش شکستن کدهای موجود را دارد. این موضوع باعث بحث‌های بی‌پایانی در python-dev شده است و در ژوئیه ۲۰۰۱ به طوفانی از پیام‌های طعنه‌آمیز و تلخ در :newsgroup:`comp.lang.python` تبدیل شد. من اینجا از هیچ‌یک از طرفین جانب‌داری نمی‌کنم و به توصیف آنچه در 2.2 پیاده‌سازی شده است پایبند می‌مانم. برای خلاصه‌ای از استدلال‌ها و استدلال‌های مقابل، :pep:`238` را بخوانید.)"

msgid "Because this change might break code, it's being introduced very gradually. Python 2.2 begins the transition, but the switch won't be complete until Python 3.0."
msgstr "از آنجا که این تغییر ممکن است کد را بشکند، به‌طور بسیار تدریجی معرفی می‌شود. پایتون 2.2 این گذار را آغاز می‌کند، اما این تعویض تا پایتون 3.0 کامل نخواهد شد."

msgid "First, I'll borrow some terminology from :pep:`238`.  \"True division\" is the division that most non-programmers are familiar with: 3/2 is 1.5, 1/4 is 0.25, and so forth.  \"Floor division\" is what Python's ``/`` operator currently does when given integer operands; the result is the floor of the value returned by true division.  \"Classic division\" is the current mixed behaviour of ``/``; it returns the result of floor division when the operands are integers, and returns the result of true division when one of the operands is a floating-point number."
msgstr "ابتدا، برخی اصطلاحات را از :pep:`238` وام می‌گیرم. «تقسیم حقیقی» (true division) تقسیمی است که بیشتر غیربرنامه‌نویسان با آن آشنا هستند: ۳/۲ برابر ۱٫۵ است، ۱/۴ برابر ۰٫۲۵ است و به همین ترتیب. «تقسیم کف» همان کاری است که عملگر ``/`` پایتون در حال حاضر هنگام دریافت عملوندهای عدد صحیح انجام می‌دهد؛ نتیجه، کف مقداری است که تقسیم حقیقی برمی‌گرداند. «تقسیم کلاسیک» (classic division) رفتار مختلط فعلی ``/`` است؛ هنگامی که عملوندها عدد صحیح باشند، نتیجه تقسیم کف را برمی‌گرداند و هنگامی که یکی از عملوندها عدد ممیز شناور باشد، نتیجه تقسیم حقیقی را برمی‌گرداند."

msgid "Here are the changes 2.2 introduces:"
msgstr "تغییراتی که 2.2 معرفی می‌کند به شرح زیر است:"

msgid "A new operator, ``//``, is the floor division operator. (Yes, we know it looks like C++'s comment symbol.)  ``//`` *always* performs floor division no matter what the types of its operands are, so ``1 // 2`` is 0 and ``1.0 // 2.0`` is also 0.0."
msgstr "یک عملگر جدید، ``//``، عملگر تقسیم کف است. (بله، می‌دانیم که شبیه نماد کامنت ++C است.) ``//`` *همیشه* تقسیم کف را انجام می‌دهد، مهم نیست که عملوندهای آن چه نوعی باشند؛ بنابراین ``1 // 2`` برابر 0 است و ``1.0 // 2.0`` نیز برابر 0.0 است."

msgid "``//`` is always available in Python 2.2; you don't need to enable it using a ``__future__`` statement."
msgstr "``//`` در پایتون 2.2 همیشه در دسترس است؛ لازم نیست آن را با استفاده از دستور ``__future__`` فعال کنید."

msgid "By including a ``from __future__ import division`` in a module, the ``/`` operator will be changed to return the result of true division, so ``1/2`` is 0.5.  Without the ``__future__`` statement, ``/`` still means classic division. The default meaning of ``/`` will not change until Python 3.0."
msgstr "با گنجاندن ``from __future__ import division`` در یک ماژول، عملگر ``/`` طوری تغییر می‌کند که نتیجه‌ی تقسیم حقیقی را برگرداند؛ بنابراین ``1/2`` برابر ۰.۵ است. بدون دستور ``__future__``، ``/`` همچنان به معنای تقسیم کلاسیک است. معنای پیش‌فرض ``/`` تا پایتون 3.0 تغییر نخواهد کرد."

msgid "Classes can define methods called :meth:`~object.__truediv__` and :meth:`~object.__floordiv__` to overload the two division operators.  At the C level, there are also slots in the :c:type:`PyNumberMethods` structure so extension types can define the two operators."
msgstr "کلاس‌ها می‌توانند متدهایی به نام :meth:`~object.__truediv__` و :meth:`~object.__floordiv__` تعریف کنند تا دو عملگر تقسیم را سربارگذاری کنند. در سطح C، جایگاه‌هایی نیز در ساختار :c:type:`PyNumberMethods` وجود دارد تا نوع‌های توسعه‌ای بتوانند این دو عملگر را تعریف کنند."

msgid "Python 2.2 supports some command-line arguments for testing whether code will work with the changed division semantics.  Running python with :option:`!-Q warn` will cause a warning to be issued whenever division is applied to two integers.  You can use this to find code that's affected by the change and fix it.  By default, Python 2.2 will simply perform classic division without a warning; the warning will be turned on by default in Python 2.3."
msgstr "پایتون 2.2 از چند آرگومان خط فرمان برای آزمایش اینکه آیا کد با معناشناسی تغییر‌یافته‌ی تقسیم کار خواهد کرد، پشتیبانی می‌کند. اجرای python با :option:`!-Q warn` باعث می‌شود هرگاه تقسیم روی دو عدد صحیح اعمال شود، هشداری صادر شود. می‌توانید از این برای یافتن کدهای متأثر از این تغییر و اصلاح آن‌ها استفاده کنید. به‌طور پیش‌فرض، پایتون 2.2 صرفاً تقسیم کلاسیک را بدون هیچ هشداری انجام می‌دهد؛ این هشدار در پایتون 2.3 به‌طور پیش‌فرض فعال خواهد شد."

msgid ":pep:`238` - Changing the Division Operator"
msgstr ":pep:`238` - تغییر عملگر تقسیم"

msgid "Written by Moshe Zadka and  Guido van Rossum.  Implemented by Guido van Rossum.."
msgstr "نوشته‌شده توسط موشه زادکا و گیدو ون روسوم. پیاده‌سازی‌شده توسط گیدو ون روسوم."

msgid "Unicode Changes"
msgstr "تغییرات یونیکد"

msgid "Python's Unicode support has been enhanced a bit in 2.2.  Unicode strings are usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by supplying :option:`!--enable-unicode=ucs4` to the configure script.   (It's also possible to specify :option:`!--disable-unicode` to completely disable Unicode support.)"
msgstr "پشتیبانی پایتون از یونیکد در نسخه‌ی 2.2 کمی بهبود یافته است. رشته‌های یونیکد معمولاً به‌صورت UCS-2، یعنی اعداد صحیح بدون علامت ۱۶ بیتی، ذخیره می‌شوند. پایتون 2.2 همچنین می‌تواند با ارائه‌ی :option:`!--enable-unicode=ucs4` به اسکریپت configure، به‌گونه‌ای کامپایل شود که از UCS-4، یعنی اعداد صحیح بدون علامت ۳۲ بیتی، به‌عنوان کدگذاری داخلی خود استفاده کند. (همچنین می‌توان :option:`!--disable-unicode` را مشخص کرد تا پشتیبانی از یونیکد به‌طور کامل غیرفعال شود.)"

msgid "When built to use UCS-4 (a \"wide Python\"), the interpreter can natively handle Unicode characters from U+000000 to U+110000, so the range of legal values for the :func:`!unichr` function is expanded accordingly.  Using an interpreter compiled to use UCS-2 (a \"narrow Python\"), values greater than 65535 will still cause :func:`!unichr` to raise a :exc:`ValueError` exception. This is all described in :pep:`261`, \"Support for 'wide' Unicode characters\"; consult it for further details."
msgstr "هنگامی که مفسر برای استفاده از UCS-4 ساخته شود (یک «پایتون پهن»)، می‌تواند به‌طور بومی نویسه‌های یونیکد از U+000000 تا U+110000 را مدیریت کند، بنابراین بازه‌ی مقادیر مجاز برای تابع :func:`!unichr` متناسب با آن گسترش می‌یابد. با استفاده از مفسری که برای استفاده از UCS-2 کامپایل شده است (یک «پایتون باریک»)، مقادیر بزرگ‌تر از ۶۵۵۳۵ همچنان باعث می‌شوند که :func:`!unichr` استثنای :exc:`ValueError` ایجاد کند. همه‌ی این موارد در :pep:`261` با عنوان «پشتیبانی از نویسه‌های یونیکد ‹پهن›» توصیف شده‌اند؛ برای جزئیات بیشتر به آن مراجعه کنید."

msgid "Another change is simpler to explain. Since their introduction, Unicode strings have supported an :meth:`!encode` method to convert the string to a selected encoding such as UTF-8 or Latin-1.  A symmetric ``decode([*encoding*])`` method has been added to 8-bit strings (though not to Unicode strings) in 2.2. :meth:`!decode` assumes that the string is in the specified encoding and decodes it, returning whatever is returned by the codec."
msgstr "توضیح تغییر دیگری ساده‌تر است. از زمان معرفی‌شان، رشته‌های یونیکد از یک متد :meth:`!encode` برای تبدیل رشته به یک کدگذاری انتخاب‌شده مانند UTF-8 یا Latin-1 پشتیبانی کرده‌اند. در نسخه 2.2، یک متد متقارن ``decode([*encoding*])`` به رشته‌های ۸-بیتی اضافه شده است (هرچند نه به رشته‌های یونیکد). :meth:`!decode` فرض می‌کند که رشته در کدگذاری مشخص‌شده است و آن را کدگشایی می‌کند و هر آنچه را که کدک برمی‌گرداند، برمی‌گرداند."

msgid "Using this new feature, codecs have been added for tasks not directly related to Unicode.  For example, codecs have been added for uu-encoding, MIME's base64 encoding, and compression with the :mod:`zlib` module::"
msgstr "با استفاده از این قابلیت جدید، کدک‌هایی برای کارهایی که ارتباط مستقیمی با یونیکد ندارند افزوده شده‌اند. برای مثال، کدک‌هایی برای کدگذاری uu، کدگذاری base64 در MIME و فشرده‌سازی با ماژول :mod:`zlib` افزوده شده‌اند::"

msgid ""
">>> s = \"\"\"Here is a lengthy piece of redundant, overly verbose,\n"
"... and repetitive text.\n"
"... \"\"\"\n"
">>> data = s.encode('zlib')\n"
">>> data\n"
"'x\\x9c\\r\\xc9\\xc1\\r\\x80 \\x10\\x04\\xc0?Ul...'\n"
">>> data.decode('zlib')\n"
"'Here is a lengthy piece of redundant, overly verbose,\\nand repetitive text.\\n'\n"
">>> print s.encode('uu')\n"
"begin 666 <data>\n"
"M2&5R92!I<R!A(&QE;F=T:'D@<&EE8V4@;V8@<F5D=6YD86YT+\"!O=F5R;'D@\n"
">=F5R8F]S92P*86YD(')E<&5T:71I=F4@=&5X=\"X*\n"
"\n"
"end\n"
">>> \"sheesh\".encode('rot-13')\n"
"'furrfu'"
msgstr ""
">>> s = \"\"\"Here is a lengthy piece of redundant, overly verbose,\n"
"... and repetitive text.\n"
"... \"\"\"\n"
">>> data = s.encode('zlib')\n"
">>> data\n"
"'x\\x9c\\r\\xc9\\xc1\\r\\x80 \\x10\\x04\\xc0?Ul...'\n"
">>> data.decode('zlib')\n"
"'Here is a lengthy piece of redundant, overly verbose,\\nand repetitive text.\\n'\n"
">>> print s.encode('uu')\n"
"begin 666 <data>\n"
"M2&5R92!I<R!A(&QE;F=T:'D@<&EE8V4@;V8@<F5D=6YD86YT+\"!O=F5R;'D@\n"
">=F5R8F]S92P*86YD(')E<&5T:71I=F4@=&5X=\"X*\n"
"\n"
"end\n"
">>> \"sheesh\".encode('rot-13')\n"
"'furrfu'"

msgid "To convert a class instance to Unicode, a :meth:`!__unicode__` method can be defined by a class, analogous to :meth:`!__str__`."
msgstr "برای تبدیل نمونه‌ی یک کلاس به یونیکد، می‌توان متد :meth:`!__unicode__` را در کلاس تعریف کرد، مشابه :meth:`!__str__`."

msgid ":meth:`!encode`, :meth:`!decode`, and :meth:`!__unicode__` were implemented by Marc-André Lemburg.  The changes to support using UCS-4 internally were implemented by Fredrik Lundh and Martin von Löwis."
msgstr ":meth:`!encode`، :meth:`!decode` و :meth:`!__unicode__` توسط Marc-André Lemburg پیاده‌سازی شدند. تغییرات مربوط به پشتیبانی از استفاده از UCS-4 به‌صورت داخلی توسط Fredrik Lundh و Martin von Löwis پیاده‌سازی شدند."

msgid ":pep:`261` - Support for 'wide' Unicode characters"
msgstr ":pep:`261` - پشتیبانی از نویسه‌های یونیکد «پهن»"

msgid "Written by Paul Prescod."
msgstr "نوشته‌ی پل پرسکاد."

msgid "PEP 227: Nested Scopes"
msgstr "PEP 227: محدوده‌های تودرتو"

msgid "In Python 2.1, statically nested scopes were added as an optional feature, to be enabled by a ``from __future__ import nested_scopes`` directive.  In 2.2 nested scopes no longer need to be specially enabled, and are now always present.  The rest of this section is a copy of the description of nested scopes from my \"What's New in Python 2.1\" document; if you read it when 2.1 came out, you can skip the rest of this section."
msgstr "در پایتون 2.1، محدوده‌های تودرتوی ایستا به‌عنوان یک قابلیت اختیاری افزوده شد که با دایرکتیو ``from __future__ import nested_scopes`` فعال می‌شد. در 2.2، محدوده‌های تودرتو دیگر نیازی به فعال‌سازی خاص ندارند و اکنون همیشه وجود دارند. باقی این بخش رونوشتی از شرح محدوده‌های تودرتو از سند «What's New in Python 2.1» من است؛ اگر آن را هنگام انتشار 2.1 خوانده‌اید، می‌توانید از خواندن باقی این بخش صرف‌نظر کنید."

msgid "The largest change introduced in Python 2.1, and made complete in 2.2, is to Python's scoping rules.  In Python 2.0, at any given time there are at most three namespaces used to look up variable names: local, module-level, and the built-in namespace.  This often surprised people because it didn't match their intuitive expectations.  For example, a nested recursive function definition doesn't work::"
msgstr "بزرگ‌ترین تغییری که در Python 2.1 معرفی شد و در 2.2 تکمیل شد، در قواعد تعیین محدوده پایتون است. در Python 2.0، در هر لحظه حداکثر سه فضای نام برای جستجوی نام‌های متغیر وجود دارد: محلی، سطح ماژول، و فضای نام توکار. این موضوع اغلب افراد را غافلگیر می‌کرد، زیرا با انتظارات شهودی آن‌ها مطابقت نداشت. برای مثال، تعریف یک تابع بازگشتی تودرتو کار نمی‌کند::"

msgid ""
"def f():\n"
"    ...\n"
"    def g(value):\n"
"        ...\n"
"        return g(value-1) + 1\n"
"    ..."
msgstr ""
"def f():\n"
"    ...\n"
"    def g(value):\n"
"        ...\n"
"        return g(value-1) + 1\n"
"    ..."

msgid "The function :func:`!g` will always raise a :exc:`NameError` exception, because the binding of the name ``g`` isn't in either its local namespace or in the module-level namespace.  This isn't much of a problem in practice (how often do you recursively define interior functions like this?), but this also made using the :keyword:`lambda` expression clumsier, and this was a problem in practice. In code which uses :keyword:`!lambda` you can often find local variables being copied by passing them as the default values of arguments. ::"
msgstr "تابع :func:`!g` همیشه استثنای :exc:`NameError` ایجاد می‌کند، زیرا مقید‌سازی نام ``g`` نه در فضای نام محلی آن و نه در فضای نام در سطح ماژول وجود ندارد. این موضوع در عمل مشکل چندانی نیست (چند وقت یک‌بار توابع داخلی را به این صورت بازگشتی تعریف می‌کنید؟)، اما همین امر استفاده از عبارت :keyword:`lambda` را نیز ناشیانه‌تر می‌کرد و این در عمل مشکل‌ساز بود. در کدی که از :keyword:`!lambda` استفاده می‌کند، اغلب می‌توانید متغیرهای محلی را بیابید که با پاس دادن آن‌ها به‌عنوان مقادیر پیش‌فرض آرگومان‌ها کپی شده‌اند. ::"

msgid ""
"def find(self, name):\n"
"    \"Return list of any entries equal to 'name'\"\n"
"    L = filter(lambda x, name=name: x == name,\n"
"               self.list_attribute)\n"
"    return L"
msgstr ""
"def find(self, name):\n"
"    \"Return list of any entries equal to 'name'\"\n"
"    L = filter(lambda x, name=name: x == name,\n"
"               self.list_attribute)\n"
"    return L"

msgid "The readability of Python code written in a strongly functional style suffers greatly as a result."
msgstr "در نتیجه، خوانایی کد پایتونی که به سبکی کاملاً تابعی نوشته شده است، به‌شدت آسیب می‌بیند."

msgid "The most significant change to Python 2.2 is that static scoping has been added to the language to fix this problem.  As a first effect, the ``name=name`` default argument is now unnecessary in the above example.  Put simply, when a given variable name is not assigned a value within a function (by an assignment, or the :keyword:`def`, :keyword:`class`, or :keyword:`import` statements), references to the variable will be looked up in the local namespace of the enclosing scope.  A more detailed explanation of the rules, and a dissection of the implementation, can be found in the PEP."
msgstr "مهم‌ترین تغییر در پایتون 2.2 این است که محدوده‌بندی ایستا (static scoping) برای رفع این مشکل به زبان افزوده شده است. به عنوان نخستین اثر، آرگومان پیش‌فرض ``name=name`` در مثال بالا دیگر لازم نیست. به بیان ساده، وقتی درون یک تابع مقداری به نام متغیر معینی انتساب داده نشده باشد (از طریق یک انتساب، یا دستورهای :keyword:`def`، :keyword:`class` یا :keyword:`import`)، ارجاع‌ها به آن متغیر در فضای نام محلیِ محدوده‌ی دربرگیرنده جستجو خواهند شد. توضیح دقیق‌تری از قواعد، به همراه کالبدشکافی پیاده‌سازی، را می‌توان در PEP (پیشنهاد بهبود پایتون) یافت."

msgid "This change may cause some compatibility problems for code where the same variable name is used both at the module level and as a local variable within a function that contains further function definitions. This seems rather unlikely though, since such code would have been pretty confusing to read in the first place."
msgstr "این تغییر ممکن است برای کدهایی که در آن‌ها نام یک متغیر هم در سطح ماژول و هم به‌عنوان متغیر محلی درون تابعی که تعریف‌های تابع دیگری را در بر می‌گیرد استفاده می‌شود، برخی مشکلات سازگاری ایجاد کند. با این حال، این موضوع نسبتاً بعید به نظر می‌رسد، چون خواندن چنین کدی از همان ابتدا بسیار گیج‌کننده بود."

msgid "One side effect of the change is that the ``from module import *`` and ``exec`` statements have been made illegal inside a function scope under certain conditions.  The Python reference manual has said all along that ``from module import *`` is only legal at the top level of a module, but the CPython interpreter has never enforced this before.  As part of the implementation of nested scopes, the compiler which turns Python source into bytecodes has to generate different code to access variables in a containing scope.  ``from module import *`` and ``exec`` make it impossible for the compiler to figure this out, because they add names to the local namespace that are unknowable at compile time. Therefore, if a function contains function definitions or :keyword:`lambda` expressions with free variables, the compiler will flag this by raising a :exc:`SyntaxError` exception."
msgstr "یکی از اثرهای جانبی این تغییر این است که دستورهای ``from module import *`` و ``exec`` تحت شرایط خاصی درون محدوده‌ی یک تابع غیرمجاز شده‌اند. راهنمای مرجع پایتون همواره گفته است که ``from module import *`` فقط در سطح بالای یک ماژول مجاز است، اما مفسر سی‌پایتون پیش از این هرگز این را اعمال نکرده بود. به‌عنوان بخشی از پیاده‌سازی محدوده‌های تودرتو، کامپایلری که کد منبع پایتون را به بایت‌کد تبدیل می‌کند، باید کد متفاوتی برای دسترسی به متغیرها در یک محدوده‌ی دربرگیرنده تولید کند. دستورهای ``from module import *`` و ``exec`` باعث می‌شوند کامپایلر نتواند این موضوع را تشخیص دهد، زیرا این دستورها نام‌هایی به فضای نام محلی اضافه می‌کنند که در زمان کامپایل قابل شناسایی نیستند. بنابراین، اگر تابعی شامل تعریف‌های تابع یا عبارت‌های :keyword:`lambda` با متغیرهای آزاد باشد، کامپایلر این موضوع را با ایجاد یک استثنای :exc:`SyntaxError` علامت‌گذاری می‌کند."

msgid "To make the preceding explanation a bit clearer, here's an example::"
msgstr "برای روشن‌تر شدن توضیح پیشین، در اینجا مثالی می‌آوریم::"

msgid ""
"x = 1\n"
"def f():\n"
"    # The next line is a syntax error\n"
"    exec 'x=2'\n"
"    def g():\n"
"        return x"
msgstr ""
"x = 1\n"
"def f():\n"
"    # The next line is a syntax error\n"
"    exec 'x=2'\n"
"    def g():\n"
"        return x"

msgid "Line 4 containing the ``exec`` statement is a syntax error, since ``exec`` would define a new local variable named ``x`` whose value should be accessed by :func:`!g`."
msgstr "سطر ۴ که حاوی دستور ``exec`` است، یک خطای نحوی است، زیرا ``exec`` یک متغیر محلی جدید با نام ``x`` تعریف می‌کند که :func:`!g` باید به مقدار آن دسترسی داشته باشد."

msgid "This shouldn't be much of a limitation, since ``exec`` is rarely used in most Python code (and when it is used, it's often a sign of a poor design anyway)."
msgstr "این نباید محدودیت چندانی باشد، زیرا ``exec`` به‌ندرت در بیشتر کدهای پایتون استفاده می‌شود (و هنگامی که استفاده می‌شود، به‌هرحال اغلب نشانه‌ی یک طراحی ضعیف است)."

msgid ":pep:`227` - Statically Nested Scopes"
msgstr ":pep:`227` - محدوده‌های تودرتوی ایستا"

msgid "Written and implemented by Jeremy Hylton."
msgstr "نوشته و پیاده‌سازی‌شده توسط جرمی هایلتون."

msgid "New and Improved Modules"
msgstr "ماژول‌های جدید و بهبودیافته"

msgid "The :mod:`xmlrpclib <xmlrpc.client>` module was contributed to the standard library by Fredrik Lundh, providing support for writing XML-RPC clients.  XML-RPC is a simple remote procedure call protocol built on top of HTTP and XML. For example, the following snippet retrieves a list of RSS channels from the O'Reilly Network, and then  lists the recent headlines for one channel::"
msgstr "ماژول :mod:`xmlrpclib <xmlrpc.client>` توسط Fredrik Lundh به کتابخانه استاندارد افزوده شد و پشتیبانی از نوشتن کلاینت‌های XML-RPC را فراهم می‌کند. XML-RPC یک پروتکل ساده‌ی فراخوانی رویه از راه دور است که بر پایه‌ی HTTP و XML ساخته شده است. برای مثال، قطعه کد زیر فهرستی از کانال‌های RSS را از O'Reilly Network بازیابی می‌کند و سپس عناوین اخیر یک کانال را فهرست می‌کند::"

msgid ""
"import xmlrpclib\n"
"s = xmlrpclib.Server(\n"
"      'http://www.oreillynet.com/meerkat/xml-rpc/server.php')\n"
"channels = s.meerkat.getChannels()\n"
"# channels is a list of dictionaries, like this:\n"
"# [{'id': 4, 'title': 'Freshmeat Daily News'}\n"
"#  {'id': 190, 'title': '32Bits Online'},\n"
"#  {'id': 4549, 'title': '3DGamers'}, ... ]\n"
"\n"
"# Get the items for one channel\n"
"items = s.meerkat.getItems( {'channel': 4} )\n"
"\n"
"# 'items' is another list of dictionaries, like this:\n"
"# [{'link': 'http://freshmeat.net/releases/52719/',\n"
"#   'description': 'A utility which converts HTML to XSL FO.',\n"
"#   'title': 'html2fo 0.3 (Default)'}, ... ]"
msgstr ""
"import xmlrpclib\n"
"s = xmlrpclib.Server(\n"
"      'http://www.oreillynet.com/meerkat/xml-rpc/server.php')\n"
"channels = s.meerkat.getChannels()\n"
"# channels is a list of dictionaries, like this:\n"
"# [{'id': 4, 'title': 'Freshmeat Daily News'}\n"
"#  {'id': 190, 'title': '32Bits Online'},\n"
"#  {'id': 4549, 'title': '3DGamers'}, ... ]\n"
"\n"
"# Get the items for one channel\n"
"items = s.meerkat.getItems( {'channel': 4} )\n"
"\n"
"# 'items' is another list of dictionaries, like this:\n"
"# [{'link': 'http://freshmeat.net/releases/52719/',\n"
"#   'description': 'A utility which converts HTML to XSL FO.',\n"
"#   'title': 'html2fo 0.3 (Default)'}, ... ]"

msgid "The :mod:`SimpleXMLRPCServer <xmlrpc.server>` module makes it easy to create straightforward XML-RPC servers.  See http://xmlrpc.scripting.com/ for more information about XML-RPC."
msgstr "ماژول :mod:`SimpleXMLRPCServer <xmlrpc.server>` ایجاد سرورهای ساده XML-RPC را آسان می‌کند. برای اطلاعات بیشتر درباره XML-RPC به http://xmlrpc.scripting.com/ مراجعه کنید."

msgid "The new :mod:`hmac` module implements the HMAC algorithm described by :rfc:`2104`. (Contributed by Gerhard Häring.)"
msgstr "ماژول جدید :mod:`hmac` الگوریتم HMAC توصیف‌شده در :rfc:`2104` را پیاده‌سازی می‌کند. (با مشارکت Gerhard Häring.)"

msgid "Several functions that originally returned lengthy tuples now return pseudo-sequences that still behave like tuples but also have mnemonic attributes such as :attr:`!memberst_mtime` or :attr:`~time.struct_time.tm_year`. The enhanced functions include :func:`~os.stat`, :func:`~os.fstat`, :func:`~os.statvfs`, and :func:`~os.fstatvfs` in the :mod:`os` module, and :func:`~time.localtime`, :func:`~time.gmtime`, and :func:`~time.strptime` in the :mod:`time` module."
msgstr "چندین تابع که در ابتدا تاپل‌های طولانی برمی‌گرداندند، اکنون شبه‌دنباله‌هایی (pseudo-sequence) برمی‌گردانند که همچنان مانند تاپل‌ها رفتار می‌کنند، اما ویژگی‌های یادیاری مانند :attr:`!memberst_mtime` یا :attr:`~time.struct_time.tm_year` نیز دارند. توابع ارتقایافته شامل :func:`~os.stat`، :func:`~os.fstat`، :func:`~os.statvfs` و :func:`~os.fstatvfs` در ماژول :mod:`os` و :func:`~time.localtime`، :func:`~time.gmtime` و :func:`~time.strptime` در ماژول :mod:`time` هستند."

msgid "For example, to obtain a file's size using the old tuples, you'd end up writing something like ``file_size = os.stat(filename)[stat.ST_SIZE]``, but now this can be written more clearly as ``file_size = os.stat(filename).st_size``."
msgstr "برای مثال، برای به‌دست آوردن اندازه‌ی یک پرونده با استفاده از تاپل‌های قدیمی، در نهایت مجبور بودید چیزی شبیه ``file_size = os.stat(filename)[stat.ST_SIZE]`` بنویسید، اما اکنون می‌توان آن را واضح‌تر به‌صورت ``file_size = os.stat(filename).st_size`` نوشت."

msgid "The original patch for this feature was contributed by Nick Mathewson."
msgstr "وصل اصلی این قابلیت توسط نیک متیوسون ارائه شد."

msgid "The Python profiler has been extensively reworked and various errors in its output have been corrected.  (Contributed by Fred L. Drake, Jr. and Tim Peters.)"
msgstr "پروفایل‌گیر پایتون به‌طور گسترده بازنویسی شده و خطاهای گوناگونی در خروجی آن اصلاح شده‌اند. (با مشارکت Fred L. Drake, Jr. و Tim Peters.)"

msgid "The :mod:`socket` module can be compiled to support IPv6; specify the :option:`!--enable-ipv6` option to Python's configure script.  (Contributed by Jun-ichiro \"itojun\" Hagino.)"
msgstr "ماژول :mod:`socket` را می‌توان طوری کامپایل کرد که از IPv6 پشتیبانی کند؛ گزینه‌ی :option:`!--enable-ipv6` را به اسکریپت configure پایتون بدهید.  (مشارکت‌شده توسط Jun-ichiro \"itojun\" Hagino.)"

msgid "Two new format characters were added to the :mod:`struct` module for 64-bit integers on platforms that support the C :c:expr:`long long` type.  ``q`` is for a signed 64-bit integer, and ``Q`` is for an unsigned one.  The value is returned in Python's long integer type.  (Contributed by Tim Peters.)"
msgstr "دو نویسه‌ی قالب جدید برای اعداد صحیح ۶۴بیتی در پلتفرم‌هایی که نوع :c:expr:`long long` زبان C را پشتیبانی می‌کنند، به ماژول :mod:`struct` اضافه شد. ``q`` برای عدد صحیح ۶۴بیتی علامت‌دار است و ``Q`` برای عدد صحیح بدون علامت است. مقدار در نوع عدد صحیح بلند پایتون برگردانده می‌شود. (مشارکت از Tim Peters.)"

msgid "In the interpreter's interactive mode, there's a new built-in function :func:`help` that uses the :mod:`pydoc` module introduced in Python 2.1 to provide interactive help. ``help(object)`` displays any available help text about *object*.  :func:`help` with no argument puts you in an online help utility, where you can enter the names of functions, classes, or modules to read their help text. (Contributed by Guido van Rossum, using Ka-Ping Yee's :mod:`pydoc` module.)"
msgstr "در حالت تعاملی مفسر، تابع توکار جدیدی به نام :func:`help` وجود دارد که از ماژول :mod:`pydoc` معرفی‌شده در پایتون 2.1 برای ارائه‌ی راهنمای تعاملی استفاده می‌کند. ``help(object)`` هر متن راهنمای موجود درباره‌ی *object* را نمایش می‌دهد. :func:`help` بدون آرگومان شما را به یک ابزار راهنمای برخط می‌برد که در آن می‌توانید نام توابع، کلاس‌ها یا ماژول‌ها را وارد کنید تا متن راهنمای آن‌ها را بخوانید. (ارائه‌شده توسط گیدو ون روسوم، با استفاده از ماژول :mod:`pydoc` نوشته‌ی کا-پینگ یی.)"

msgid "Various bugfixes and performance improvements have been made to the SRE engine underlying the :mod:`re` module.  For example, the :func:`re.sub` and :func:`re.split` functions have been rewritten in C.  Another contributed patch speeds up certain Unicode character ranges by a factor of two, and a new :meth:`~re.finditer`  method that returns an iterator over all the non-overlapping matches in  a given string.  (SRE is maintained by Fredrik Lundh.  The BIGCHARSET patch was contributed by Martin von Löwis.)"
msgstr "رفع اشکال‌ها و بهبود‌های کارایی گوناگونی در موتور SRE که زیربنای ماژول :mod:`re` است، انجام شده است. برای مثال، توابع :func:`re.sub` و :func:`re.split` در C بازنویسی شده‌اند. وصلی دیگر که مشارکت شده است، سرعت برخی از بازه‌های نویسه‌ی یونیکد را دو برابر می‌کند، و متد جدید :meth:`~re.finditer` پیمایش‌گری بر روی تمام تطبیق‌های غیرهمپوشان در یک رشته‌ی داده‌شده برمی‌گرداند. (SRE توسط فردریک لوند نگهداری می‌شود. وصل BIGCHARSET توسط مارتین فون لویس ارائه شده است.)"

msgid "The :mod:`smtplib` module now supports :rfc:`2487`, \"Secure SMTP over TLS\", so it's now possible to encrypt the SMTP traffic between a Python program and the mail transport agent being handed a message.  :mod:`smtplib` also supports SMTP authentication.  (Contributed by Gerhard Häring.)"
msgstr "ماژول :mod:`smtplib` اکنون از :rfc:`2487` با عنوان «Secure SMTP over TLS» پشتیبانی می‌کند، بنابراین اکنون می‌توان ترافیک SMTP بین یک برنامه‌ی پایتون و عامل انتقال پست (mail transport agent) که پیامی به آن تحویل داده می‌شود را رمزگذاری کرد. :mod:`smtplib` همچنین از احراز هویت SMTP پشتیبانی می‌کند. (با مشارکت گرهارد هرینگ.)"

msgid "The :mod:`imaplib` module, maintained by Piers Lauder, has support for several new extensions: the NAMESPACE extension defined in :rfc:`2342`, SORT, GETACL and SETACL.  (Contributed by Anthony Baxter and Michel Pelletier.)"
msgstr "ماژول :mod:`imaplib` که توسط Piers Lauder نگهداری می‌شود، از چندین افزونه‌ی جدید پشتیبانی می‌کند: افزونه‌ی NAMESPACE تعریف‌شده در :rfc:`2342`، SORT، GETACL و SETACL.  (مشارکت‌شده توسط Anthony Baxter و Michel Pelletier.)"

msgid "The :mod:`!rfc822` module's parsing of email addresses is now compliant with :rfc:`2822`, an update to :rfc:`822`.  (The module's name is *not* going to be changed to ``rfc2822``.)  A new package, :mod:`email`, has also been added for parsing and generating e-mail messages.  (Contributed by Barry Warsaw, and arising out of his work on Mailman.)"
msgstr "تجزیه‌ی نشانی‌های ایمیل در ماژول :mod:`!rfc822` اکنون با :rfc:`2822` که به‌روزرسانی :rfc:`822` است، سازگار است.  (نام این ماژول به ``rfc2822`` تغییر *نخواهد کرد*.)  یک بسته‌ی جدید به نام :mod:`email` نیز برای تجزیه و تولید پیام‌های ایمیل اضافه شده است.  (مشارکت‌شده توسط Barry Warsaw، و برآمده از کار او روی Mailman.)"

msgid "The :mod:`difflib` module now contains a new :class:`!Differ` class for producing human-readable lists of changes (a \"delta\") between two sequences of lines of text.  There are also two generator functions, :func:`!ndiff` and :func:`!restore`, which respectively return a delta from two sequences, or one of the original sequences from a delta. (Grunt work contributed by David Goodger, from ndiff.py code by Tim Peters who then did the generatorization.)"
msgstr "ماژول :mod:`difflib` اکنون شامل کلاس جدیدی به نام :class:`!Differ` برای تولید فهرست‌های خوانا برای انسان از تغییرات (یک «دلتا») میان دو دنباله از سطرهای متن است. همچنین دو تابع تولیدگر، :func:`!ndiff` و :func:`!restore`، وجود دارند که به ترتیب یک دلتا از روی دو دنباله، یا یکی از دنباله‌های اصلی را از روی یک دلتا برمی‌گردانند. (کار پرزحمت توسط David Goodger ارائه شده است، برگرفته از کد ndiff.py نوشته‌ی Tim Peters که سپس کار تولیدگرسازی (generatorization) را انجام داد.)"

msgid "New constants :const:`!ascii_letters`, :const:`!ascii_lowercase`, and :const:`!ascii_uppercase` were added to the :mod:`string` module.  There were several modules in the standard library that used :const:`!string.letters` to mean the ranges A-Za-z, but that assumption is incorrect when locales are in use, because :const:`!string.letters` varies depending on the set of legal characters defined by the current locale.  The buggy modules have all been fixed to use :const:`!ascii_letters` instead. (Reported by an unknown person; fixed by Fred L. Drake, Jr.)"
msgstr "ثابت‌های جدید :const:`!ascii_letters`، :const:`!ascii_lowercase` و :const:`!ascii_uppercase` به ماژول :mod:`string` اضافه شدند. چندین ماژول در کتابخانه استاندارد وجود داشتند که از :const:`!string.letters` به معنای بازه‌های A-Za-z استفاده می‌کردند، اما این فرض هنگامی که از locale‌ها استفاده می‌شود نادرست است، زیرا :const:`!string.letters` بسته به مجموعه نویسه‌های مجاز تعریف‌شده توسط locale جاری تغییر می‌کند. ماژول‌های دارای اشکال همگی اصلاح شده‌اند تا به‌جای آن از :const:`!ascii_letters` استفاده کنند. (گزارش شده توسط شخصی ناشناس؛ اصلاح شده توسط Fred L. Drake, Jr.)"

msgid "The :mod:`mimetypes` module now makes it easier to use alternative MIME-type databases by the addition of a :class:`~mimetypes.MimeTypes` class, which takes a list of filenames to be parsed.  (Contributed by Fred L. Drake, Jr.)"
msgstr "ماژول :mod:`mimetypes` اکنون با افزودن کلاس :class:`~mimetypes.MimeTypes`، که فهرستی از نام پرونده‌ها را برای تجزیه دریافت می‌کند، استفاده از پایگاه داده‌های جایگزین نوع MIME را آسان‌تر می‌سازد.  (مشارکت Fred L. Drake, Jr.)"

msgid "A :class:`~threading.Timer` class was added to the :mod:`threading` module that allows scheduling an activity to happen at some future time.  (Contributed by Itamar Shtull-Trauring.)"
msgstr "کلاس :class:`~threading.Timer` به ماژول :mod:`threading` اضافه شد که امکان زمان‌بندی یک فعالیت برای رخ دادن در زمانی در آینده را فراهم می‌کند.  (مشارکت‌شده توسط ایتامار شتول-تراورینگ.)"

msgid "Interpreter Changes and Fixes"
msgstr "تغییرات و اصلاحات مفسر"

msgid "Some of the changes only affect people who deal with the Python interpreter at the C level because they're writing Python extension modules, embedding the interpreter, or just hacking on the interpreter itself. If you only write Python code, none of the changes described here will affect you very much."
msgstr "برخی از تغییرات فقط بر کسانی اثر می‌گذارند که در سطح C با مفسر پایتون سروکار دارند، زیرا آن‌ها ماژول‌های توسعه‌ای پایتون می‌نویسند، مفسر را تعبیه می‌کنند، یا صرفاً روی خودِ مفسر هک می‌کنند. اگر شما فقط کد پایتون می‌نویسید، هیچ‌یک از تغییراتی که در اینجا شرح داده شده‌اند، تأثیر زیادی بر شما نخواهند گذاشت."

msgid "Profiling and tracing functions can now be implemented in C, which can operate at much higher speeds than Python-based functions and should reduce the overhead of profiling and tracing.  This  will be of interest to authors of development environments for Python.  Two new C functions were added to Python's API, :c:func:`PyEval_SetProfile` and :c:func:`PyEval_SetTrace`. The existing :func:`sys.setprofile` and :func:`sys.settrace` functions still exist, and have simply been changed to use the new C-level interface.  (Contributed by Fred L. Drake, Jr.)"
msgstr "توابع پروفایل‌گیری و ردگیری اکنون می‌توانند به زبان C پیاده‌سازی شوند؛ توابعی که می‌توانند با سرعت بسیار بالاتری نسبت به توابع مبتنی بر پایتون عمل کنند و باید سربار پروفایل‌گیری و ردگیری را کاهش دهند. این موضوع مورد توجه سازندگان محیط‌های توسعه برای پایتون قرار خواهد گرفت. دو تابع C جدید به API پایتون اضافه شدند: :c:func:`PyEval_SetProfile` و :c:func:`PyEval_SetTrace`. توابع موجود :func:`sys.setprofile` و :func:`sys.settrace` همچنان وجود دارند و صرفاً تغییر کرده‌اند تا از رابط جدید در سطح C استفاده کنند. (مشارکت از سوی Fred L. Drake, Jr.)"

msgid "Another low-level API, primarily of interest to implementers of Python debuggers and development tools, was added. :c:func:`PyInterpreterState_Head` and :c:func:`PyInterpreterState_Next` let a caller walk through all the existing interpreter objects; :c:func:`PyInterpreterState_ThreadHead` and :c:func:`PyThreadState_Next` allow looping over all the thread states for a given interpreter.  (Contributed by David Beazley.)"
msgstr "یک API سطح پایین دیگر اضافه شد که عمدتاً مورد توجه پیاده‌سازان اشکال‌زداها و ابزارهای توسعه‌ی پایتون است. :c:func:`PyInterpreterState_Head` و :c:func:`PyInterpreterState_Next` به فراخواننده اجازه می‌دهند همه‌ی اشیای مفسر موجود را پیمایش کند؛ :c:func:`PyInterpreterState_ThreadHead` و :c:func:`PyThreadState_Next` امکان حلقه زدن روی همه‌ی وضعیت‌های نخ برای یک مفسر معین را فراهم می‌کنند.  (مشارکت‌شده توسط David Beazley.)"

msgid "The C-level interface to the garbage collector has been changed to make it easier to write extension types that support garbage collection and to debug misuses of the functions. Various functions have slightly different semantics, so a bunch of functions had to be renamed.  Extensions that use the old API will still compile but will *not* participate in garbage collection, so updating them for 2.2 should be considered fairly high priority."
msgstr "رابط زباله‌روب در سطح C تغییر کرده است تا نوشتن نوع‌های توسعه‌ای که از زباله‌روبی پشتیبانی می‌کنند و اشکال‌زدایی استفاده‌های نادرست از توابع آسان‌تر شود. توابع مختلفی معناشناسی کمی متفاوتی دارند، بنابراین تعدادی از توابع باید تغییر نام می‌دادند.  ماژول‌های توسعه‌ای که از API قدیمی استفاده می‌کنند همچنان کامپایل خواهند شد، اما در زباله‌روبی شرکت *نخواهند* کرد؛ بنابراین به‌روزرسانی آن‌ها برای 2.2 باید اولویتی نسبتاً بالا در نظر گرفته شود."

msgid "To upgrade an extension module to the new API, perform the following steps:"
msgstr "برای ارتقای یک ماژول توسعه‌ای به API جدید، گام‌های زیر را انجام دهید:"

msgid "Rename :c:macro:`!Py_TPFLAGS_GC` to :c:macro:`Py_TPFLAGS_HAVE_GC`."
msgstr "نام :c:macro:`!Py_TPFLAGS_GC` به :c:macro:`Py_TPFLAGS_HAVE_GC` تغییر یافت."

msgid "Use :c:func:`PyObject_GC_New` or :c:func:`PyObject_GC_NewVar` to allocate"
msgstr "برای تخصیص دادن، از :c:func:`PyObject_GC_New` یا :c:func:`PyObject_GC_NewVar` استفاده کنید"

msgid "objects, and :c:func:`PyObject_GC_Del` to deallocate them."
msgstr "اشیاء، و :c:func:`PyObject_GC_Del` برای آزادسازی آن‌ها."

msgid "Rename :c:func:`!PyObject_GC_Init` to :c:func:`PyObject_GC_Track` and :c:func:`!PyObject_GC_Fini` to :c:func:`PyObject_GC_UnTrack`."
msgstr "تغییر نام :c:func:`!PyObject_GC_Init` به :c:func:`PyObject_GC_Track` و :c:func:`!PyObject_GC_Fini` به :c:func:`PyObject_GC_UnTrack`."

msgid "Remove :c:macro:`!PyGC_HEAD_SIZE` from object size calculations."
msgstr ":c:macro:`!PyGC_HEAD_SIZE` را از محاسبات اندازه شیء حذف کنید."

msgid "Remove calls to :c:func:`!PyObject_AS_GC` and :c:func:`!PyObject_FROM_GC`."
msgstr "فراخوانی‌های :c:func:`!PyObject_AS_GC` و :c:func:`!PyObject_FROM_GC` را حذف کنید."

msgid "A new ``et`` format sequence was added to :c:func:`PyArg_ParseTuple`; ``et`` takes both a parameter and an encoding name, and converts the parameter to the given encoding if the parameter turns out to be a Unicode string, or leaves it alone if it's an 8-bit string, assuming it to already be in the desired encoding.  This differs from the ``es`` format character, which assumes that 8-bit strings are in Python's default ASCII encoding and converts them to the specified new encoding. (Contributed by M.-A. Lemburg, and used for the MBCS support on Windows described in the following section.)"
msgstr "دنباله‌ی قالب جدید ``et`` به تابع :c:func:`PyArg_ParseTuple` اضافه شد؛ ``et`` هم یک پارامتر و هم یک نام کدگذاری می‌گیرد و اگر پارامتر یک رشته‌ی یونیکد باشد، آن را به کدگذاری داده‌شده تبدیل می‌کند، یا اگر یک رشته‌ی ۸ بیتی باشد، آن را دست‌نخورده باقی می‌گذارد، با این فرض که از قبل در کدگذاری موردنظر قرار دارد. این با نویسه‌ی قالب ``es`` متفاوت است که فرض می‌کند رشته‌های ۸ بیتی در کدگذاری پیش‌فرض اسکی پایتون هستند و آن‌ها را به کدگذاری جدید مشخص‌شده تبدیل می‌کند. (مشارکت‌کرده M.-A. Lemburg، و برای پشتیبانی MBCS در ویندوز که در بخش بعدی توضیح داده شده است، استفاده شد.)"