GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing python.github.io — تازه‌های پایتون 3.3

تازه‌های پایتون 3.3¶

این مقاله ویژگی‌های جدید پایتون 3.3 را در مقایسه با 3.2 توضیح می‌دهد. پایتون 3.3 در ۲۹ سپتامبر ۲۰۱۲ منتشر شد. برای جزئیات کامل، فهرست تغییرات را ببینید.

همچنین ببینید

PEP 398 - زمان‌بندی انتشار پایتون 3.3

خلاصه -- نکات برجسته‌ی انتشار¶

ویژگی‌های نحوی جدید:

عبارت جدید yield from برای واگذاری تولیدگر.
سینتکس u'unicode' دوباره برای شیءهای str پذیرفته می‌شود.

ماژول‌های جدید کتابخانه:

faulthandler (به اشکال‌زدایی فروپاشی‌های سطح پایین کمک می‌کند)
ipaddress (اشیاء سطح بالای نمایانگر نشانی‌های IP و نقاب‌ها)
lzma (فشرده‌سازی داده‌ها با استفاده از الگوریتم XZ / LZMA)
unittest.mock (بخش‌هایی از سیستم تحت آزمون خود را با شیءهای ماک جایگزین کنید)
venv (محیط‌های مجازی پایتون، مانند بسته‌ی محبوب virtualenv)

قابلیت‌های جدید توکار:

سلسله‌مراتب استثناهای I/O بازطراحی شد.

بهبودهای پیاده‌سازی:

سازوکار ایمپورت بر پایه‌ی importlib بازنویسی شد.
رشته‌های یونیکد فشرده‌تر.
دیکشنری‌های ویژگی فشرده‌تر.

ماژول‌های کتابخانه‌ای به‌طور چشمگیر بهبودیافته:

شتاب‌دهنده C برای ماژول decimal.
مدیریت بهتر یونیکد در ماژول email (آزمایشی).

بهبودهای امنیتی:

تصادفی‌سازی هش به‌صورت پیش‌فرض فعال است.

لطفاً برای فهرست جامع تغییرات رو به کاربر، به خواندن ادامه دهید.

PEP 405: محیط‌های مجازی¶

محیط‌های مجازی به ایجاد پیکربندی‌های جداگانه‌ی پایتون کمک می‌کنند و در عین حال به‌طور مشترک از یک نصب پایه‌ی سراسری سیستم استفاده می‌کنند تا نگهداری آسان باشد. محیط‌های مجازی مجموعه‌ای از بسته‌های site (site packages) خصوصی خود را دارند (یعنی کتابخانه‌های نصب‌شده به‌صورت محلی) و به‌صورت اختیاری از بسته‌های site سراسری سیستم جدا نگه داشته می‌شوند. مفهوم و پیاده‌سازی آن‌ها از بسته‌ی محبوب شخص ثالث virtualenv الهام گرفته است، اما از یکپارچگی محکم‌تر با هسته‌ی مفسر بهره می‌برد.

این PEP (پیشنهاد بهبود پایتون) ماژول venv را برای دسترسی برنامه‌ای، و اسکریپت pyvenv را برای دسترسی و مدیریت از طریق خط فرمان اضافه می‌کند. مفسر پایتون وجود پرونده‌ی pyvenv.cfg را بررسی می‌کند؛ پرونده‌ای که وجود آن، پایه‌ی درخت پوشه‌های یک محیط مجازی را نشان می‌دهد.

همچنین ببینید

PEP 405 - محیط‌های مجازی پایتون: PEP نوشته‌شده توسط کارل مایر؛ پیاده‌سازی توسط کارل مایر و وینای ساجیپ انجام شده است.

PEP 420: بسته‌های فضای نام ضمنی¶

پشتیبانی بومی برای پوشه‌های بسته که نیازی به پرونده‌های نشانگر __init__.py ندارند و می‌توانند به‌طور خودکار چندین بخش مسیر را در بر بگیرند (الهام‌گرفته از رویکردهای مختلف اشخاص ثالث برای بسته‌های فضای نام، همان‌طور که در PEP 420 توضیح داده شده است)

همچنین ببینید

PEP 420 - بسته‌های فضای نام ضمنی: PEP نوشته‌شده توسط Eric V. Smith؛ پیاده‌سازی توسط Eric V. Smith و Barry Warsaw

PEP 3118: پیاده‌سازی جدید memoryview و مستندات پروتکل بافر¶

پیاده‌سازی PEP 3118 به‌طور چشمگیری بهبود یافته است.

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

شیء memoryview اکنون یک getbufferproc() منطبق با PEP-3118 دارد که نوع درخواست مصرف‌کننده را بررسی می‌کند. قابلیت‌های جدید بسیاری اضافه شده‌اند؛ بیشتر آن‌ها به‌طور کاملاً عمومی برای آرایه‌های ناپیوسته و آرایه‌های دارای زیرآفست (suboffset) کار می‌کنند.

مستندات به‌روزرسانی شده است و مسئولیت‌های هم اکسپورتکنندگان و هم مصرف‌کنندگان را به‌وضوح تشریح می‌کند. پرچم‌های درخواست بافر به پرچم‌های پایه و مرکب گروه‌بندی شده‌اند. چیدمان حافظه‌ی آرایه‌های غیرپیوسته و چندبُعدی به سبک NumPy توضیح داده شده است.

قابلیت‌ها¶

اکنون از همه‌ی مشخص‌کننده‌های قالب تک‌نویسه‌ای بومی در سینتکس ماژول struct (با پیشوند اختیاری '@') پشتیبانی می‌شود.
با رعایت برخی محدودیت‌ها، متد cast() اجازه‌ی تغییر قالب و شکل آرایه‌های پیوسته‌ی C را می‌دهد.
از نمایش‌های فهرست چندبعدی برای هر نوع آرایه پشتیبانی می‌شود.
مقایسه‌های چندبعدی برای هر نوع آرایه پشتیبانی می‌شود.
نماهای حافظه (memoryview) یک‌بعدی از نوع‌های هش‌پذیر (فقط‌خواندنی) با قالب‌های B، b یا c اکنون هش‌پذیر هستند. (مشارکت داده‌شده توسط Antoine Pitrou در bpo-13411.)
از اسلایس‌کردن دلخواه هر نوع آرایه‌ی یک‌بعدی پشتیبانی می‌شود. برای مثال، اکنون می‌توان یک memoryview را با استفاده از گام منفی در O(1) معکوس کرد.

تغییرات API¶

حداکثر تعداد ابعاد به‌طور رسمی به ۶۴ محدود شده است.
نمایش شکل خالی، گام‌ها (strides) و زیرآفست‌ها (suboffsets) اکنون به جای None یک تاپل خالی است.
دسترسی به یک المان memoryview با قالب 'B' (بایت‌های بدون علامت) اکنون یک عدد صحیح برمی‌گرداند (مطابق با سینتکس ماژول struct). برای برگرداندن یک شیء bytes، ابتدا باید نما به 'c' قالب‌ریزی شود.
مقایسه‌های memoryview اکنون از ساختار منطقی عملوندها استفاده می‌کنند و تمام عناصر آرایه را بر اساس مقدار مقایسه می‌کنند. از تمام رشته‌های قالب با سینتکس ماژول struct پشتیبانی می‌شود. نماهای دارای رشته‌های قالب نا‌شناخته همچنان مجاز هستند، اما صرف‌نظر از محتوای نما، همیشه نابرابر مقایسه می‌شوند.
برای سایر تغییرات، تغییرات ساخت و API زبان C و انتقال کد C را ببینید.

(مشارکت‌شده توسط Stefan Krah در bpo-10181.)

همچنین ببینید

PEP 3118 - بازنگری پروتکل بافر

PEP 393: نمایش انعطاف‌پذیر رشته¶

نوع رشته‌ی یونیکد تغییر کرده است تا بسته به نویسه‌ای که بزرگ‌ترین مقدار ترتیبی یونیکد را در رشته‌ی نمایش‌داده‌شده دارد، از چندین نمایش درونی (۱، ۲ یا ۴ بایت) پشتیبانی کند. این امر در موارد رایج امکان نمایشی کارآمد از نظر فضا را فراهم می‌کند، اما دسترسی به UCS-4 کامل را در همه‌ی سیستم‌ها می‌دهد. برای سازگاری با APIهای موجود، ممکن است چندین نمایش به‌صورت موازی وجود داشته باشند؛ به‌مرور زمان، این سازگاری باید به‌تدریج حذف شود.

از سمت پایتون، این تغییر نباید هیچ ایرادی داشته باشد.

در سمت API زبان C، PEP 393 به‌طور کامل با نسخه‌های پیشین سازگار است. API قدیمی باید دست‌کم پنج سال در دسترس باقی بماند. برنامه‌هایی که از API قدیمی استفاده می‌کنند به‌طور کامل از کاهش حافظه بهره‌مند نخواهند شد، یا — بدتر از آن — ممکن است کمی حافظه بیشتر مصرف کنند، زیرا پایتون ممکن است ناچار باشد دو نسخه از هر رشته را نگهداری کند (یکی در قالب قدیمی و دیگری در ذخیره‌سازی کارآمد جدید).

کارکرد¶

تغییراتی که با PEP 393 معرفی شدند به شرح زیر است:

پایتون اکنون همیشه از دامنه‌ی کامل نقطه‌کدهای یونیکد پشتیبانی می‌کند، از جمله نقطه‌کدهای خارج از BMP (یعنی از U+0000 تا U+10FFFF). تمایز میان ساخت‌های باریک و پهن دیگر وجود ندارد و پایتون اکنون حتی در ویندوز مانند یک ساخت‌ پهن رفتار می‌کند.
با از میان رفتن ساخت‌های باریک (narrow builds)، مشکلات مختص به ساخت‌های باریک نیز برطرف شده‌اند، برای مثال:
- len() اکنون برای نویسه‌های خارج از BMP همیشه مقدار ۱ را برمی‌گرداند، بنابراین len('\U0010FFFF') == 1 است؛
- جفت‌های جانشین در مقادیر لفظی رشته بازترکیب نمی‌شوند، بنابراین '\uDBFF\uDFFF' != '\U0010FFFF'؛
- اندیس‌گذاری یا اسلایس‌کردن نویسه‌های خارج از BMP مقدار مورد انتظار را برمی‌گرداند، بنابراین '\U0010FFFF'[0] اکنون '\U0010FFFF' را برمی‌گرداند و نه '\uDBFF' را؛
- تمام توابع دیگر در کتابخانه‌ی استاندارد اکنون به‌درستی نقاط کد خارج از سطح چندزبانه‌ی پایه (BMP) را مدیریت می‌کنند.
مقدار sys.maxunicode اکنون همیشه 1114111 است (0x10FFFF در مبنای شانزده). تابع PyUnicode_GetMax() همچنان 0xFFFF یا 0x10FFFF را برای سازگاری با نسخه‌های پیشین برمی‌گرداند و نباید با API یونیکد جدید استفاده شود (به bpo-13054 مراجعه کنید).
پرچم --with-wide-unicode در ./configure حذف شده است.

کارایی و استفاده از منابع¶

ذخیره‌سازی رشته‌های یونیکد اکنون به بالاترین نقطه‌کد در رشته بستگی دارد:

رشته‌های خالص اسکی و Latin1 (U+0000-U+00FF) به ازای هر نقطه‌کد ۱ بایت استفاده می‌کنند؛
رشته‌های BMP (U+0000-U+FFFF) به ازای هر نقطه‌کد ۲ بایت استفاده می‌کنند؛
رشته‌های غیر BMP (U+10000-U+10FFFF) به ازای هر نقطه‌کد از ۴ بایت استفاده می‌کنند.

اثر خالص این است که برای بیشتر برنامه‌ها، مصرف حافظه‌ی ذخیره‌سازی رشته‌ها باید به‌طور چشمگیری کاهش یابد - به‌ویژه در مقایسه با ساخت‌های پیشین یونیکد پهن - زیرا در بسیاری از موارد، رشته‌ها حتی در زمینه‌های بین‌المللی نیز اسکی خالص خواهند بود (چرا که بسیاری از رشته‌ها داده‌هایی ذخیره می‌کنند که زبان انسانی نیستند، مانند قطعه‌های XML، سرآیندهای HTTP، داده‌های کدگذاری‌شده با JSON و غیره). ما همچنین امیدواریم که به همین دلایل، کارایی نهانگاه CPU را در برنامه‌های غیربدیهی افزایش دهد. مصرف حافظه‌ی پایتون 3.3 در یک بنچمارک Django دو تا سه برابر کمتر از پایتون 3.2 و کمی بهتر از پایتون 2.7 است (برای جزئیات به PEP مراجعه کنید).

همچنین ببینید

PEP 393 - نمایش انعطاف‌پذیر رشته: نگارش PEP توسط مارتین فون لویس؛ پیاده‌سازی توسط تورستن بکر و مارتین فون لویس.

PEP 397: راه‌انداز پایتون برای ویندوز¶

نصاب ویندوزی پایتون 3.3 اکنون شامل یک برنامه راه‌انداز py است که می‌توان از آن برای راه‌اندازی برنامه‌های پایتون به‌صورت مستقل از نسخه استفاده کرد.

این راه‌انداز به‌طور ضمنی هنگام دوبار کلیک کردن روی پرونده‌های *.py فراخوانی می‌شود. اگر تنها یک نسخه از پایتون روی سیستم نصب باشد، از همان نسخه برای اجرای پرونده استفاده می‌شود. اگر چند نسخه نصب باشند، به‌طور پیش‌فرض از جدیدترین نسخه استفاده می‌شود، اما می‌توان این پیش‌فرض را با گنجاندن یک «سطر shebang» به سبک یونیکس در اسکریپت پایتون لغو کرد.

همچنین می‌توان از راه‌انداز به‌طور صریح از طریق خط فرمان به‌عنوان برنامه‌ی py استفاده کرد. اجرای py همان قواعد انتخاب نسخه در راه‌اندازی ضمنی اسکریپت‌ها را دنبال می‌کند، اما می‌توان با پاس دادن آرگومان‌های مناسب، نسخه‌ی مشخص‌تری را انتخاب کرد (مانند -3 برای درخواست پایتون ۳ هنگامی که پایتون ۲ نیز نصب است، یا -2.6 برای درخواست صریح نسخه‌ی قدیمی‌تری از پایتون هنگامی که نسخه‌ی جدید‌تری نصب است).

علاوه بر راه‌انداز، نصاب ویندوز اکنون گزینه‌ای برای افزودن پایتون تازه نصب‌شده به PATH سیستم در بر می‌گیرد. (مشارکت از طرف Brian Curtin در bpo-3561.)

همچنین ببینید

PEP 397 - راه‌انداز پایتون برای ویندوز: PEP نوشته‌شده توسط Mark Hammond و Martin v. Löwis؛ پیاده‌سازی توسط Vinay Sajip.

مستندات راه‌انداز: مدیر نصب پایتون

تغییر PATH توسط نصب‌کننده: مدیر نصب پایتون

PEP 3151: بازسازی سلسله‌مراتب استثناهای سیستم‌عامل و ورودی/خروجی¶

سلسله‌مراتب استثناهایی که توسط خطاهای سیستم‌عامل ایجاد می‌شوند، اکنون هم ساده‌تر و هم دانه‌ریزتر شده است.

دیگر لازم نیست نگران انتخاب نوع استثنای مناسب بین OSError، IOError، EnvironmentError، WindowsError، mmap.error، socket.error یا select.error باشید. اکنون همه‌ی این نوع‌های استثنا تنها یکی هستند: OSError. نام‌های دیگر به دلایل سازگاری به‌عنوان نام‌های مستعار نگه داشته شده‌اند.

همچنین، اکنون گرفتن یک وضعیت خطای مشخص آسان‌تر شده است. به‌جای اینکه ویژگی errno (یا args[0]) را از نظر ثابت مشخصی از ماژول errno بررسی کنید، می‌توانید زیرکلاس مناسب OSError را بگیرید. زیرکلاس‌های موجود عبارت‌اند از:

و خودِ ConnectionError نیز زیرکلاس‌های ریزدانه‌تری دارد:

به لطف استثناهای جدید، اکنون می‌توان از کاربردهای رایج errno اجتناب کرد. برای مثال، کد زیر که برای پایتون 3.2 نوشته‌شده است:

from errno import ENOENT, EACCES, EPERM

try:
    with open("document.txt") as f:
        content = f.read()
except IOError as err:
    if err.errno == ENOENT:
        print("document.txt file is missing")
    elif err.errno in (EACCES, EPERM):
        print("You are not allowed to read document.txt")
    else:
        raise

اکنون می‌توان بدون ایمپورت errno و بدون بررسی دستی ویژگی‌های استثنا نوشت:

try:
    with open("document.txt") as f:
        content = f.read()
except FileNotFoundError:
    print("document.txt file is missing")
except PermissionError:
    print("You are not allowed to read document.txt")

همچنین ببینید

PEP 3151 - بازطراحی سلسله‌مراتب استثناهای سیستم‌عامل و ورودی/خروجی: PEP (پیشنهاد بهبود پایتون) نوشته و پیاده‌سازی‌شده توسط آنتوان پی‌ترو

PEP 380: سینتکس واگذاری به زیرتولیدگر¶

PEP 380 عبارت yield from را اضافه می‌کند که به یک generator اجازه می‌دهد بخشی از عملیات خود را به تولیدگر دیگری واگذار کند. این امر اجازه می‌دهد بخشی از کد که حاوی yield است، استخراج و در تولیدگر دیگری قرار گیرد. علاوه بر این، تولیدگر فرعی می‌تواند به همراه یک مقدار بازگردد و این مقدار در اختیار تولیدگر واگذارکننده قرار می‌گیرد.

هرچند عبارت yield from عمدتاً برای استفاده در واگذاری به یک تولیدگر فرعی طراحی شده است، اما در واقع امکان واگذاری به پیمایش‌گرهای فرعی دلخواه را فراهم می‌کند.

برای پیمایش‌گرهای ساده، yield from iterable در اصل فقط شکل کوتاه‌شده‌ی for item in iterable: yield item است:

>>> def g(x):
...     yield from range(x, 0, -1)
...     yield from range(x)
...
>>> list(g(5))
[5, 4, 3, 2, 1, 0, 1, 2, 3, 4]

اما برخلاف یک حلقه‌ی معمولی، yield from به زیرتولیدگرها اجازه می‌دهد مقادیر ارسال‌شده و پرتاب‌شده را مستقیماً از محدوده‌ی فراخوانی دریافت کنند و یک مقدار نهایی را به تولیدگر بیرونی بازگردانند:

>>> def accumulate():
...     tally = 0
...     while 1:
...         next = yield
...         if next is None:
...             return tally
...         tally += next
...
>>> def gather_tallies(tallies):
...     while 1:
...         tally = yield from accumulate()
...         tallies.append(tally)
...
>>> tallies = []
>>> acc = gather_tallies(tallies)
>>> next(acc)  # Ensure the accumulator is ready to accept values
>>> for i in range(4):
...     acc.send(i)
...
>>> acc.send(None)  # Finish the first tally
>>> for i in range(5):
...     acc.send(i)
...
>>> acc.send(None)  # Finish the second tally
>>> tallies
[6, 10]

اصل اصلی هدایت‌کننده‌ی این تغییر این است که حتی تولیدگرهایی که برای استفاده با متدهای send و throw طراحی‌شده‌اند، به همان سادگی که یک تابع بزرگ منفرد می‌تواند به چندین زیرتابع تقسیم شود، به چندین زیرتولیدگر تقسیم شوند.

همچنین ببینید

PEP 380 - سینتکس واگذاری به زیرتولیدگر (subgenerator): PEP توسط Greg Ewing نوشته شد؛ پیاده‌سازی توسط Greg Ewing انجام شد و Renaud Blanch، Ryan Kelly و Nick Coghlan آن را در نسخه‌ی 3.3 ادغام کردند؛ مستندسازی توسط Zbigniew Jędrzejewski-Szmek و Nick Coghlan انجام شد

PEP 409: سرکوب زمینه‌ی استثنا¶

PEP 409 سینتکس جدیدی معرفی می‌کند که به شما اجازه می‌دهد نمایش زمینه‌ی استثنای زنجیره‌شده را غیرفعال کنید. این امر امکان داشتن پیام‌های خطای تمیزتر را در برنامه‌هایی که بین انواع استثنا تبدیل انجام می‌دهند فراهم می‌کند:

>>> class D:
...     def __init__(self, extra):
...         self._extra_attributes = extra
...     def __getattr__(self, attr):
...         try:
...             return self._extra_attributes[attr]
...         except KeyError:
...             raise AttributeError(attr) from None
...
>>> D({}).x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in __getattr__
AttributeError: x

بدون پسوند from None برای سرکوب علت، استثنای اصلی به‌طور پیش‌فرض نمایش داده می‌شد:

>>> class C:
...     def __init__(self, extra):
...         self._extra_attributes = extra
...     def __getattr__(self, attr):
...         try:
...             return self._extra_attributes[attr]
...         except KeyError:
...             raise AttributeError(attr)
...
>>> C({}).x
Traceback (most recent call last):
  File "<stdin>", line 6, in __getattr__
KeyError: 'x'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in __getattr__
AttributeError: x

هیچ قابلیت اشکال‌زدایی از دست نمی‌رود، زیرا زمینه‌ی استثنای اصلی در صورت نیاز در دسترس باقی می‌ماند (مثلاً اگر کتابخانه‌ای میانی جزئیات ارزشمند زیرین را به‌اشتباه سرکوب کرده باشد):

>>> try:
...     D({}).x
... except AttributeError as exc:
...     print(repr(exc.__context__))
...
KeyError('x',)

همچنین ببینید

PEP 409 - سرکوب زمینه‌ی استثنا: PEP نوشته‌شده توسط Ethan Furman؛ پیاده‌سازی‌شده توسط Ethan Furman و Nick Coghlan.

PEP 414: مقادیر لفظی یونیکد صریح¶

برای آسان‌سازی گذار از پایتون 2 برای برنامه‌های پایتونی آگاه از یونیکد که استفاده‌ی فراوانی از مقادیر لفظی یونیکد می‌کنند، پایتون 3.3 بار دیگر از پیشوند «u» برای مقادیر لفظی رشته پشتیبانی می‌کند. این پیشوند در پایتون 3 هیچ اهمیت معنایی ندارد و صرفاً برای کاهش تعداد تغییرات کاملاً مکانیکی در مهاجرت به پایتون 3 ارائه شده است تا تمرکز توسعه‌دهندگان بر تغییرات معنایی مهم‌تر (مانند جداسازی پیش‌فرض سخت‌گیرانه‌تر داده‌های دودویی و متنی) آسان‌تر شود.

همچنین ببینید

PEP 414 - مقادیر لفظی یونیکد صریح: PEP (پیشنهاد بهبود پایتون) نوشته‌شده توسط آرمین روناکر.

PEP 3155: نام کامل برای کلاس‌ها و توابع¶

توابع و اشیای کلاس ویژگی جدید __qualname__ دارند که «مسیر» از سطح بالای ماژول تا تعریف آن‌ها را نشان می‌دهد. برای توابع و کلاس‌های سراسری، این همان __name__ است. برای سایر توابع و کلاس‌ها، این ویژگی اطلاعات بهتری درباره‌ی جایی که در واقع در آن تعریف شده‌اند و نحوه‌ی دسترسی‌پذیری آن‌ها از محدوده سراسری ارائه می‌دهد.

مثال با متدهای (غیرمقید):

>>> class C:
...     def meth(self):
...         pass
...
>>> C.meth.__name__
'meth'
>>> C.meth.__qualname__
'C.meth'

مثال با کلاس‌های تودرتو:

>>> class C:
...     class D:
...         def meth(self):
...             pass
...
>>> C.D.__name__
'D'
>>> C.D.__qualname__
'C.D'
>>> C.D.meth.__name__
'meth'
>>> C.D.meth.__qualname__
'C.D.meth'

مثالی با توابع تودرتو:

>>> def outer():
...     def inner():
...         pass
...     return inner
...
>>> outer().__name__
'inner'
>>> outer().__qualname__
'outer.<locals>.inner'

نمایش رشته‌ای آن اشیاء نیز برای گنجاندن اطلاعات جدید و دقیق‌تر تغییر کرده است:

>>> str(C.D)
"<class '__main__.C.D'>"
>>> str(C.D.meth)
'<function C.D.meth at 0x7f46b9fe31e0>'

همچنین ببینید

PEP 3155 - نام کامل برای کلاس‌ها و توابع: PEP نوشته و پیاده‌سازی‌شده توسط آنتوان پی‌ترو.

PEP 412: دیکشنری با اشتراک‌گذاری کلید (Key-Sharing Dictionary)¶

دیکشنری‌هایی که برای ذخیره‌سازی ویژگی‌های اشیاء استفاده می‌شوند، اکنون می‌توانند بخشی از ذخیره‌سازی داخلی خود را با یکدیگر به اشتراک بگذارند (یعنی بخشی که کلیدها و هش‌های متناظرشان را ذخیره می‌کند). این امر مصرف حافظه‌ی برنامه‌هایی را که نمونه‌های زیادی از نوع‌های غیرتوکار ایجاد می‌کنند کاهش می‌دهد.

همچنین ببینید

PEP 412 - دیکشنری با اشتراک کلیدها: PEP توسط مارک شانون نوشته و پیاده‌سازی شده است.

PEP 362: شیء امضای تابع¶

تابع جدید inspect.signature() درون‌نگری فراخوانی‌پذیرهای پایتون را آسان و سرراست می‌سازد. از طیف گسترده‌ای از فراخوانی‌پذیرها پشتیبانی می‌شود: توابع پایتون، با دکوراتور یا بدون آن، کلاس‌ها و اشیاء functools.partial(). کلاس‌های جدید inspect.Signature، inspect.Parameter و inspect.BoundArguments اطلاعاتی درباره‌ی امضاهای فراخوانی نگه می‌دارند، مانند حاشیه‌نویسی‌ها، مقادیر پیش‌فرض، انواع پارامترها و آرگومان‌های مقیدشده؛ این امر نوشتن دکوراتورها و هر کدی که امضاهای فراخوانی یا آرگومان‌ها را اعتبارسنجی یا اصلاح می‌کند را به‌طور قابل توجهی ساده‌تر می‌سازد.

همچنین ببینید

PEP 362: - شیء امضای تابع: PEP (پیشنهاد بهبود پایتون) نوشته‌شده توسط برت کانون، یوری سلیوانوف، لری هستینگز و جی‌وون سو؛ پیاده‌سازی‌شده توسط یوری سلیوانوف.

PEP 421: افزودن sys.implementation¶

ویژگی جدیدی روی ماژول sys جزئیات مربوط به پیاده‌سازی مفسر در حال اجرا را آشکار می‌کند. مجموعه اولیه ویژگی‌های sys.implementation شامل name، version، hexversion و cache_tag است.

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

یک نمونه از بهبود قابلیت حمل کتابخانه استاندارد، cache_tag است. از پایتون 3.3 به بعد، sys.implementation.cache_tag توسط importlib برای پشتیبانی از انطباق با PEP 3147 استفاده می‌شود. هر پیاده‌سازی پایتون که از importlib برای سیستم ایمپورت توکار خود استفاده می‌کند، می‌تواند از cache_tag برای کنترل رفتار نهان‌گذاری ماژول‌ها استفاده کند.

SimpleNamespace¶

پیاده‌سازی sys.implementation همچنین نوع جدیدی را به پایتون معرفی می‌کند: types.SimpleNamespace. در مقابل یک فضای نام مبتنی بر نگاشت مانند dict، SimpleNamespace مانند object مبتنی بر ویژگی است. اما برخلاف object، نمونه‌های SimpleNamespace نوشتنی هستند. این بدان معناست که شما می‌توانید از طریق دسترسی عادی به ویژگی، به فضای نام اضافه کنید، از آن حذف کنید و آن را تغییر دهید.

همچنین ببینید

PEP 421 - افزودن sys.implementation: PEP نوشته و پیاده‌سازی‌شده توسط اریک اسنو.

استفاده از importlib به‌عنوان پیاده‌سازی ایمپورت¶

bpo-2377 - جایگزینی __import__ با importlib.__import__ bpo-13959 - پیاده‌سازی مجدد بخش‌هایی از imp در پایتون خالص bpo-14605 - صریح کردن سازوکار ایمپورت bpo-14646 - الزام بارگذارها به تنظیم __loader__ و __package__

تابع __import__() اکنون بر پایه‌ی importlib.__import__() کار می‌کند. این کار به تکمیل «مرحله ۲» از PEP 302 منجر می‌شود. این تغییر مزایای متعددی دارد. نخست، این امکان را فراهم کرده است که بخش بیشتری از سازوکاری که ایمپورت را ممکن می‌کند، به‌جای اینکه ضمنی و پنهان در کد C باقی بماند، در دسترس قرار گیرد. همچنین یک پیاده‌سازی واحد در اختیار تمام ماشین‌های مجازی پایتون که پایتون 3.3 را پشتیبانی می‌کنند قرار می‌دهد و کمک می‌کند تا هرگونه انحراف خاص ماشین مجازی در معناشناسی ایمپورت به پایان برسد. و در نهایت، نگهداری ایمپورت را آسان‌تر می‌کند و امکان رشد در آینده را فراهم می‌آورد.

برای کاربر عادی، نباید هیچ تغییر قابل‌مشاهده‌ای در معناشناسی وجود داشته باشد. برای کسانی که کدشان در حال حاضر ایمپورت را دستکاری می‌کند یا ایمپورت را به‌صورت برنامه‌ای فراخوانی می‌کند، تغییرات کدی که ممکن است لازم باشند در بخش Porting Python code این سند شرح داده شده‌اند.

API‌های جدید¶

یکی از مزیت‌های بزرگ این کار، آشکار شدن آن چیزی است که در کار کردن دستور import دخیل است. این بدان معناست که ایمپورت‌کننده‌های گوناگونی که زمانی ضمنی بودند، اکنون به‌طور کامل به‌عنوان بخشی از بسته‌ی importlib آشکار شده‌اند.

کلاس‌های پایه انتزاعی تعریف‌شده در importlib.abc گسترش یافته‌اند تا با معرفی importlib.abc.MetaPathFinder و importlib.abc.PathEntryFinder، به‌ترتیب بین یابنده‌های فرامسیر و یابنده‌های ورودی مسیر تمایز درستی قائل شوند. کلاس پایه انتزاعی قدیمی importlib.abc.Finder اکنون تنها برای سازگاری با نسخه‌های پیشین ارائه می‌شود و هیچ الزامی برای متدها اعمال نمی‌کند.

از منظر یابنده‌ها، importlib.machinery.FileFinder سازوکار مورد استفاده برای جستجوی پرونده‌های سورس و بایت‌کد یک ماژول را در دسترس قرار می‌دهد. پیش‌تر این کلاس عضوی ضمنی از sys.path_hooks بود.

برای بارگذارها، کلاس پایه انتزاعی جدید importlib.abc.FileLoader کمک می‌کند تا یک بارگذار بنویسید که از سامانه فایل‌بندی به‌عنوان سازوکار ذخیره‌سازی کد یک ماژول استفاده می‌کند. بارگذار پرونده‌های منبع (importlib.machinery.SourceFileLoader)، پرونده‌های بایت‌کد بدون منبع (importlib.machinery.SourcelessFileLoader) و ماژول‌های توسعه‌ای (importlib.machinery.ExtensionFileLoader) اکنون برای استفاده مستقیم در دسترس هستند.

ImportError اکنون دارای ویژگی‌های name و path است که هنگامی که داده‌های مربوطی برای ارائه وجود داشته باشد، تنظیم می‌شوند. پیام ایمپورت‌های ناموفق نیز اکنون به‌جای فقط بخش انتهایی نام ماژول، نام کامل ماژول را ارائه می‌دهد.

تابع importlib.invalidate_caches() اکنون متد هم‌نام را روی همه‌ی یابنده‌های نهانگاه‌شده در sys.path_importer_cache فراخوانی می‌کند تا در صورت لزوم به پاک‌سازی هر وضعیت ذخیره‌شده کمک کند.

تغییرات قابل مشاهده¶

برای تغییرات احتمالی مورد نیاز در کد، به بخش Porting Python code مراجعه کنید.

فراتر از گستره‌ی آنچه importlib اکنون در دسترس قرار می‌دهد، تغییرات قابل مشاهده‌ی دیگری نیز در ایمپورت وجود دارد. بزرگ‌ترین آن‌ها این است که sys.meta_path و sys.path_hooks اکنون تمام یابنده‌های فرامسیر و قلاب‌های ورودی مسیر مورد استفاده در ایمپورت را نگه‌داری می‌کنند. پیش‌تر یابنده‌ها ضمنی و پنهان درون کد C ایمپورت بودند و به‌طور مستقیم در دسترس قرار نمی‌گرفتند. این بدان معناست که اکنون می‌توانید به‌سادگی یابنده‌های مختلف را حذف کنید یا ترتیب آن‌ها را مطابق نیاز خود تغییر دهید.

تغییر دیگر این است که همه‌ی ماژول‌ها ویژگی __loader__ را دارند که بارگذار استفاده‌شده برای ایجاد ماژول را ذخیره می‌کند. PEP 302 به‌روزرسانی شده است تا پیاده‌سازی این ویژگی را برای بارگذارها الزامی کند؛ بنابراین در آینده، وقتی بارگذارهای شخص ثالث به‌روزرسانی شدند، افراد خواهند توانست بر وجود این ویژگی تکیه کنند. اما تا آن زمان، ایمپورت ماژول را پس از بارگذاری تنظیم می‌کند.

اکنون همچنین از بارگذارها انتظار می‌رود که ویژگی __package__ را مطابق PEP 366 تنظیم کنند. یک‌بار دیگر، خود ایمپورت این کار را از قبل روی همه بارگذارهای importlib انجام می‌دهد و خود ایمپورت این ویژگی را پس از بارگذاری تنظیم می‌کند.

اکنون وقتی هیچ یابنده‌ای روی sys.path_hooks یافت نشود، None در sys.path_importer_cache درج می‌شود. از آنجا که imp.NullImporter به‌طور مستقیم روی sys.path_hooks قرار نمی‌گیرد، دیگر نمی‌توان به آن اتکا کرد که همیشه به‌عنوان مقداری که نشان می‌دهد هیچ یابنده‌ای یافت نشده است، در دسترس باشد.

همه‌ی تغییرات دیگر به تغییرات معنایی مربوط‌اند که هنگام به‌روزرسانی کد برای پایتون 3.3 باید در نظر گرفته شوند، و بنابراین باید درباره‌ی آن‌ها در بخش Porting Python code این سند بخوانید.

(پیاده‌سازی توسط Brett Cannon)

دیگر تغییرات زبان¶

برخی از تغییرات کوچک‌تر اعمال‌شده در هسته زبان پایتون عبارت‌اند از:

پشتیبانی از نام‌های مستعار یونیکد و دنباله‌های نام‌دار افزوده شد. هر دو unicodedata.lookup() و '\N{...}' اکنون نام‌های مستعار را حل می‌کنند، و unicodedata.lookup() دنباله‌های نام‌دار را نیز حل می‌کند.

(مشارکت Ezio Melotti در bpo-12753.)
پایگاه داده یونیکد به نسخه 6.1.0 از UCD به‌روزرسانی شد
مقایسه‌های برابری روی اشیای range() اکنون نتیجه‌ای را برمی‌گردانند که برابری دنباله‌های زیربناییِ تولیدشده توسط آن اشیای range را منعکس می‌کند. (bpo-13201)
متدهای count()، find()، rfind()، index() و rindex() در اشیاء bytes و bytearray اکنون یک عدد صحیح بین ۰ و ۲۵۵ را به‌عنوان آرگومان اول خود می‌پذیرند.

(مشارکت از سوی پتری لهتینن در bpo-12170.)
متدهای rjust()، ljust() و center() در bytes و bytearray اکنون یک bytearray را به‌عنوان آرگومان fill می‌پذیرند. (مشارکت‌شده توسط Petri Lehtinen در bpo-12380.)
متدهای جدیدی به list و bytearray افزوده شده‌اند: copy() و clear() (bpo-10516). در نتیجه، MutableSequence اکنون یک متد clear() را نیز تعریف می‌کند (bpo-11388).
مقادیر لفظی بایت خام را اکنون می‌توان به صورت rb"..." و همچنین br"..." نوشت.

(مشارکت آنتوان پی‌ترو در bpo-13748.)
dict.setdefault() اکنون تنها یک جستجو برای کلید داده‌شده انجام می‌دهد و همین امر آن را هنگام استفاده با نوع‌های توکار اتمی می‌کند.

(مشارکت Filip Gruszczyński در bpo-13521.)
پیام‌های خطایی که هنگام عدم تطابق فراخوانی تابع با امضای تابع تولید می‌شوند، به‌طور چشمگیری بهبود یافته‌اند.

(با مشارکت Benjamin Peterson.)

قفل ایمپورت با دانه‌بندی ریزتر¶

نسخه‌های قبلی سی‌پایتون همیشه به قفل ایمپورت سراسری متکی بودند. این امر منجر به بروز مشکلات غیرمنتظره‌ای می‌شد؛ مانند بن‌بست‌هایی که در آن‌ها ایمپورت کردن یک ماژول به‌عنوان اثر جانبی، باعث اجرای کد در یک نخ متفاوت می‌شد. گاهی اوقات از راه‌حل‌های ناخوشایندی مانند تابع C API به نام PyImport_ImportModuleNoBlock() استفاده می‌شد.

در پایتون 3.3، هنگام ایمپورت کردن یک ماژول، قفلی مخصوص همان ماژول گرفته می‌شود. این کار، ایمپورت یک ماژول معین از چندین نخ را به‌درستی متوالی می‌سازد (و مانع از نمایان شدن ماژول‌های ناقص مقداردهی‌شده می‌شود) و در عین حال مزاحمت‌های پیش‌گفته را از بین می‌برد.

(مشارکت آنتوان پیترو در bpo-9260.)

توابع و انواع توکار¶

open() پارامتر جدیدی به نام opener می‌گیرد: در این صورت، توصیف‌گر پرونده‌ی زیرین برای شیء پرونده از طریق فراخوانی opener با آرگومان‌های (file, flags) به دست می‌آید. با آن می‌توان برای مثال از پرچم‌های سفارشی مانند os.O_CLOEXEC استفاده کرد. حالت 'x' افزوده شد: باز کردن برای ایجاد انحصاری، که اگر پرونده از قبل وجود داشته باشد شکست می‌خورد.
print(): آرگومان کلیدواژه‌ای flush افزوده شد. اگر آرگومان کلیدواژه‌ای flush درست باشد، جریان به‌طور اجباری تخلیه می‌شود.
hash(): تصادفی‌سازی هش به‌طور پیش‌فرض فعال است؛ به object.__hash__() و PYTHONHASHSEED مراجعه کنید.
نوع str متد جدید casefold() را دریافت می‌کند: نسخه‌ای حالت‌تاشده (casefolded) از رشته را برمی‌گرداند؛ رشته‌های حالت‌تاشده (casefolded) را می‌توان برای تطبیق بدون توجه به بزرگی و کوچکی حروف به کار برد. برای مثال، 'ß'.casefold() مقدار 'ss' را برمی‌گرداند.
مستندات دنباله به‌طور اساسی بازنویسی شده است تا تمایز بین دنباله‌های دودویی و متنی را بهتر توضیح دهد و برای هر یک از نوع‌های دنباله توکار، بخش‌های مستندات اختصاصی فراهم کند (bpo-4966).

ماژول‌های جدید¶

faulthandler¶

این ماژول اشکال‌زدایی جدید faulthandler شامل توابعی است که ردگیری‌های پشته پایتون را به‌صورت صریح، هنگام وقوع خطا (فروپاشی‌ای مانند خطای قطعه‌بندی (segmentation fault))، پس از سپری شدن مهلت زمانی، یا هنگام دریافت سیگنال کاربر برون‌ریزی می‌کنند. تابع faulthandler.enable() را فراخوانی کنید تا هندلرهای خطا برای سیگنال‌های SIGSEGV، SIGFPE، SIGABRT، SIGBUS و SIGILL نصب شوند. همچنین می‌توانید آن‌ها را در زمان راه‌اندازی، با تنظیم متغیر محیطی PYTHONFAULTHANDLER یا با استفاده از گزینه‌ی خط فرمان -X faulthandler فعال کنید.

نمونه‌ای از خطای قطعه‌بندی (segmentation fault) در لینوکس:

$ python -q -X faulthandler
>>> import ctypes
>>> ctypes.string_at(0)
Fatal Python error: Segmentation fault

Current thread 0x00007fb899f39700:
  File "/home/python/cpython/Lib/ctypes/__init__.py", line 486 in string_at
  File "<stdin>", line 1 in <module>
Segmentation fault

ipaddress¶

ماژول جدید ipaddress ابزارهایی برای ایجاد و دستکاری اشیاء نماینده‌ی نشانی‌های IPv4 و IPv6، شبکه‌ها و رابط‌ها (یعنی نشانی IP مرتبط با یک زیرشبکه‌ی IP خاص) فراهم می‌کند.

(مشارکت‌شده توسط Google و Peter Moody در PEP 3144.)

lzma¶

ماژول lzma که به‌تازگی اضافه شده است، فشرده‌سازی و واگشایی داده‌ها را با استفاده از الگوریتم LZMA فراهم می‌کند، از جمله پشتیبانی از قالب‌های پرونده .xz و .lzma.

(مشارکت‌شده توسط Nadeem Vawda و Per Øyvind Karlsen در bpo-6715.)

ماژول‌های بهبودیافته¶

abc¶

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

@abc.abstractproperty منسوخ شده است؛ به جای آن از @property همراه با @abc.abstractmethod استفاده کنید.
@abc.abstractclassmethod منسوخ شده است؛ به‌جای آن از @classmethod همراه با @abc.abstractmethod استفاده کنید.
@abc.abstractstaticmethod منسوخ شده است؛ به‌جای آن از @staticmethod همراه با @abc.abstractmethod استفاده کنید.

(با مشارکت Darren Dale در bpo-11610.)

abc.ABCMeta.register() اکنون زیرکلاس ثبت‌شده را برمی‌گرداند، که یعنی اکنون می‌توان از آن به‌عنوان دکوراتور کلاس استفاده کرد (bpo-10868).

array¶

ماژول array از نوع long long با استفاده از کدهای نوع q و Q پشتیبانی می‌کند.

(مشارکت‌شده توسط Oren Tirosh و Hirokazu Yamamoto در bpo-1172711.)

base64¶

رشته‌های یونیکدِ صرفاً اسکی اکنون توسط توابع کدگشایی رابط مدرن base64 پذیرفته می‌شوند. برای مثال، base64.b64decode('YWJj') مقدار b'abc' را برمی‌گرداند. (مشارکت Catalin Iacob در bpo-13641.)

binascii¶

علاوه بر اشیاء دودویی که به‌طور معمول می‌پذیرند، توابع a2b_ اکنون همگی رشته‌های فقط اسکی را نیز به عنوان ورودی می‌پذیرند. (مشارکت Antoine Pitrou در bpo-13637.)

bz2¶

ماژول bz2 از پایه بازنویسی شده است. در این فرایند، چندین قابلیت جدید افزوده شده است:

تابع جدید bz2.open(): باز کردن یک پرونده فشرده‌شده با bzip2 در حالت دودویی یا متنی.
bz2.BZ2File اکنون می‌تواند به‌واسطه‌ی آرگومان fileobj سازنده‌اش، از هر شیء شبه‌پرونده‌ای بخواند و در آن بنویسد.

(مشارکت‌شده توسط Nadeem Vawda در bpo-5863.)
bz2.BZ2File و bz2.decompress() اکنون می‌توانند ورودی‌های چندجریانی را واگشایی کنند (مانند مواردی که با ابزار pbzip2 تولید می‌شوند). bz2.BZ2File اکنون همچنین می‌تواند با استفاده از حالت 'a' (افزودن) برای ایجاد این نوع پرونده به کار رود.

(با مشارکت Nir Aides در bpo-1625.)
bz2.BZ2File اکنون تمام API io.BufferedIOBase را پیاده‌سازی می‌کند، به‌جز متدهای detach() و truncate().

codecs¶

کدک mbcs بازنویسی شده است تا هندلرهای خطای replace و ignore را در تمامی نسخه‌های ویندوز به‌درستی مدیریت کند. کدک mbcs اکنون از تمامی هندلرهای خطا پشتیبانی می‌کند، نه فقط از replace برای کدگذاری و ignore برای کدگشایی.

یک کدک جدید مخصوص ویندوز افزوده‌شده است: cp65001 (bpo-13216). این کدک، صفحه کد 65001 ویندوز است (UTF-8 ویندوز، CP_UTF8). برای مثال، اگر صفحه کد خروجی کنسول به cp65001 تنظیم‌شده باشد (مثلاً با استفاده از دستور chcp 65001)، sys.stdout از آن استفاده می‌کند.

کدگشاهای چندبایتی CJK اکنون سریع‌تر همگام‌سازی مجدد می‌کنند. آن‌ها فقط نخستین بایت یک دنباله بایتی نامعتبر را نادیده می‌گیرند. برای مثال، b'\xff\n'.decode('gb2312', 'replace') اکنون پس از نویسه جایگزین، یک \n برمی‌گرداند.

(bpo-12016)

کدگذارهای افزایشی کدک‌های CJK در هر فراخوانی متد encode() خود، دیگر بازنشانی نمی‌شوند. برای مثال:

>>> import codecs
>>> encoder = codecs.getincrementalencoder('hz')('strict')
>>> b''.join(encoder.encode(x) for x in '\u52ff\u65bd\u65bc\u4eba\u3002 Bye.'
b'~{NpJ)l6HK!#~} Bye.'

این مثال در نسخه‌های قدیمی‌تر پایتون b'~{Np~}~{J)~}~{l6~}~{HK~}~{!#~} Bye.' را به دست می‌دهد.

(bpo-12100)

کدک unicode_internal منسوخ شده است.

collections¶

افزودن کلاس جدید ChainMap برای امکان برخورد با تعدادی نگاشت به‌عنوان یک واحد واحد. (نوشته‌شده توسط Raymond Hettinger برای bpo-11089، عمومی‌شده در bpo-11297.)

کلاس‌های پایه انتزاعی به ماژول جدید collections.abc منتقل شده‌اند تا تمایز بین کلاس‌های انتزاعی و عینی مجموعه‌ها بهتر مشخص شود. نام‌های مستعار کلاس‌های پایه انتزاعی برای حفظ ایمپورت‌های موجود، همچنان در ماژول collections وجود دارند. (bpo-11085)

کلاس Counter اکنون از عملگرهای یک‌عملوندی + و - و همچنین از عملگرهای درجا +=، -=, |= و &= پشتیبانی می‌کند. (مشارکت‌شده توسط Raymond Hettinger در bpo-13121.)

contextlib¶

ExitStack اکنون پایه‌ای محکم برای دستکاری برنامه‌ای مدیرهای زمینه و قابلیت‌های پاک‌سازی مشابه فراهم می‌کند. برخلاف API قبلی contextlib.nested (که منسوخ و حذف شد)، API جدید به‌گونه‌ای طراحی شده است که صرف‌نظر از اینکه مدیرهای زمینه منابع خود را در متد __init__ خود به دست می‌آورند (برای مثال، اشیای پرونده) یا در متد __enter__ خود (برای مثال، اشیای همگام‌سازی از ماژول threading)، به‌درستی کار کند.

(bpo-13585)

crypt¶

افزودن نمک و قالب کریپت ماژولار (modular crypt format) (روش هش) و تابع mksalt() به ماژول crypt.

(bpo-10924)

curses¶

اگر ماژول curses به کتابخانه‌ی ncursesw پیوند داده شده باشد، هنگام ارسال رشته‌ها یا نویسه‌های یونیکد از توابع یونیکد استفاده کنید (مثلاً waddwstr()) و در غیر این صورت از توابع بایتی (مثلاً waddstr()).
برای کدگذاری رشته‌های یونیکد، به‌جای utf-8 از کدگذاری locale استفاده کنید.
curses.window دارای یک ویژگی جدید curses.window.encoding است.
کلاس curses.window یک متد جدید get_wch() برای دریافت یک نویسه پهن دارد
ماژول curses دارای تابع جدید unget_wch() است که یک نویسه پهن را می‌فشارد تا فراخوانی بعدی get_wch() آن را بازگرداند

(مشارکت‌شده توسط اینیگو سرنا در bpo-6755.)

datetime¶

مقایسه‌های برابری میان نمونه‌های ساده و آگاه datetime اکنون به‌جای برافکندن TypeError، مقدار False را برمی‌گردانند (bpo-15006).
متد جدید datetime.datetime.timestamp(): مهر زمانی POSIX متناظر با نمونه‌ی datetime را برمی‌گرداند.
متد datetime.datetime.strftime() از قالب‌بندی سال‌های قدیمی‌تر از ۱۰۰۰ پشتیبانی می‌کند.
متد datetime.datetime.astimezone() اکنون می‌تواند بدون آرگومان فراخوانی شود تا نمونه‌ی datetime را به منطقه زمانی سیستم تبدیل کند.

decimal¶

bpo-7652 - یکپارچه‌سازی محاسبات اعشاری سریع و بومی.: ماژول C و libmpdec نوشته‌شده توسط Stefan Krah.

نسخه جدید C ماژول decimal، کتابخانه پرسرعت libmpdec را برای محاسبات ممیز شناور ده‌دهی با دقت دلخواه و گرد شدن به‌درستی یکپارچه می‌کند. libmpdec مطابق با مشخصات محاسبات ده‌دهی عمومی IBM (General Decimal Arithmetic Specification) است.

افزایش عملکرد از ۱۰ برابر برای برنامه‌های پایگاه داده تا ۱۰۰ برابر برای برنامه‌های با محاسبات عددی سنگین متغیر است. این اعداد، دستاوردهای مورد انتظار برای دقت‌های استاندارد استفاده‌شده در محاسبات ممیز شناور دهدهی هستند. از آنجا که دقت توسط کاربر قابل‌تنظیم است، ممکن است مقادیر دقیق متفاوت باشند. برای مثال، در محاسبات اعداد صحیح بزرگ (bignum) تفاوت‌ها می‌توانند به‌طور چشمگیری بیشتر باشند.

جدول زیر صرفاً جهت نمایش است. بنچمارک‌ها در https://www.bytereef.org/mpdecimal/quickstart.html در دسترس هستند.

decimal.py

_decimal

افزایش سرعت

پی

42.02s

0.345s

120x

telco

172.19s

5.68s

30x

psycopg

3.57s

0.29s

12x

قابلیت‌ها¶

سیگنال FloatOperation به‌صورت اختیاری، معناشناسی سخت‌گیرانه‌تری را برای ترکیب اعداد ممیز شناور و Decimal فعال می‌کند.
اگر پایتون بدون نخ‌ها کامپایل شود، نسخه‌ی C به‌طور خودکار سازوکار پرهزینه‌ی زمینه‌ی نخ‌محلی را غیرفعال می‌کند. در این حالت، متغیر HAVE_THREADS برابر False قرار می‌گیرد.

تغییرات API¶

ماژول C بسته به معماری ماشین، کران‌های زمینه‌ی زیر را دارد:

۳۲-بیتی

۶۴-بیتی

MAX_PREC

425000000

999999999999999999

MAX_EMAX

425000000

999999999999999999

MIN_EMIN

-425000000

-999999999999999999
در قالب‌های زمینه (DefaultContext، BasicContext و ExtendedContext) قدر مطلق Emax و Emin به 999999 تغییر کرده است.
سازنده‌ی Decimal در decimal.py محدودیت‌های زمینه را رعایت نمی‌کند و مقادیر با توان یا دقت دلخواه را دقیقاً تبدیل می‌کند. از آنجا که نسخه‌ی C محدودیت‌های داخلی دارد، از طرح‌واره‌ی زیر استفاده می‌شود: در صورت امکان، مقادیر دقیقاً تبدیل می‌شوند؛ در غیر این صورت، InvalidOperation ایجاد می‌شود و نتیجه NaN است. در حالت دوم همیشه می‌توان از create_decimal() استفاده کرد تا مقداری گردشده یا نا‌دقیق به دست آید.
تابع توان در decimal.py همیشه به‌درستی گرد می‌شود (correctly rounded). در نسخه‌ی C، این تابع بر اساس توابع به‌درستی گردشده‌ی exp() و ln() تعریف شده است، اما نتیجه‌ی نهایی فقط «تقریباً همیشه به‌درستی گردشده» است.
در نسخه‌ی C، دیکشنری زمینه‌ای که سیگنال‌ها را در بر دارد، یک MutableMapping است. به دلیل سرعت، flags و traps همیشه به همان MutableMapping ارجاع می‌کنند که زمینه با آن مقداردهی اولیه شده است. اگر دیکشنری سیگنال جدیدی انتساب داده شود، flags و traps با مقادیر جدید به‌روزرسانی می‌شوند، اما به دیکشنری سمت راست (RHS) ارجاع نمی‌کنند.
پیکل‌کردن یک Context خروجی متفاوتی تولید می‌کند تا یک قالب تبادل مشترک برای نسخه‌های پایتون و C وجود داشته باشد.
ترتیب آرگومان‌ها در سازنده‌ی Context تغییر کرده است تا با ترتیبی که repr() نمایش می‌دهد مطابقت داشته باشد.
پارامتر watchexp در متد quantize() منسوخ شده است.

email¶

چارچوب سیاست¶

بسته‌ی ایمیل اکنون دارای یک چارچوب policy است. Policy شیءی است با چندین متد و ویژگی که نحوه‌ی رفتار بسته‌ی ایمیل را کنترل می‌کنند. سیاست اصلی برای پایتون 3.3، سیاست Compat32 است که سازگاری پس‌رونده با بسته‌ی ایمیل در پایتون 3.2 را فراهم می‌کند. می‌توان یک policy را هنگام تجزیه‌ی یک پیام ایمیل توسط parser، یا هنگام ایجاد یک شیء Message، یا هنگام سریال‌سازی یک ایمیل با استفاده از generator مشخص کرد. مگر آنکه بازنویسی شود، سیاستی که به یک parser پاس داده می‌شود، توسط تمام شیء Message و زیراشیایی که توسط همان parser ایجاد شده‌اند به ارث برده می‌شود. به‌طور پیش‌فرض، یک generator از سیاست شیء Message که در حال سریال‌سازی آن است استفاده می‌کند. سیاست پیش‌فرض compat32 است.

مجموعه‌ی حداقلی کنترل‌هایی که همه‌ی اشیاء policy پیاده‌سازی می‌کنند، عبارت‌اند از:

max_line_length	حداکثر طولی که سطرهای منفرد می‌توانند هنگام سریال‌سازی یک `Message` داشته باشند، بدون احتساب نویسه(های) جداکننده‌ی سطر (linesep). مقدار پیش‌فرض ۷۸ است.
linesep	نویسه‌ای که هنگام سریال‌سازی یک `Message` برای جدا کردن سطرهای جداگانه استفاده می‌شود. مقدار پیش‌فرض آن `\n` است.
cte_type	`7bit` یا `8bit`. `8bit` فقط برای یک `generator` `Bytes` کاربرد دارد و به این معناست که می‌توان از نویسه‌های غیراسکی در جایی که پروتکل اجازه می‌دهد (یا در جایی که در ورودی اصلی وجود دارند) استفاده کرد.
raise_on_defect	باعث می‌شود یک `parser` هنگام مواجهه با نقص‌ها، به‌جای افزودن آن‌ها به فهرست `defects` شیء `Message`، خطا بردارد.

یک نمونه‌ی جدید سیاست، همراه با تنظیمات جدید، با استفاده از متد clone() اشیای سیاست ایجاد می‌شود. clone هر یک از کنترل‌های بالا را به‌عنوان آرگومان کلیدواژه‌ای می‌پذیرد. هر کنترلی که در فراخوانی مشخص نشده باشد، مقدار پیش‌فرض خود را حفظ می‌کند. بنابراین می‌توانید سیاستی ایجاد کنید که از نویسه‌های \r\n به‌عنوان linesep استفاده می‌کند، به این شکل:

mypolicy = compat32.clone(linesep='\r\n')

از سیاست‌ها می‌توان برای ساده‌تر کردن تولید پیام‌ها در قالب مورد نیاز برنامه‌تان استفاده کرد. به‌جای آنکه ناچار باشید در همه‌ی مکان‌هایی که generator را فراخوانی می‌کنید به یاد داشته باشید که linesep='\r\n' را مشخص کنید، می‌توانید آن را یک‌بار، هنگام تنظیم سیاستی که parser یا Message (هر کدام که برنامه‌تان برای ایجاد اشیاء Message به کار می‌برد) از آن استفاده می‌کند، مشخص کنید. از سوی دیگر، اگر نیاز دارید پیام‌ها را به شکل‌های متعدد تولید کنید، همچنان می‌توانید پارامترها را در فراخوانی generator مناسب مشخص کنید. یا می‌توانید برای موارد مختلف خود، نمونه‌های سیاست سفارشی داشته باشید و آن‌ها را هنگام ایجاد generator ارسال کنید.

سیاست آزمایشی با API جدید سرآیند¶

هرچند چارچوب سیاست به‌خودی‌خود ارزشمند است، انگیزه‌ی اصلی برای معرفی آن، فراهم کردن امکان ایجاد سیاست‌های جدیدی است که ویژگی‌های تازه‌ای را برای بسته‌ی email به شکلی پیاده‌سازی می‌کنند که سازگاری با نسخه‌های قبلی برای کسانی که از سیاست‌های جدید استفاده نمی‌کنند، حفظ شود. از آنجا که سیاست‌های جدید یک API تازه ارائه می‌کنند، آن‌ها را در پایتون 3.3 به‌عنوان یک سیاست آزمایشی منتشر می‌کنیم. در صورتی که توسعه‌دهندگان هسته آن را ضروری بدانند، ممکن است تغییرات ناسازگار با نسخه‌های قبلی (حتی شامل حذف کد) رخ دهد.

سیاست‌های جدید نمونه‌هایی از EmailPolicy هستند و کنترل‌های اضافی زیر را می‌افزایند:

refold_source

کنترل می‌کند که سرآیندهای تجزیه‌شده به‌وسیله‌ی parser، توسط generator دوباره تا شوند یا خیر. این گزینه می‌تواند none، long یا all باشد. مقدار پیش‌فرض long است؛ یعنی سرآیندهای منبعی که سطری طولانی‌تر از max_line_length دارند، دوباره تا می‌شوند. none به این معناست که هیچ سطری دوباره تا نمی‌شود، و all به این معناست که همه‌ی سطرها دوباره تا می‌شوند.

header_factory

فراخوانی‌پذیری که name و value را می‌گیرد و شیء سرآیند سفارشی تولید می‌کند.

header_factory کلید قابلیت‌های جدیدی است که سیاست‌های جدید فراهم می‌کنند. هنگامی که یکی از سیاست‌های جدید استفاده می‌شود، هر سرآیندی که از یک شیء Message بازیابی می‌شود، شیء‌ای است که توسط header_factory تولید شده است، و هرگاه سرآیندی را روی یک Message تنظیم کنید، به شیء‌ای تبدیل می‌شود که توسط header_factory تولید شده است. همه‌ی این اشیاء سرآیند ویژگی name دارند که برابر با نام سرآیند است. سرآیندهای Address و Date ویژگی‌های اضافی دارند که به شما امکان می‌دهند به داده‌های تجزیه‌شده‌ی سرآیند دسترسی داشته باشید. این بدان معناست که اکنون می‌توانید کارهایی مانند این انجام دهید:

>>> m = Message(policy=SMTP)
>>> m['To'] = 'Éric <[email protected]>'
>>> m['to']
'Éric <[email protected]>'
>>> m['to'].addresses
(Address(display_name='Éric', username='foo', domain='example.com'),)
>>> m['to'].addresses[0].username
'foo'
>>> m['to'].addresses[0].display_name
'Éric'
>>> m['Date'] = email.utils.localtime()
>>> m['Date'].datetime
datetime.datetime(2012, 5, 25, 21, 39, 24, 465484, tzinfo=datetime.timezone(datetime.timedelta(-1, 72000), 'EDT'))
>>> m['Date']
'Fri, 25 May 2012 21:44:27 -0400'
>>> print(m)
To: =?utf-8?q?=C3=89ric?= <[email protected]>
Date: Fri, 25 May 2012 21:44:27 -0400

متوجه خواهید شد که نام نمایشی یونیکد هنگام سریال‌سازی پیام به‌طور خودکار به‌صورت utf-8 کدگذاری می‌شود، اما هنگام دسترسی مستقیم به سرآیند، نسخه‌ی یونیکد را دریافت می‌کنید. این امر هرگونه نیاز به سروکار داشتن با توابع decode_header() یا make_header() در email.header را از بین می‌برد.

همچنین می‌توانید نشانی‌ها را از اجزا بسازید:

>>> m['cc'] = [Group('pals', [Address('Bob', 'bob', 'example.com'),
...                           Address('Sally', 'sally', 'example.com')]),
...            Address('Bonzo', addr_spec='[email protected]')]
>>> print(m)
To: =?utf-8?q?=C3=89ric?= <[email protected]>
Date: Fri, 25 May 2012 21:44:27 -0400
cc: pals: Bob <[email protected]>, Sally <[email protected]>;, Bonzo <[email protected]>

کدگشایی به یونیکد به‌طور خودکار انجام می‌شود:

>>> m2 = message_from_string(str(m))
>>> m2['to']
'Éric <[email protected]>'

هنگامی که یک پیام را پارس می‌کنید، می‌توانید از ویژگی‌های addresses و groups شیءهای سرآیند برای دسترسی به گروه‌ها و نشانی‌های فردی استفاده کنید:

>>> m2['cc'].addresses
(Address(display_name='Bob', username='bob', domain='example.com'), Address(display_name='Sally', username='sally', domain='example.com'), Address(display_name='Bonzo', username='bonz', domain='laugh.com'))
>>> m2['cc'].groups
(Group(display_name='pals', addresses=(Address(display_name='Bob', username='bob', domain='example.com'), Address(display_name='Sally', username='sally', domain='example.com')), Group(display_name=None, addresses=(Address(display_name='Bonzo', username='bonz', domain='laugh.com'),))

خلاصه اینکه اگر از یکی از سیاست‌های جدید استفاده کنید، دستکاری سرآیندها همان‌طور کار می‌کند که باید: برنامه‌ی شما با رشته‌های یونیکد کار می‌کند و بسته‌ی email یونیکد را به‌طور شفاف به کدگذاری‌های انتقال محتوا (Content Transfer Encodings) استاندارد RFC کدگذاری و از آن‌ها کدگشایی می‌کند.

سایر تغییرات API¶

BytesHeaderParser جدید، به ماژول parser اضافه شد تا مکمل HeaderParser باشد و API بایت‌ها را تکمیل کند.

توابع کاربردی جدید:

format_datetime(): با دریافت یک datetime، یک رشته قالب‌بندی‌شده برای استفاده در سرآیند ایمیل تولید می‌کند.
parsedate_to_datetime(): با دریافت یک رشته تاریخ از سرآیند ایمیل، آن را به یک datetime آگاه تبدیل می‌کند، یا اگر آفست -0000 باشد، به یک datetime ساده (naive) تبدیل می‌کند.
localtime(): بدون آرگومان، زمان محلی جاری را به‌صورت یک datetime آگاه با استفاده از timezone محلی برمی‌گرداند. با دریافت یک datetime آگاه، آن را به یک datetime آگاه با استفاده از timezone محلی تبدیل می‌کند.

ftplib¶

ftplib.FTP اکنون آرگومان کلیدواژه‌ای source_address را می‌پذیرد تا (host, port) را که باید هنگام ایجاد سوکت خروجی در فراخوانی bind به‌عنوان نشانی مبدأ استفاده شود، مشخص کند. (مشارکت‌شده توسط Giampaolo Rodolà در bpo-8594.)
کلاس FTP_TLS اکنون تابع جدید ccc() را برای بازگرداندن کانال کنترل به حالت متن ساده (plaintext) فراهم می‌کند. این می‌تواند برای بهره‌گیری از فایروال‌هایی که می‌دانند چگونه NAT را با FTP ناامن و بدون باز کردن پورت‌های ثابت مدیریت کنند، مفید باشد. (مشارکت Giampaolo Rodolà در bpo-12139.)
متد ftplib.FTP.mlsd() افزوده شد که قالبی قابل پارس برای فهرست‌بندی پوشه فراهم می‌کند و متدهای ftplib.FTP.nlst() و ftplib.FTP.dir() را منسوخ می‌کند. (مشارکت‌شده توسط Giampaolo Rodolà در bpo-11072.)

functools¶

The @functools.lru_cache decorator now accepts a typed keyword argument (that defaults to False to ensure that it caches values of different types that compare equal in separate cache slots. (Contributed by Raymond Hettinger in bpo-13227.)

gc¶

اکنون می‌توانید با استفاده از فهرست جدید callbacks، کال‌بک‌هایی را که پیش و پس از زباله‌روبی توسط زباله‌روب فراخوانی می‌شوند ثبت کنید.

hmac¶

تابع جدید compare_digest() برای جلوگیری از حملات کانال جانبی بر روی خلاصه‌ها از طریق تحلیل زمان‌بندی افزوده شده است. (با مشارکت Nick Coghlan و Christian Heimes در bpo-15061.)

http¶

http.server.BaseHTTPRequestHandler اکنون سرآیندها را بافر می‌کند و هنگامی که end_headers() فراخوانی می‌شود، همه را یک‌جا می‌نویسد. متد جدید flush_headers() می‌تواند برای مدیریت مستقیم زمان ارسال سرآیندهای انباشته‌شده استفاده شود. (مشارکت‌شده توسط Andrew Schaaf در bpo-3709.)

http.server اکنون خروجی معتبر HTML 4.01 strict تولید می‌کند. (مشارکت‌شده توسط Ezio Melotti در bpo-13295.)

http.client.HTTPResponse اکنون دارای متد readinto() است، که یعنی می‌توان از آن به‌عنوان کلاس io.RawIOBase استفاده کرد. (مشارکت‌شده توسط John Kuhn در bpo-13464.)

html¶

html.parser.HTMLParser اکنون می‌تواند نشانه‌گذاری خراب را بدون ایجاد خطا تجزیه کند، بنابراین آرگومان strict سازنده و استثنای HTMLParseError اکنون منسوخ شده‌اند. توانایی تجزیه نشانه‌گذاری خراب نتیجه تعدادی رفع اشکال است که در آخرین نسخه‌های رفع اشکال پایتون 2.7/3.2 نیز در دسترس هستند. (مشارکت‌شده توسط Ezio Melotti در bpo-15114 و bpo-14538، bpo-13993، bpo-13960، bpo-13358، bpo-1745761، bpo-755670، bpo-13357، bpo-12629، bpo-1200313، bpo-670664، bpo-13273، bpo-12888، bpo-7311.)

یک دیکشنری جدید html5 که ارجاع‌های نویسه نام‌دار HTML5 را به نویسه‌های معادل یونیکد نگاشت می‌کند (برای مثال html5['gt;'] == '>') به ماژول html.entities افزوده شده است. این دیکشنری اکنون توسط HTMLParser نیز استفاده می‌شود. (مشارکت‌شده توسط Ezio Melotti در bpo-11113 و bpo-15156.)

imaplib¶

سازنده‌ی IMAP4_SSL اکنون یک پارامتر SSLContext را برای کنترل پارامترهای کانال امن می‌پذیرد.

(مشارکت‌شده توسط Sijin Joseph در bpo-8808.)

inspect¶

تابع جدید getclosurevars() افزوده شده است. این تابع مقیدسازی فعلی همه‌ی نام‌هایی که از بدنه‌ی تابع به آن‌ها ارجاع شده است و اینکه آن نام‌ها در کجا حل شده‌اند را گزارش می‌کند؛ این امر راستی‌آزمایی درستی وضعیت درونی را هنگام آزمون کدی که به بستارهای وضعیت‌دار وابسته است، آسان‌تر می‌سازد.

(مشارکت‌شده توسط Meador Inge و Nick Coghlan در bpo-13062.)

تابع جدید getgeneratorlocals() افزوده شده است. این تابع مقیدسازی فعلی متغیرهای محلی در فریم پشته‌ی تولیدگر را گزارش می‌کند و تأیید درستی وضعیت داخلی را هنگام آزمون تولیدگرها آسان‌تر می‌سازد.

(با مشارکت Meador Inge در bpo-15153.)

io¶

تابع open() یک حالت جدید 'x' دارد که می‌توان از آن برای ایجاد انحصاری یک پرونده‌ی جدید استفاده کرد و در صورتی که پرونده از قبل وجود داشته باشد، استثنای FileExistsError را raise می‌کند. این حالت بر اساس حالت 'x' در C11 برای fopen() است.

(با مشارکت David Townshend در bpo-12760.)

سازنده‌ی کلاس TextIOWrapper آرگومان اختیاری جدید write_through دارد. اگر write_through برابر True باشد، تضمین می‌شود که فراخوانی‌های write() بافر نشوند: هر داده‌ای که روی شیء TextIOWrapper نوشته شود، بلافاصله به بافر دودویی زیرین آن تحویل داده می‌شود.

itertools¶

accumulate() اکنون یک آرگومان اختیاری func را می‌پذیرد که برای فراهم‌کردن یک تابع دودوییِ ارائه‌شده از سوی کاربر است.

logging¶

تابع basicConfig() اکنون از یک آرگومان اختیاری handlers پشتیبانی می‌کند که یک پیمایش‌پذیر از هندلرها را می‌گیرد تا به گزارش‌گیر ریشه افزوده شوند.

ویژگی سطح کلاس append_nul به SysLogHandler افزوده شده است تا امکان کنترل افزودن بایت NUL (\000) به رکوردهای syslog را فراهم کند؛ زیرا این بایت برای برخی دِیمِن‌ها لازم است، در حالی که برای برخی دیگر به گزارش منتقل می‌شود.

math¶

ماژول math تابع جدیدی به نام log2() دارد که لگاریتم مبنای ۲ x را برمی‌گرداند.

(نوشته‌شده توسط Mark Dickinson در bpo-11888.)

mmap¶

متد read() اکنون با سایر اشیاء شبه‌پرونده سازگارتر است: اگر آرگومان حذف شود یا به‌صورت None تعیین شود، بایت‌ها را از موقعیت فعلی پرونده تا انتهای نگاشت برمی‌گرداند. (مشارکت Petri Lehtinen در bpo-12021.)

multiprocessing¶

تابع جدید multiprocessing.connection.wait() امکان پایش چندین شیء (مانند اتصال‌ها، سوکت‌ها و پایپ‌ها) را با یک مهلت زمانی فراهم می‌کند. (نوشته‌شده توسط ریچارد اودکرک در bpo-12328.)

اشیاء multiprocessing.connection.Connection اکنون می‌توانند از طریق اتصالات multiprocessing منتقل شوند. (مشارکت‌شده توسط Richard Oudkerk در bpo-4892.)

multiprocessing.Process اکنون آرگومان کلیدواژه‌ای daemon را می‌پذیرد تا رفتار پیش‌فرضِ ارث‌بری پرچم daemon از فرایند والد را لغو کند (bpo-6064).

ویژگی جدید multiprocessing.Process.sentinel به یک برنامه اجازه می‌دهد تا با استفاده از سازوکارهای اولیه مناسب سیستم‌عامل (برای مثال، select در سیستم‌های posix) هم‌زمان منتظر چند شیء Process بماند.

متدهای جدید multiprocessing.pool.Pool.starmap() و starmap_async() معادل‌های itertools.starmap() را برای توابع موجود multiprocessing.pool.Pool.map() و map_async() فراهم می‌کنند. (این تغییر توسط Hynek Schlawack در bpo-12708 ارائه شد.)

nntplib¶

کلاس nntplib.NNTP اکنون از پروتکل مدیریت زمینه پشتیبانی می‌کند تا استثناهای socket.error را بدون قید و شرط مهار کند و اتصال NNTP را پس از اتمام کار ببندد:

>>> from nntplib import NNTP
>>> with NNTP('news.gmane.org') as n:
...     n.group('gmane.comp.python.committers')
...
('211 1755 1 1755 gmane.comp.python.committers', 1755, 1, 1755, 'gmane.comp.python.committers')
>>>

(مشارکت‌شده توسط Giampaolo Rodolà در bpo-9795.)

os¶

ماژول os تابع جدیدی به نام pipe2() دارد که امکان ایجاد پایپ با تنظیم اتمی پرچم‌های O_CLOEXEC یا O_NONBLOCK را فراهم می‌کند. این امر به‌ویژه برای اجتناب از شرایط رقابتی در برنامه‌های چندنخی مفید است.
ماژول os دارای تابع جدید sendfile() است که روشی کارآمد «کپی صفر» (zero-copy) برای کپی کردن داده‌ها از یک توصیف‌گر پرونده (یا سوکت) به توصیف‌گر دیگری فراهم می‌کند. عبارت «کپی صفر» (zero-copy) به این واقعیت اشاره دارد که تمام کپی کردن داده‌ها بین دو توصیف‌گر به‌طور کامل توسط هسته انجام می‌شود، بدون کپی شدن داده‌ها در بافرهای فضای کاربر. از sendfile() می‌توان برای کپی کردن کارآمد داده‌ها از یک پرونده روی دیسک به یک سوکت شبکه استفاده کرد، مثلاً برای دانلود یک پرونده.

(وصل ارسال‌شده توسط Ross Lagerwall و Giampaolo Rodolà در bpo-10882.)
برای پرهیز از شرایط رقابتی مانند حملات پیوند نمادین و مشکلات مربوط به پرونده‌ها و پوشه‌های موقت، دستکاری کردن توصیف‌گرهای پرونده به‌جای نام‌های پرونده قابل‌اعتمادتر (و همچنین سریع‌تر) است. پایتون 3.3 توابع موجود را بهبود می‌بخشد و توابع جدیدی برای کار با توصیف‌گرهای پرونده معرفی می‌کند (bpo-4761، bpo-10755 و bpo-14626).
- ماژول os تابع جدیدی به نام fwalk() دارد که مشابه walk() است، با این تفاوت که توصیف‌گرهای پرونده‌ی ارجاع‌دهنده به پوشه‌های پیموده‌شده را نیز تولید می‌کند. این به‌ویژه برای اجتناب از رقابت‌های پیوند نمادین مفید است.
- توابع زیر پارامترهای اختیاری جدید dir_fd (مسیرهای نسبی به توصیف‌گرهای پوشه) و/یا follow_symlinks (پیروی نکردن از پیوندهای نمادین) را دریافت می‌کنند: access()، chflags()، chmod()، chown()، link()، lstat()، mkdir()، mkfifo()، mknod()، open()، readlink()، remove()، rename()، replace()، rmdir()، stat()، symlink()، unlink()، utime(). پشتیبانی پلتفرم از استفاده از این پارامترها را می‌توان از طریق مجموعه‌های os.supports_dir_fd و os.supports_follow_symlinks بررسی کرد.
- توابع زیر اکنون برای آرگومان مسیر خود از توصیف‌گر پرونده پشتیبانی می‌کنند: chdir()، chmod()، chown()، execve()، listdir()، pathconf()، exists()، stat()، statvfs()، utime(). پشتیبانی پلتفرم از این قابلیت را می‌توان از طریق مجموعه‌ی os.supports_fd بررسی کرد.
access() یک آرگومان کلیدواژه‌ای effective_ids را می‌پذیرد که استفاده از uid/gid مؤثر به‌جای uid/gid واقعی را در بررسی دسترسی فعال می‌کند. می‌توان پشتیبانی پلتفرم از این قابلیت را از طریق مجموعه‌ی supports_effective_ids بررسی کرد.
ماژول os دو تابع جدید دارد: getpriority() و setpriority(). می‌توان از این توابع برای دریافت یا تنظیم نایس‌بودن (niceness)/اولویت فرایند به شکلی مشابه os.nice() اما گسترش‌یافته به همه فرایندها به‌جای فقط فرایند جاری استفاده کرد.

(وصله توسط Giampaolo Rodolà در bpo-10784 ارسال شد.)
تابع جدید os.replace() امکان تغییر نام یک پرونده همراه با بازنویسی مقصد را به‌صورت چندسکویی فراهم می‌کند. با os.rename()، در POSIX پرونده مقصدِ موجود بازنویسی می‌شود، اما در ویندوز خطا ایجاد می‌شود. (مشارکت آنتوان پی‌ترو در bpo-8828.)
خانواده‌ی توابع stat (stat()، fstat() و lstat()) اکنون از خواندن مهرهای زمانی یک پرونده با دقت نانوثانیه پشتیبانی می‌کنند. به‌طور متقارن، utime() اکنون می‌تواند مهرهای زمانی پرونده را با دقت نانوثانیه بنویسد. (مشارکت‌شده توسط لری هستینگز در bpo-14127.)
تابع جدید os.get_terminal_size() اندازه‌ی پایانه‌ی متصل به یک توصیف‌گر پرونده را استعلام می‌کند. همچنین shutil.get_terminal_size() را ببینید. (ارائه‌شده توسط Zbigniew Jędrzejewski-Szmek در bpo-13609.)

توابع جدید برای پشتیبانی از ویژگی‌های توسعه‌یافته لینوکس (bpo-12720): getxattr()، listxattr()، removexattr()، setxattr().
رابط جدید برای زمان‌بند. این توابع کنترل می‌کنند که سیستم‌عامل چگونه زمان CPU را به یک فرایند تخصیص می‌دهد. توابع جدید: sched_get_priority_max()، sched_get_priority_min()، sched_getaffinity()، sched_getparam()، sched_getscheduler()، sched_rr_get_interval()، sched_setaffinity()، sched_setparam()، sched_setscheduler()، sched_yield()،
توابع جدید برای کنترل سامانه فایل‌بندی:
- posix_fadvise(): قصد دسترسی به داده‌ها با الگوی مشخصی را اعلام می‌کند و بدین ترتیب به هسته اجازه می‌دهد بهینه‌سازی‌هایی انجام دهد.
- posix_fallocate(): تضمین می‌کند که فضای کافی دیسک برای یک پرونده تخصیص داده شود.
- sync(): نوشتن اجباری همه‌چیز روی دیسک.
توابع جدید اضافی posix:
- lockf(): اعمال، آزمایش یا حذف یک قفل POSIX روی یک توصیف‌گر پرونده‌ی باز.
- pread(): خواندن از یک توصیف‌گر پرونده در یک آفست، به‌طوری که آفست پرونده بدون تغییر باقی می‌ماند.
- pwrite(): در توصیف‌گر پرونده از یک آفست می‌نویسد و آفست پرونده را بدون تغییر باقی می‌گذارد.
- readv(): خواندن از یک توصیف‌گر پرونده درون تعدادی بافر نوشتنی.
- truncate(): پرونده‌ی متناظر با path را کوتاه می‌کند، به‌طوری‌که حجم آن حداکثر length بایت باشد.
- waitid(): منتظر اتمام یک یا چند فرایند فرزند می‌ماند.
- writev(): محتوای buffers را در یک توصیف‌گر پرونده می‌نویسد، که در آن buffers دنباله‌ای دلخواه از بافرها است.
- getgrouplist() (bpo-9344): فهرست شناسه‌های گروه‌هایی را که کاربر مشخص‌شده عضو آن‌هاست برمی‌گرداند.
times() و uname(): نوع بازگشتی از یک تاپل به یک شیء شبه‌تاپل با ویژگی‌های نام‌دار تغییر یافت.
برخی پلتفرم‌ها اکنون از ثابت‌های اضافی مانند os.SEEK_HOLE و os.SEEK_DATA برای تابع lseek() پشتیبانی می‌کنند.
ثابت‌های جدید RTLD_LAZY، RTLD_NOW، RTLD_GLOBAL، RTLD_LOCAL، RTLD_NODELETE، RTLD_NOLOAD و RTLD_DEEPBIND در پلتفرم‌هایی که از آن‌ها پشتیبانی می‌کنند در دسترس هستند. این ثابت‌ها برای استفاده همراه با تابع sys.setdlopenflags() هستند و جای ثابت‌های مشابه تعریف‌شده در ctypes و DLFCN را می‌گیرند. (نوشته‌شده توسط Victor Stinner در bpo-13226.)
os.symlink() اکنون آرگومان کلیدواژه‌ای target_is_directory را در پلتفرم‌های غیر ویندوزی می‌پذیرد (و نادیده می‌گیرد) تا پشتیبانی چندپلتفرمی آسان‌تر شود.

pdb¶

تکمیل با Tab اکنون نه‌تنها برای نام فرمان‌ها، بلکه برای آرگومان‌های آن‌ها نیز در دسترس است. برای نمونه، برای فرمان break، نام توابع و پرونده‌ها تکمیل می‌شوند.

(مشارکت‌شده توسط Georg Brandl در bpo-14210)

pickle¶

اشیاء pickle.Pickler اکنون دارای یک ویژگی اختیاری dispatch_table هستند که امکان تنظیم توابع کاهش مخصوص هر پیکل‌ساز را فراهم می‌کند.

(مشارکت‌شده توسط Richard Oudkerk در bpo-14166.)

pydoc¶

رابط گرافیکی Tk و تابع serve() از ماژول pydoc حذف شده‌اند: pydoc -g و serve() در پایتون 3.2 منسوخ شده بودند.

re¶

عبارات باقاعده‌ی str اکنون از گریزهای \u و \U پشتیبانی می‌کنند.

(مشارکت Serhiy Storchaka در bpo-3665.)

sched¶

run() اکنون یک پارامتر blocking می‌پذیرد که وقتی روی false تنظیم شود، باعث می‌شود متد رویدادهای زمان‌بندی‌شده‌ای را که زودترین زمان انقضا را دارند (در صورت وجود) اجرا کند و سپس بلافاصله بازگردد. این در صورتی مفید است که بخواهید از scheduler در برنامه‌های غیرمسدودکننده استفاده کنید. (مشارکت‌شده توسط Giampaolo Rodolà در bpo-13449.)
کلاس scheduler اکنون می‌تواند به‌طور ایمن در محیط‌های چندنخی استفاده شود. (با مشارکت Josiah Carlson و Giampaolo Rodolà در bpo-8684.)
پارامترهای timefunc و delayfunct سازنده‌ی کلاس scheduler اکنون اختیاری هستند و مقدار پیش‌فرض آن‌ها به‌ترتیب time.time() و time.sleep() است. (مشارکت‌شده توسط Chris Clark در bpo-13245.)
پارامتر argument در enter() و enterabs() اکنون اختیاری است. (مشارکت‌شده توسط Chris Clark در bpo-13245.)
enter() و enterabs() اکنون یک پارامتر kwargs را می‌پذیرند. (مشارکت‌شده توسط Chris Clark در bpo-13245.)

select¶

پلتفرم‌های سولاریس و مشتقات آن دارای کلاس جدید select.devpoll برای سوکت‌های ناهمگام با کارایی بالا از طریق /dev/poll هستند. (با مشارکت Jesús Cea Avión در bpo-6397.)

shlex¶

تابع کمکی quote که پیش‌تر مستند نشده بود، از ماژول‌های pipes به ماژول shlex منتقل شده و مستند شده است. quote() تمام نویسه‌های یک رشته را که ممکن است در غیر این صورت توسط پوسته معنای خاصی به آن‌ها داده شود، به‌درستی خنثی می‌کند.

shutil¶

توابع جدید:
- disk_usage(): آمار فضای کل، استفاده‌شده و آزاد دیسک را فراهم می‌کند. (مشارکت‌شده توسط Giampaolo Rodolà در bpo-12442.)
- chown(): به شما امکان می‌دهد کاربر و/یا گروه مسیر داده‌شده را تغییر دهید، همچنین با تعیین نام کاربر/گروه و نه فقط شناسه‌های عددی آن‌ها. (مشارکت‌شده توسط Sandro Tosi در bpo-12191.)
- shutil.get_terminal_size(): اندازه‌ی پنجره‌ی پایانه‌ای را که مفسر به آن متصل است برمی‌گرداند. (مشارکت‌شده توسط Zbigniew Jędrzejewski-Szmek در bpo-13609.)
copy2() و copystat() اکنون مهرهای زمانی پرونده را با دقت نانوثانیه، در پلتفرم‌هایی که از آن پشتیبانی می‌کنند، حفظ می‌کنند. این توابع همچنین «ویژگی‌های توسعه‌یافته»ی پرونده‌ها را در لینوکس حفظ می‌کنند. (با مشارکت Larry Hastings در bpo-14127 و bpo-15238.)
چندین تابع اکنون یک آرگومان اختیاری symlinks می‌گیرند: وقتی این پارامتر درست باشد، از پیوندهای نمادین پیروی نمی‌شود و عملیات به‌جای آن روی خودِ پیوند نمادین عمل می‌کند (یا در صورت لزوم، یکی ایجاد می‌کند). (مشارکت‌شده توسط هاینک شلاواک در bpo-12715.)
هنگام کپی کردن پرونده‌ها به یک سامانه فایل‌بندی دیگر، move() اکنون با پیوندهای نمادین همانند دستور mv در posix برخورد می‌کند و به جای کپی کردن محتوای پرونده‌ی هدف، پیوند نمادین را بازایجاد می‌کند. (مشارکت‌شده توسط Jonathan Niehof در bpo-9993.) move() اکنون آرگومان dst را نیز به عنوان نتیجه‌ی خود برمی‌گرداند.
rmtree() اکنون در پلتفرم‌هایی که پارامتر جدید dir_fd را در os.open() و os.unlink() پشتیبانی می‌کنند، در برابر حملات مبتنی بر پیوند نمادین مقاوم است. (مشارکت Martin von Löwis و Hynek Schlawack در bpo-4489.)

سیگنال¶

ماژول signal توابع جدیدی دارد:
- pthread_sigmask(): واکشی و/یا تغییر نقاب سیگنال نخ فراخواننده (مشارکت Jean-Paul Calderone در bpo-8407)؛
- pthread_kill(): ارسال یک سیگنال به یک نخ؛
- sigpending(): بررسی توابع در انتظار؛
- sigwait(): انتظار برای یک سیگنال؛
- sigwaitinfo(): منتظر یک سیگنال می‌ماند و اطلاعات دقیق درباره‌ی آن را برمی‌گرداند؛
- sigtimedwait(): مانند sigwaitinfo() اما با مهلت زمانی.
هندلر سیگنال به‌جای بایت تهی، شماره‌ی سیگنال را به‌صورت یک بایت واحد در توصیف‌گر پرونده‌ی بیدارسازی (wakeup) می‌نویسد. بنابراین می‌توان برای بیش از یک سیگنال منتظر ماند و دانست که کدام سیگنال‌ها رخ داده‌اند.
signal.signal() و signal.siginterrupt() به جای یک RuntimeError، یک OSError ایجاد می‌کنند: OSError دارای ویژگی errno است.

smtpd¶

ماژول smtpd اکنون از RFC 5321 (SMTP توسعه‌یافته) و RFC 1870 (افزونه اندازه) پشتیبانی می‌کند. طبق استاندارد، این افزونه‌ها اگر و تنها اگر کلاینت نشست را با دستور EHLO آغاز کند فعال می‌شوند.

(پشتیبانی اولیه از ELHO توسط Alberto Trevino. گسترش اندازه توسط Juhana Jauhiainen. کارهای اضافی قابل‌توجه بر روی وصل با مشارکت Michele Orrù و Dan Boswell انجام شد. bpo-8739)

smtplib¶

کلاس‌های SMTP، SMTP_SSL و LMTP اکنون آرگومان کلیدواژه‌ای source_address را می‌پذیرند تا (host, port) را که هنگام ایجاد سوکت خروجی در فراخوانی مقید کردن به عنوان آدرس مبدأ استفاده می‌شود، مشخص کنند. (مشارکت‌شده توسط Paulo Scardine در bpo-11281.)

SMTP اکنون از پروتکل مدیریت زمینه پشتیبانی می‌کند و اجازه می‌دهد از یک نمونه SMTP در دستور with استفاده شود. (مشارکت‌شده توسط Giampaolo Rodolà در bpo-11289.)

سازنده‌ی SMTP_SSL و متد starttls() اکنون پارامتری از نوع SSLContext را برای کنترل پارامترهای کانال امن می‌پذیرند. (مشارکت Kasun Herath در bpo-8809.)

socket¶

کلاس socket اکنون متدهای اضافی برای پردازش داده‌های جانبی (ancillary data) در اختیار می‌گذارد، در صورتی که پلتفرم زیرین از آن‌ها پشتیبانی کند:
(ارائه‌شده توسط David Watson در bpo-6560، بر اساس وصلی قدیمی‌تر از Heiko Wundram)
کلاس socket اکنون خانواده‌ی پروتکل PF_CAN (https://en.wikipedia.org/wiki/Socketcan) را در لینوکس (https://lwn.net/Articles/253425) پشتیبانی می‌کند.

(مشارکت Matthias Fuchs، به‌روزرسانی‌شده توسط Tiago Gonçalves در bpo-10141.)
کلاس socket اکنون از خانواده پروتکل PF_RDS پشتیبانی می‌کند (https://en.wikipedia.org/wiki/Reliable_Datagram_Sockets و https://oss.oracle.com/projects/rds).
کلاس socket اکنون از خانواده پروتکل PF_SYSTEM در OS X پشتیبانی می‌کند. (ارائه‌شده توسط Michael Goderbauer در bpo-13777.)
تابع جدید sethostname() اجازه می‌دهد تا در صورتی که فرایند فراخواننده امتیازهای کافی داشته باشد، نام میزبان روی سیستم‌های یونیکس تنظیم شود. (مشارکت‌شده توسط Ross Lagerwall در bpo-10866.)

socketserver¶

BaseServer اکنون دارای متدی قابل بازنویسی به نام service_actions() است که در حلقه سرویس توسط متد serve_forever() فراخوانی می‌شود. ForkingMixIn اکنون از این متد برای پاک‌سازی فرایندهای فرزند زامبی استفاده می‌کند. (مشارکت‌شده توسط Justin Warkentin در bpo-11109.)

sqlite3¶

متد جدید set_trace_callback() در sqlite3.Connection می‌تواند برای ثبت ردگیری تمام فرمان‌های sql پردازش‌شده توسط sqlite استفاده شود. (مشارکت‌شده توسط Torsten Landschoff در bpo-11688.)

ssl¶

ماژول ssl دو تابع جدید تولید تصادفی دارد:
- RAND_bytes(): تولید بایت‌های شبه‌تصادفیِ قوی از نظر رمزنگاری.
- RAND_pseudo_bytes(): تولید بایت‌های شبه‌تصادفی.
(مشارکت‌شده توسط Victor Stinner در bpo-12049.)
ماژول ssl اکنون سلسله‌مراتب ریزدانه‌تری از استثناها را در دسترس قرار می‌دهد تا بررسی انواع مختلف خطاها آسان‌تر شود. (ارائه‌شده توسط Antoine Pitrou در bpo-11183.)
load_cert_chain() اکنون آرگومان password را می‌پذیرد تا در صورت رمزنگاری‌شده بودن کلید خصوصی استفاده شود. (مشارکت‌شده توسط Adam Simpkins در bpo-12803.)
تبادل کلید Diffie-Hellman، هم به‌صورت معمولی و هم مبتنی بر منحنی بیضوی، اکنون از طریق متدهای load_dh_params() و set_ecdh_curve() پشتیبانی می‌شود. (مشارکت‌شده توسط Antoine Pitrou در bpo-13626 و bpo-13627.)
سوکت‌های SSL یک متد جدید get_channel_binding() دارند که امکان پیاده‌سازی برخی از سازوکارهای احراز هویت مانند SCRAM-SHA-1-PLUS را فراهم می‌کند. (مشارکت‌شده توسط Jacek Konieczny در bpo-12551.)
می‌توانید الگوریتم فشرده‌سازی SSL استفاده‌شده در یک سوکت SSL را به لطف متد جدید compression() آن پرس‌وجو کنید. ویژگی جدید OP_NO_COMPRESSION می‌تواند برای غیرفعال کردن فشرده‌سازی استفاده شود. (ارائه‌شده توسط Antoine Pitrou در bpo-13634.)
پشتیبانی از افزونه‌ی مذاکره‌ی پروتکل بعدی (Next Protocol Negotiation) با استفاده از متد ssl.SSLContext.set_npn_protocols() افزوده شده است. (مشارکت‌شده توسط Colin Marc در bpo-14204.)
اکنون می‌توان خطاهای SSL را به لطف ویژگی‌های library و reason آسان‌تر درون‌نگری کرد. (مشارکت‌شده توسط آنتوان پی‌ترو در bpo-14837.)
تابع get_server_certificate() اکنون از IPv6 پشتیبانی می‌کند. (مشارکت‌شده توسط Charles-François Natali در bpo-11811.)
ویژگی جدید OP_CIPHER_SERVER_PREFERENCE اجازه می‌دهد سوکت‌های سرور SSLv3 را طوری تنظیم کنید که از ترتیب ترجیحی رمزهای سرور به‌جای ترتیب ترجیحی رمزهای کلاینت استفاده کنند (bpo-13635).

stat¶

تابع مستندنشده‌ی tarfile.filemode به stat.filemode() منتقل شده است. از این تابع می‌توان برای تبدیل حالت یک پرونده به رشته‌ای به شکل '-rwxrwxrwx' استفاده کرد.

(باهمکاری Giampaolo Rodolà در bpo-14807.)

struct¶

ماژول struct اکنون از ssize_t و size_t به‌ترتیب از طریق کدهای جدید n و N پشتیبانی می‌کند. (مشارکت آنتوان پی‌ترو در bpo-3163.)

subprocess¶

رشته‌های فرمان در پلتفرم‌های پوزیکس اکنون می‌توانند اشیای بایت باشند. (مشارکت توسط Victor Stinner در bpo-8513.)

ثابت جدید DEVNULL امکان سرکوب خروجی به شکلی مستقل از پلتفرم را فراهم می‌کند. (مشارکت‌شده توسط Ross Lagerwall در bpo-5870.)

sys¶

ماژول sys یک تاپل نام‌دار جدید به نام thread_info دارد که اطلاعات مربوط به پیاده‌سازی نخ را نگه می‌دارد (bpo-11223).

tarfile¶

اکنون tarfile کدگذاری lzma را از طریق ماژول lzma پشتیبانی می‌کند. (مشارکت‌شده توسط Lars Gustäbel در bpo-5689.)

tempfile¶

متد truncate() از tempfile.SpooledTemporaryFile اکنون پارامتر size را می‌پذیرد. (مشارکت‌شده توسط رایان کلی در bpo-9957.)

textwrap¶

ماژول textwrap یک تابع جدید indent() دارد که افزودن پیشوندی مشترک به سطرهای انتخاب‌شده در یک بلوک از متن را ساده می‌کند (bpo-13857).

threading¶

threading.Condition، threading.Semaphore، threading.BoundedSemaphore، threading.Event و threading.Timer، که همگی قبلاً توابع کارخانه‌ای بودند و نمونه‌ای از یک کلاس را برمی‌گرداندند، اکنون کلاس هستند و می‌توان از آن‌ها زیرکلاس گرفت. (مشارکت‌شده توسط Éric Araujo در bpo-10968.)

سازنده‌ی threading.Thread اکنون یک آرگومان کلیدواژه‌ای daemon را برای بازنویسی رفتار پیش‌فرضِ به ارث بردن مقدار پرچم daemon از نخ والد می‌پذیرد (bpo-6064).

تابع _thread.get_ident که پیش‌تر خصوصی بود، اکنون به‌عنوان تابع عمومی threading.get_ident() در دسترس است. این کار چند مورد از دسترسی مستقیم به ماژول _thread در کتابخانه استاندارد را از بین می‌برد. کدهای شخص ثالثی که از _thread.get_ident استفاده می‌کردند نیز باید به‌طور مشابه تغییر داده شوند تا از رابط عمومی جدید استفاده کنند.

time¶

PEP 418 توابع جدیدی به ماژول time اضافه کرد:

get_clock_info(): اطلاعات مربوط به یک ساعت را دریافت می‌کند.
monotonic(): ساعت یکنواخت (نمی‌تواند به عقب برگردد)، از به‌روزرسانی‌های ساعت سیستم تأثیر نمی‌پذیرد.
perf_counter(): شمارنده عملکرد با بالاترین وضوح موجود برای اندازه‌گیری مدت زمان کوتاه.
process_time(): مجموع زمان CPU سیستمی و کاربری فرایند جاری.

سایر توابع جدید:

توابع clock_getres()، clock_gettime() و clock_settime() به همراه ثابت‌های CLOCK_xxx. (مشارکت‌شده توسط Victor Stinner در bpo-10278.)

برای بهبود سازگاری بین‌سکویی، sleep() اکنون هنگامی که مقدار توقف منفی به آن ارسال شود، استثنای ValueError را ایجاد می‌کند. پیش‌تر این کار در posix خطا ایجاد می‌کرد، اما در ویندوز به توقف بی‌نهایت منجر می‌شد.

types¶

افزودن کلاس جدید types.MappingProxyType: پراکسی فقط‌خواندنی یک نگاشت. (bpo-14386)

توابع جدید types.new_class() و types.prepare_class() پشتیبانی از ایجاد پویای نوع مطابق با PEP 3115 را فراهم می‌کنند. (bpo-14588)

unittest¶

assertRaises()، assertRaisesRegex()، assertWarns() و assertWarnsRegex() اکنون هنگامی که به‌عنوان مدیر زمینه استفاده می‌شوند، آرگومان کلیدواژه‌ای msg را می‌پذیرند. (مشارکت Ezio Melotti و Winston Ewert در bpo-10775.)

unittest.TestCase.run() اکنون شیء TestResult را برمی‌گرداند.

urllib¶

کلاس Request اکنون آرگومان method را می‌پذیرد که get_method() از آن برای تعیین اینکه چه متد HTTP باید استفاده شود، استفاده می‌کند. برای مثال، این یک درخواست 'HEAD' ارسال می‌کند:

>>> urlopen(Request('https://www.python.org', method='HEAD'))

(bpo-1673007)

webbrowser¶

ماژول webbrowser از «مرورگرهای» بیشتری پشتیبانی می‌کند: گوگل کروم (با نام‌های chrome، chromium، chrome-browser یا chromium-browser بسته به نسخه و سیستم‌عامل)، و راه‌اندازهای عمومی xdg-open از پروژه‌ی FreeDesktop.org و gvfs-open که هندلر پیش‌فرض URI برای GNOME 3 است. (اولی توسط Arnaud Calmettes در bpo-13620 و دومی توسط Matthias Klose در bpo-14493 ارائه شده‌اند.)

xml.etree.ElementTree¶

ماژول xml.etree.ElementTree اکنون به‌صورت پیش‌فرض شتاب‌دهنده C خود را ایمپورت می‌کند؛ دیگر نیازی به ایمپورت صریح xml.etree.cElementTree نیست (این ماژول برای سازگاری با نسخه‌های پیشین باقی می‌ماند، اما اکنون منسوخ شده است). علاوه بر این، خانواده‌ی متدهای iter در Element بهینه شده است (در C بازنویسی شده است). مستندات این ماژول نیز با مثال‌های افزوده‌شده و مرجعی دقیق‌تر، به‌طور چشمگیری بهبود یافته است.

zlib¶

ویژگی جدید zlib.Decompress.eof این امکان را فراهم می‌کند که میان یک جریان فشرده‌ی به‌درستی شکل‌گرفته و یک جریان ناقص یا قطع‌شده تمایز قائل شوید. (با مشارکت Nadeem Vawda در bpo-12646.)

ویژگی جدید zlib.ZLIB_RUNTIME_VERSION رشته‌ی نسخه‌ی کتابخانه‌ی زیرین zlib را که در ران‌تایم بارگذاری می‌شود، گزارش می‌دهد. (مشارکت‌شده توسط Torsten Landschoff در bpo-12306.)

بهینه‌سازی‌ها¶

بهبودهای عملکردی عمده‌ای افزوده شده‌اند:

به لطف PEP 393، برخی از عملیات روی رشته‌های یونیکد بهینه شده‌اند:
- ردپای حافظه بسته به متن بر ۲ تا ۴ تقسیم می‌شود
- کدگذاری یک رشته اسکی به UTF-8 دیگر نیازی به کدگذاری نویسه‌ها ندارد؛ نمایش UTF-8 با نمایش اسکی به اشتراک گذاشته شده است
- کدگذار UTF-8 بهینه‌سازی شده است
- تکرار یک تک‌حرف اسکی و گرفتن زیررشته‌ای از یک رشته اسکی ۴ برابر سریع‌تر است
UTF-8 اکنون ۲ تا ۴ برابر سریع‌تر شده است. کدگذاری UTF-16 اکنون تا ۱۰ برابر سریع‌تر شده است.

(مشارکت‌شده توسط Serhiy Storchaka در bpo-14624، bpo-14738 و bpo-15026.)

تغییرات ساخت و C API¶

تغییرات در فرایند ساخت پایتون و در C API شامل موارد زیر است:

تابع جدید مرتبط با PEP 3118:
- PyMemoryView_FromMemory()
PEP 393 نوع‌های جدید یونیکد، ماکروها و توابع را افزود:
- API سطح بالا:
- API سطح پایین:
  - انواع Py_UCS1، Py_UCS2 و Py_UCS4
  - ساختارهای PyASCIIObject و PyCompactUnicodeObject
  - PyUnicode_READY
  - PyUnicode_FromKindAndData()
  - PyUnicode_AsUCS4(), PyUnicode_AsUCS4Copy()
  - PyUnicode_DATA, PyUnicode_1BYTE_DATA, PyUnicode_2BYTE_DATA, PyUnicode_4BYTE_DATA
  - PyUnicode_KIND به همراه enum PyUnicode_Kind: PyUnicode_WCHAR_KIND، PyUnicode_1BYTE_KIND، PyUnicode_2BYTE_KIND، PyUnicode_4BYTE_KIND
  - PyUnicode_READ, PyUnicode_READ_CHAR, PyUnicode_WRITE
  - PyUnicode_MAX_CHAR_VALUE
PyArg_ParseTuple اکنون bytearray را برای قالب c می‌پذیرد (bpo-12380).

منسوخ¶

سیستم‌عامل‌های پشتیبانی‌نشده¶

OS/2 و VMS به دلیل نبود نگهدارنده، دیگر پشتیبانی نمی‌شوند.

ویندوز 2000 و پلتفرم‌های ویندوز که COMSPEC را روی command.com تنظیم می‌کنند، به دلیل بار نگهداری دیگر پشتیبانی نمی‌شوند.

پشتیبانی از OSF، که در نسخه 3.2 منسوخ شده بود، به‌طور کامل حذف شده است.

ماژول‌ها، توابع و متدهای منسوخ پایتون¶

ارسال یک رشته‌ی غیرخالی به object.__format__() منسوخ شده است و در پایتون 3.4 باعث ایجاد TypeError خواهد شد (bpo-9856).
کدک unicode_internal به دلیل PEP 393 منسوخ شده است؛ از UTF-8، UTF-16 (utf-16-le یا utf-16-be) یا UTF-32 (utf-32-le یا utf-32-be) استفاده کنید
ftplib.FTP.nlst() و ftplib.FTP.dir(): از ftplib.FTP.mlsd() استفاده کنید
platform.popen(): از ماژول subprocess استفاده کنید. به‌ویژه بخش جایگزینی توابع قدیمی با ماژول subprocess را بررسی کنید (bpo-11377).
bpo-13374: API بایتی ویندوز در ماژول os منسوخ شده است. به‌جای نام پرونده‌های بایتی، از نام پرونده‌های یونیکد استفاده کنید تا دیگر به صفحه کد ANSI وابسته نباشید و از هر نام پرونده‌ای پشتیبانی کنید.
bpo-13988: ماژول xml.etree.cElementTree منسوخ شده است. شتاب‌دهنده هر زمان که در دسترس باشد، به‌طور خودکار استفاده می‌شود.
رفتار time.clock() به پلتفرم بستگی دارد: بسته به نیازمندی‌هایتان، به‌جای آن از تابع جدید time.perf_counter() یا time.process_time() استفاده کنید تا رفتاری به‌خوبی تعریف‌شده داشته باشید.
تابع os.stat_float_times() منسوخ شده است.
ماژول abc:
- @abc.abstractproperty منسوخ شده است؛ به جای آن از @property همراه با @abc.abstractmethod استفاده کنید.
- @abc.abstractclassmethod منسوخ شده است؛ به‌جای آن از @classmethod همراه با @abc.abstractmethod استفاده کنید.
- @abc.abstractstaticmethod منسوخ شده است؛ به‌جای آن از @staticmethod همراه با @abc.abstractmethod استفاده کنید.
بسته‌ی importlib:
- importlib.abc.SourceLoader.path_mtime() اکنون به نفع importlib.abc.SourceLoader.path_stats() منسوخ شده است، زیرا پرونده‌های بایت‌کد اکنون هم زمان تغییر و هم اندازه‌ی پرونده منبعی را که پرونده بایت‌کد از روی آن کامپایل شده است ذخیره می‌کنند.

توابع و نوع‌های منسوخ API زبان C¶

نوع Py_UNICODE توسط PEP 393 منسوخ شده است و در پایتون 4 حذف خواهد شد. تمام توابعی که از این نوع استفاده می‌کنند، منسوخ شده‌اند:

توابع و متدهای یونیکد که از نوع‌های Py_UNICODE و Py_UNICODE* استفاده می‌کنند:

PyUnicode_FromUnicode: از PyUnicode_FromWideChar() یا PyUnicode_FromKindAndData() استفاده کنید
PyUnicode_AS_UNICODE، PyUnicode_AsUnicode()، PyUnicode_AsUnicodeAndSize(): از PyUnicode_AsWideCharString() استفاده کنید
PyUnicode_AS_DATA: از PyUnicode_DATA همراه با PyUnicode_READ و PyUnicode_WRITE استفاده کنید
PyUnicode_GET_SIZE، PyUnicode_GetSize(): از PyUnicode_GET_LENGTH یا PyUnicode_GetLength() استفاده کنید
PyUnicode_GET_DATA_SIZE: از PyUnicode_GET_LENGTH(str) * PyUnicode_KIND(str) استفاده کنید (فقط روی رشته‌های آماده کار می‌کنند)
PyUnicode_AsUnicodeCopy(): از PyUnicode_AsUCS4Copy() یا PyUnicode_AsWideCharString() استفاده کنید
PyUnicode_GetMax()

توابع و ماکروهایی که رشته‌های Py_UNICODE* را دستکاری می‌کنند:

Py_UNICODE_strlen(): از PyUnicode_GetLength() یا PyUnicode_GET_LENGTH استفاده کنید
Py_UNICODE_strcat(): از PyUnicode_CopyCharacters() یا PyUnicode_FromFormat() استفاده کنید
Py_UNICODE_strcpy()، Py_UNICODE_strncpy()، Py_UNICODE_COPY(): از PyUnicode_CopyCharacters() یا PyUnicode_Substring() استفاده کنید
Py_UNICODE_strcmp(): از PyUnicode_Compare() استفاده کنید
Py_UNICODE_strncmp(): از PyUnicode_Tailmatch() استفاده کنید
Py_UNICODE_strchr()، Py_UNICODE_strrchr(): از PyUnicode_FindChar() استفاده کنید
Py_UNICODE_FILL(): از PyUnicode_Fill() استفاده کنید
Py_UNICODE_MATCH

کدگذار‌ها:

PyUnicode_Encode(): از PyUnicode_AsEncodedObject() استفاده کنید
PyUnicode_EncodeUTF7()
PyUnicode_EncodeUTF8(): از PyUnicode_AsUTF8() یا PyUnicode_AsUTF8String() استفاده کنید
PyUnicode_EncodeUTF32()
PyUnicode_EncodeUTF16()
PyUnicode_EncodeUnicodeEscape() از PyUnicode_AsUnicodeEscapeString() استفاده کنید
PyUnicode_EncodeRawUnicodeEscape() از PyUnicode_AsRawUnicodeEscapeString() استفاده کنید
PyUnicode_EncodeLatin1(): از PyUnicode_AsLatin1String() استفاده کنید
PyUnicode_EncodeASCII(): از PyUnicode_AsASCIIString() استفاده کنید
PyUnicode_EncodeCharmap()
PyUnicode_TranslateCharmap()
PyUnicode_EncodeMBCS(): از PyUnicode_AsMBCSString() یا PyUnicode_EncodeCodePage() (با CP_ACP به‌عنوان code_page) استفاده کنید
PyUnicode_EncodeDecimal(), PyUnicode_TransformDecimalToASCII()

قابلیت‌های منسوخ¶

کد قالب 'u' در ماژول array اکنون منسوخ شده است و در Python 4 همراه با بقیه‌ی API (Py_UNICODE) حذف خواهد شد.

انتقال به پایتون 3.3¶

این بخش تغییرات پیش‌تر شرح داده‌شده و سایر رفع اشکال‌هایی را فهرست می‌کند که ممکن است نیاز به تغییراتی در کد شما داشته باشند.

انتقال کد پایتون¶

تصادفی‌سازی هش به‌صورت پیش‌فرض فعال است. برای غیرفعال کردن تصادفی‌سازی هش، متغیر محیطی PYTHONHASHSEED را برابر 0 قرار دهید. همچنین متد object.__hash__() را ببینید.
bpo-12326: در لینوکس، sys.platform دیگر نسخه‌ی اصلی را در بر نمی‌گیرد. اکنون همیشه 'linux' است، به‌جای 'linux2' یا 'linux3' بسته به نسخه‌ی لینوکسی که برای ساخت پایتون استفاده شده است. sys.platform == 'linux2' را با sys.platform.startswith('linux') جایگزین کنید، یا مستقیماً با sys.platform == 'linux'، اگر نیازی به پشتیبانی از نسخه‌های قدیمی‌تر پایتون ندارید.
bpo-13847، bpo-14180: time و datetime: اگر مهر زمانی خارج از محدوده باشد، اکنون به جای استثنای ValueError، استثنای OverflowError ایجاد می‌شود. اگر توابع C یعنی gmtime() یا localtime() شکست بخورند، اکنون استثنای OSError ایجاد می‌شود.
یابنده‌های پیش‌فرضی که ایمپورت از آن‌ها استفاده می‌کند، اکنون از نهانگاهی از محتویات یک پوشه‌ی خاص بهره می‌برند. اگر یک پرونده‌ی منبع پایتون یا پرونده‌ی بایت‌کد بدون منبع ایجاد می‌کنید، حتماً importlib.invalidate_caches() را فراخوانی کنید تا نهانگاه پاک شود و یابنده‌ها پرونده‌ی جدید را متوجه شوند.
ImportError اکنون از نام کامل ماژولی که تلاش شده ایمپورت شود استفاده می‌کند. داک‌تست‌هایی (doctest) که پیام‌های ImportError را بررسی می‌کنند، باید به‌روزرسانی شوند تا به جای صرفاً انتهای نام، از نام کامل ماژول استفاده کنند.
آرگومان index تابع __import__() اکنون به‌جای ‎-1 به‌طور پیش‌فرض 0 است و دیگر از مقادیر منفی پشتیبانی نمی‌کند. این یک سهل‌انگاری بود که هنگام پیاده‌سازی PEP 328، مقدار پیش‌فرض همچنان ‎-1 باقی ماند. اگر لازم است به انجام یک ایمپورت نسبی و پس از آن یک ایمپورت مطلق ادامه دهید، ایمپورت نسبی را با اندیس 1 و سپس ایمپورت دیگری را با اندیس 0 انجام دهید. با این حال، ترجیح داده می‌شود که به‌جای فراخوانی مستقیم __import__()، از importlib.import_module() استفاده کنید.
__import__() دیگر اجازه نمی‌دهد برای ماژول‌های سطح بالا از مقدار اندیسی غیر از ۰ استفاده کنید. برای نمونه، __import__('sys', level=1) اکنون خطا است.
از آنجا که sys.meta_path و sys.path_hooks اکنون به‌صورت پیش‌فرض یابنده‌هایی روی خود دارند، به احتمال زیاد می‌خواهید برای افزودن به آن فهرست‌ها به‌جای list.append() از list.insert() استفاده کنید.
از آنجا که None اکنون در sys.path_importer_cache درج می‌شود، اگر در حال پاک‌سازی ورودی‌های دیکشنری مسیرهایی هستید که یابنده ندارند، برای سازگاری با نسخه‌های قبلی باید کلیدهایی را که با مقادیر None و imp.NullImporter جفت‌شده‌اند حذف کنید. این کار در نسخه‌های قدیمی‌تر پایتون که None را دوباره در sys.path_importer_cache درج می‌کنند — جایی که نشان‌دهنده استفاده از یابنده‌های ضمنی است — سربار اضافی ایجاد خواهد کرد، اما از نظر معنایی نباید چیزی را تغییر دهد.
importlib.abc.Finder دیگر متد انتزاعی find_module() را که باید پیاده‌سازی شود تعیین نمی‌کند. اگر برای پیاده‌سازی آن متد به زیرکلاس‌ها تکیه داشتید، حتماً ابتدا وجود متد را بررسی کنید. با این حال، در صورت کار با یابنده‌های ورودی مسیر احتمالاً می‌خواهید ابتدا find_loader() را بررسی کنید.
pkgutil به‌گونه‌ای تبدیل شده است که به‌صورت داخلی از importlib استفاده کند. این کار بسیاری از حالت‌های مرزی‌ای را که در آن‌ها رفتار قدیمی شبیه‌سازی ایمپورت PEP 302 با رفتار سیستم ایمپورت واقعی مطابقت نداشت، حذف می‌کند. خودِ شبیه‌سازی ایمپورت همچنان وجود دارد، اما اکنون منسوخ شده است. توابع pkgutil.iter_importers() و pkgutil.walk_packages() قلاب‌های استاندارد ایمپورت را به‌عنوان موارد خاص در نظر می‌گیرند، بنابراین این قلاب‌ها همچنان پشتیبانی می‌شوند، هرچند متد غیراستاندارد iter_modules() را ارائه نمی‌دهند.
یک باگ قدیمی مربوط به انطباق با RFC (bpo-1079) در تجزیه‌ای که email.header.decode_header() انجام می‌دهد، رفع شده است. کدی که از الگوی استاندارد برای تبدیل سرآیندهای کدگذاری‌شده به یونیکد استفاده می‌کند (str(make_header(decode_header(h)))، هیچ تغییری نخواهد دید، اما کدی که به تاپل‌های جداگانه‌ی برگردانده‌شده توسط decode_header نگاه می‌کند، خواهد دید که فاصله سفیدی که پیش یا پس از بخش‌های ASCII قرار دارد، اکنون در بخش ASCII گنجانده شده است. کدی که سرآیندها را با استفاده از make_header می‌سازد نیز باید همچنان بدون تغییر کار کند، زیرا make_header همچنان در صورتی که فاصله سفید از قبل در رشته‌های ورودی وجود نداشته باشد، بین بخش‌های ASCII و غیر ASCII فاصله سفید اضافه می‌کند.
email.utils.formataddr() اکنون هنگامی که نام‌های نمایشی غیر ASCII به آن داده شود، کدگذاری انتقال محتوای صحیح را انجام می‌دهد. هر کدی که به رفتار اشکال‌دار پیشین — رفتاری که یونیکد غیر ASCII را در رشته خروجی قالب‌بندی‌شده حفظ می‌کرد — وابسته بود، باید تغییر کند (bpo-1690608).
poplib.POP3.quit() اکنون ممکن است مانند تمام متدهای دیگر poplib خطاهای پروتکل ایجاد کند. کدی که فرض می‌کند quit خطاهای poplib.error_proto ایجاد نمی‌کند، ممکن است در صورتی که یک برنامه‌ی خاص هنگام quit با خطا مواجه شود، نیاز به تغییر داشته باشد (bpo-11291).
آرگومان strict در email.parser.Parser، که از پایتون 2.4 منسوخ شده بود، سرانجام حذف شده است.
متد منسوخ unittest.TestCase.assertSameElements حذف شده است.
متغیر منسوخ time.accept2dyear حذف شده است.
ویژگی منسوخ Context._clamp از ماژول decimal حذف شده است. این ویژگی پیش‌تر با ویژگی عمومی clamp جایگزین شده بود. (به bpo-8540 مراجعه کنید.)
کلاس کمکی داخلیِ مستندنشده SSLFakeFile از smtplib حذف شده است، زیرا کارکرد آن مدت‌هاست که مستقیماً توسط socket.socket.makefile() فراهم شده است.
ارسال مقدار منفی به time.sleep() در ویندوز اکنون به جای توقف برای همیشه، خطا ایجاد می‌کند. در posix همیشه خطا ایجاد می‌شده است.
ثابت ast.__version__ حذف شده است. اگر نیاز دارید تصمیم‌هایی بگیرید که تحت تأثیر نسخه‌ی AST هستند، برای گرفتن این تصمیم از sys.version_info استفاده کنید.
کدی که برای دور زدن این واقعیت که ماژول threading از توابع کارخانه‌ای استفاده می‌کرد، از کلاس‌های خصوصی زیرکلاس می‌ساخت، باید تغییر کند تا از کلاس‌هایی که اکنون عمومی هستند زیرکلاس بسازد.
سازوکار اشکال‌زدایی غیرمستند در ماژول threading حذف شده است که باعث ساده‌تر شدن کد می‌شود. این نباید تأثیری بر کد تولیدی داشته باشد، اما به این دلیل در اینجا ذکر شده است که ممکن است چارچوب‌های اشکال‌زدایی برنامه با آن تعامل داشته باشند (bpo-13550).

انتقال کد C¶

در جریان تغییرات API بافر، عضو مستندنشده‌ی smalltable از ساختار Py_buffer حذف شده است و چیدمان PyMemoryViewObject تغییر کرده است.

همه‌ی ماژول‌های توسعه‌ای که به بخش‌های مربوط در memoryobject.h یا object.h متکی‌اند، باید بازسازی شوند.
به دلیل PEP 393، نوع Py_UNICODE و تمام توابعی که از این نوع استفاده می‌کنند منسوخ شده‌اند (اما دست‌کم به مدت پنج سال در دسترس باقی خواهند ماند). اگر از APIهای یونیکد سطح پایین برای ساخت اشیاء یونیکد و دسترسی به آن‌ها استفاده می‌کردید و می‌خواهید از کاهشی که PEP 393 در ردپای حافظه فراهم کرده است بهره‌مند شوید، باید کد خود را به API یونیکد جدید تبدیل کنید.

با این حال، اگر تنها از توابع سطح بالا مانند PyUnicode_Concat()، PyUnicode_Join() یا PyUnicode_FromFormat() استفاده کرده باشید، کد شما به‌طور خودکار از بازنمایی‌های جدید یونیکد بهره‌مند خواهد شد.
PyImport_GetMagicNumber() اکنون در صورت شکست -1 برمی‌گرداند.
از آنجا که مقدار منفی برای آرگومان level در __import__() دیگر معتبر نیست، همین امر اکنون برای PyImport_ImportModuleLevel() نیز صدق می‌کند. این همچنین بدان معناست که مقدار level استفاده‌شده توسط PyImport_ImportModuleEx() اکنون 0 است، نه -1.

ساخت ماژول‌های توسعه‌ای C¶

دامنه‌ی نام‌های پرونده‌ی ممکن برای ماژول‌های توسعه‌ای C محدودتر شده است. املاء‌های بسیار کم‌استفاده حذف شده‌اند: در POSIX، پرونده‌هایی با نام‌های xxxmodule.so، xxxmodule.abi3.so و xxxmodule.cpython-*.so دیگر به‌عنوان پیاده‌کننده‌ی ماژول xxx تشخیص داده نمی‌شوند. اگر شما چنین پرونده‌هایی را تولید می‌کردید، باید به املاء‌های دیگر تغییر دهید (یعنی رشته‌ی module را از نام‌های پرونده حذف کنید).

(پیاده‌سازی‌شده در bpo-14040.)

تغییرات سوییچ‌های خط فرمان¶

پرچم (flag) خط فرمان -Q و موارد مرتبط با آن حذف شده‌اند. کدی که sys.flags.division_warning را بررسی می‌کند، باید به‌روزرسانی شود.

(bpo-10998، با همکاری Éric Araujo.)
وقتی python با گزینه‌ی -S اجرا می‌شود، import site دیگر مسیرهای خاص سایت را به مسیرهای جستجوی ماژول اضافه نمی‌کند. در نسخه‌های قبلی، این کار انجام می‌شد.

(bpo-11591، با مشارکت Carl Meyer و ویرایش‌هایی از Éric Araujo.)

© حق نشر 2001 Python Software Foundation.
این صفحه تحت مجوز بنیاد نرم‌افزار پایتون نسخه ۲ منتشر شده است.
مثال‌ها، دستورالعمل‌ها، و سایر کدهای موجود در مستندات همچنین تحت مجوز بدون بند BSD منتشر شده‌اند.
برای اطلاعات بیشتر به تاریخچه و مجوز مراجعه کنید.

بنیاد نرم‌افزار پایتون یک شرکت غیرانتفاعی است. لطفاً کمک مالی کنید.

آخرین به‌روزرسانی در نوامبر 12, 2026 (06:19 UTC). آیا اشکالی یافتید؟
ساخته شده با Sphinx 9.1.0.

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.