تازههای پایتون 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بازنویسی شد.رشتههای یونیکد فشردهتر.
دیکشنریهای ویژگی فشردهتر.
ماژولهای کتابخانهای بهطور چشمگیر بهبودیافته:
بهبودهای امنیتی:
تصادفیسازی هش بهصورت پیشفرض فعال است.
لطفاً برای فهرست جامع تغییرات رو به کاربر، به خواندن ادامه دهید.
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.)
قفل ایمپورت با دانهبندی ریزتر¶
نسخههای قبلی سیپایتون همیشه به یک قفل سراسری ایمپورت تکیه داشتهاند. این امر به مزاحمتهای غیرمنتظرهای منجر میشد، مانند بنبستها در مواردی که ایمپورت کردن یک ماژول، بهعنوان یک اثر جانبی، اجرای کد را در نخ دیگری فعال میکرد. گاهی راهحلهای ناشیانهای به کار گرفته میشد، مانند تابع PyImport_ImportModuleNoBlock() در C API.
در پایتون 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اکنون تمام APIio.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 برمیگرداند.
کدگذارهای افزایشی کدکهای 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.' را به دست میدهد.
کدک 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)، بهدرستی کار کند.
crypt¶
افزودن نمک و قالب کریپت ماژولار (modular crypt format) (روش هش) و تابع mksalt() به ماژول crypt.
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 بسته به معماری ماشین، کرانهای زمینهی زیر را دارد:
در قالبهای زمینه (
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 |
حداکثر طولی که سطرهای منفرد میتوانند هنگام سریالسازی یک |
linesep |
نویسهای که هنگام سریالسازی یک |
cte_type |
|
raise_on_defect |
باعث میشود یک |
یک نمونهی جدید سیاست، همراه با تنظیمات جدید، با استفاده از متد 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 |
کنترل میکند که سرآیندهای تجزیهشده بهوسیلهی |
header_factory |
فراخوانیپذیری که |
header_factory کلید قابلیتهای جدیدی است که سیاستهای جدید فراهم میکنند. هنگامی که یکی از سیاستهای جدید استفاده میشود، هر سرآیندی که از یک شیء Message بازیابی میشود، شیئی است که توسط header_factory تولید شده است، و هرگاه سرآیندی را روی یک Message تنظیم کنید، به شیئی تبدیل میشود که توسط header_factory تولید شده است. همهی این اشیاء سرآیند ویژگی name دارند که برابر با نام سرآیند است. سرآیندهای Address و Date ویژگیهای اضافی دارند که به شما امکان میدهند به دادههای تجزیهشدهی سرآیند دسترسی داشته باشید. این بدان معناست که اکنون میتوانید کارهایی مانند این انجام دهید:
>>> m = Message(policy=SMTP)
>>> m['To'] = 'Éric <foo@example.com>'
>>> m['to']
'Éric <foo@example.com>'
>>> 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?= <foo@example.com>
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='bonz@laugh.com')]
>>> print(m)
To: =?utf-8?q?=C3=89ric?= <foo@example.com>
Date: Fri, 25 May 2012 21:44:27 -0400
cc: pals: Bob <bob@example.com>, Sally <sally@example.com>;, Bonzo <bonz@laugh.com>
کدگشایی به یونیکد بهطور خودکار انجام میشود:
>>> m2 = message_from_string(str(m))
>>> m2['to']
'Éric <foo@example.com>'
هنگامی که یک پیام را پارس میکنید، میتوانید از ویژگیهای 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'))
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:
PEP 393 نوعهای جدید یونیکد، ماکروها و توابع را افزود:
API سطح بالا:
API سطح پایین:
ساختارهای
PyASCIIObjectوPyCompactUnicodeObjectPyUnicode_DATA,PyUnicode_1BYTE_DATA,PyUnicode_2BYTE_DATA,PyUnicode_4BYTE_DATAPyUnicode_KINDبه همراه enumPyUnicode_Kind:PyUnicode_WCHAR_KIND،PyUnicode_1BYTE_KIND،PyUnicode_2BYTE_KIND،PyUnicode_4BYTE_KIND
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.)