GeezerVison is showing python.github.io — تازههای پایتون 3.10
تازههای پایتون 3.10¶
- ویرایشگر:
Pablo Galindo Salgado
این مقاله قابلیتهای جدید پایتون 3.10 را در مقایسه با 3.9 توضیح میدهد. پایتون 3.10 در ۴ اکتبر ۲۰۲۱ منتشر شد. برای جزئیات کامل، به فهرست تغییرات مراجعه کنید.
خلاصه -- نکات برجستهی انتشار¶
ویژگیهای جدید سینتکس:
PEP 634، تطبیق الگوی ساختاری: مشخصات
PEP 635، تطبیق الگوی ساختاری: انگیزه و منطق
PEP 636، تطبیق الگوی ساختاری: آموزش
bpo-12782، مدیرهای زمینهی پرانتزگذاریشده اکنون بهطور رسمی مجاز.
قابلیتهای جدید در کتابخانه استاندارد:
بهبودهای مفسر:
قابلیتهای جدید typing:
PEP 604، اجازهی نوشتن نوعهای اجتماعی بهصورت X | Y
PEP 612، متغیرهای مشخصه پارامتر
PEP 613، مستعارهای صریح نوع
PEP 647، نگهبانهای نوع تعریفشده توسط کاربر
منسوخسازیها، حذفها یا محدودیتهای مهم:
PEP 644، نیازمند OpenSSL 1.1.1 یا جدیدتر
PEP 632، منسوخ کردن ماژول distutils.
PEP 623، منسوخسازی و آمادهسازی برای حذف عضو wstr در PyUnicodeObject.
PEP 624، حذف APIهای کدگذار Py_UNICODE
PEP 597، افزودن EncodingWarning اختیاری
ویژگیهای جدید¶
مدیران زمینه درون پرانتز¶
استفاده از پرانتزهای دربرگیرنده برای ادامه در چند سطر در مدیرهای زمینه اکنون پشتیبانی میشود. این امکان را فراهم میکند تا مجموعهای طولانی از مدیرهای زمینه را در چند سطر، به شکلی مشابه آنچه پیشتر با دستورهای ایمپورت امکانپذیر بود، قالببندی کنید. برای نمونه، همهی این مثالها اکنون معتبر هستند:
with (CtxManager() as example):
...
with (
CtxManager1(),
CtxManager2()
):
...
with (CtxManager1() as example,
CtxManager2()):
...
with (CtxManager1(),
CtxManager2() as example):
...
with (
CtxManager1() as example1,
CtxManager2() as example2
):
...
همچنین میتوان در انتهای گروه محصورشده از یک کامای انتهایی استفاده کرد:
with (
CtxManager1() as example1,
CtxManager2() as example2,
CtxManager3() as example3,
):
...
این سینتکس جدید از قابلیتهای غیر LL(1) پارسر جدید استفاده میکند. برای جزئیات بیشتر به PEP 617 مراجعه کنید.
(مشارکتشده توسط Guido van Rossum، Pablo Galindo و Lysandros Nikolaou در bpo-12782 و bpo-40334.)
پیامهای خطای بهتر¶
SyntaxErrors¶
هنگام تجزیهی کدی که شامل پرانتزها یا براکتهای بستهنشده است، مفسر اکنون بهجای نمایش SyntaxError: unexpected EOF while parsing یا اشاره به مکانی نادرست، مکان براکت یا پرانتز بستهنشده را در بر میگیرد. برای مثال، کد زیر را در نظر بگیرید (توجه کنید که '{' بستهنشده است):
expected = {9: 1, 18: 2, 19: 2, 27: 3, 28: 3, 29: 3, 36: 4, 37: 4,
38: 4, 39: 4, 45: 5, 46: 5, 47: 5, 48: 5, 49: 5, 54: 6,
some_other_code = foo()
نسخههای قبلی مفسر، مکانهای گیجکنندهای را بهعنوان محل خطای نحوی گزارش میکردند:
File "example.py", line 3
some_other_code = foo()
^
SyntaxError: invalid syntax
اما در پایتون 3.10 خطای گویاتری نشان داده میشود:
File "example.py", line 1
expected = {9: 1, 18: 2, 19: 2, 27: 3, 28: 3, 29: 3, 36: 4, 37: 4,
^
SyntaxError: '{' was never closed
به شکلی مشابه، خطاهای مربوط به رشتههای لفظی بستهنشده (تکنقلقولی و سهنقلقولی) اکنون بهجای گزارش EOF/EOL، به ابتدای رشته اشاره میکنند.
این بهبودها از کارهای پیشین در مفسر PyPy الهام گرفتهاند.
(مشارکتشده توسط Pablo Galindo در bpo-42864 و Batuhan Taskaya در bpo-40176.)
استثناهای SyntaxError که توسط مفسر ایجاد میشوند، اکنون محدودهی کامل خطای عبارتی را که خودِ خطای سینتکس را تشکیل میدهد برجسته میکنند، نه فقط جایی که مشکل شناسایی میشود. به این ترتیب، به جای نمایش (پیش از پایتون 3.10):
>>> foo(x, z for z in range(10), t, w)
File "<stdin>", line 1
foo(x, z for z in range(10), t, w)
^
SyntaxError: Generator expression must be parenthesized
اکنون پایتون 3.10 این استثنا را به این صورت نمایش میدهد:
>>> foo(x, z for z in range(10), t, w)
File "<stdin>", line 1
foo(x, z for z in range(10), t, w)
^^^^^^^^^^^^^^^^^^^^
SyntaxError: Generator expression must be parenthesized
این بهبود توسط پابلو گالیندو در bpo-43914 ارائه شد.
تعداد قابل توجهی پیام تخصصی جدید برای استثناهای SyntaxError گنجانده شده است. برخی از قابل توجهترین آنها عبارتاند از:
: پیش از بلوکها وجود ندارد:
>>> if rocket.position > event_horizon
File "<stdin>", line 1
if rocket.position > event_horizon
^
SyntaxError: expected ':'
(مشارکت پابلو گالیندو در bpo-42997.)
تاپلهای بدون پرانتز در اهداف درکها:
>>> {x,y for x,y in zip('abcd', '1234')}
File "<stdin>", line 1
{x,y for x,y in zip('abcd', '1234')}
^
SyntaxError: did you forget parentheses around the comprehension target?
(مشارکتشده توسط Pablo Galindo در bpo-43017.)
کاماهای جاافتاده در مقادیر لفظی کالکشن و بین عبارتها:
>>> items = {
... x: 1,
... y: 2
... z: 3,
File "<stdin>", line 3
y: 2
^
SyntaxError: invalid syntax. Perhaps you forgot a comma?
(مشارکتشده توسط پابلو گالیندو در bpo-43822.)
چندین نوع استثنا بدون پرانتز:
>>> try:
... build_dyson_sphere()
... except NotEnoughScienceError, NotEnoughResourcesError:
File "<stdin>", line 3
except NotEnoughScienceError, NotEnoughResourcesError:
^
SyntaxError: multiple exception types must be parenthesized
(مشارکتشده توسط Pablo Galindo در bpo-43149.)
نبود : و مقادیر در لفظیهای دیکشنری:
>>> values = {
... x: 1,
... y: 2,
... z:
... }
File "<stdin>", line 4
z:
^
SyntaxError: expression expected after dictionary key and ':'
>>> values = {x:1, y:2, z w:3}
File "<stdin>", line 1
values = {x:1, y:2, z w:3}
^
SyntaxError: ':' expected after dictionary key
(با مشارکت پابلو گالیندو در bpo-43823.)
بلوکهای try بدون بلوکهای except یا finally:
>>> try:
... x = 2
... something = 3
File "<stdin>", line 3
something = 3
^^^^^^^^^
SyntaxError: expected 'except' or 'finally' block
(مشارکتشده توسط پابلو گالیندو در bpo-44305.)
استفاده از = بهجای == در مقایسهها:
>>> if rocket.position = event_horizon:
File "<stdin>", line 1
if rocket.position = event_horizon:
^
SyntaxError: cannot assign to attribute here. Maybe you meant '==' instead of '='?
(مشارکتشده توسط پابلو گالیندو در bpo-43797.)
کاربرد * در افاسترینگها:
>>> f"Black holes {*all_black_holes} and revelations"
File "<stdin>", line 1
(*all_black_holes)
^
SyntaxError: f-string: cannot use starred expression here
(مشارکتشده توسط پابلو گالیندو در bpo-41064.)
IndentationErrors¶
بسیاری از استثناهای IndentationError اکنون زمینه بیشتری دربارهی اینکه چه نوع بلوکی در انتظار تورفتگی بوده است، از جمله محل دستور، ارائه میدهند:
>>> def foo():
... if lel:
... x = 2
File "<stdin>", line 3
x = 2
^
IndentationError: expected an indented block after 'if' statement in line 2
AttributeErrors¶
هنگام چاپ AttributeError، PyErr_Display() پیشنهادهایی از نامهای ویژگی مشابه در شیءای که استثنا از آن پرتاب شده است ارائه میدهد:
>>> collections.namedtoplo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'collections' has no attribute 'namedtoplo'. Did you mean: namedtuple?
(مشارکتشده توسط Pablo Galindo در bpo-38530.)
هشدار
توجه داشته باشید که اگر PyErr_Display() برای نمایش خطا فراخوانی نشود، این کار نخواهد کرد؛ این وضعیت میتواند زمانی رخ دهد که تابع سفارشی دیگری برای نمایش خطا استفاده شده باشد. این یک سناریوی رایج در برخی REPLها مانند IPython است.
NameErrors¶
هنگام چاپ NameError برخاسته توسط مفسر، PyErr_Display() پیشنهادهایی از نامهای متغیر مشابه در تابعی که استثنا از آن برخاسته است ارائه میدهد:
>>> schwarzschild_black_hole = None
>>> schwarschild_black_hole
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'schwarschild_black_hole' is not defined. Did you mean: schwarzschild_black_hole?
(مشارکتشده توسط Pablo Galindo در bpo-38530.)
هشدار
توجه کنید که اگر PyErr_Display() برای نمایش خطا فراخوانی نشود، این کار نخواهد کرد؛ این وضعیت میتواند زمانی رخ دهد که از تابع سفارشی دیگری برای نمایش خطا استفاده شود. این یک سناریوی رایج در برخی REPLها مانند IPython است.
PEP 626: شمارههای دقیق سطر برای اشکالزدایی و ابزارهای دیگر¶
PEP 626 شمارههای سطر دقیقتر و قابلاعتمادتری را برای اشکالزدایی، پروفایلگیری و ابزارهای پوشش به ارمغان میآورد. رویدادهای ردگیری، بههمراه شماره سطر صحیح، برای تمام سطرهای کد اجراشده و تنها برای سطرهایی از کد که اجرا میشوند تولید میشوند.
ویژگی f_lineno در اشیاء فریم همیشه شماره سطر مورد انتظار را در بر خواهد گرفت.
ویژگی codeobject.co_lnotab از اشیای کد منسوخ شده است و در نسخهی 3.12 حذف خواهد شد. کدهایی که نیاز دارند آفست را به شماره سطر تبدیل کنند، باید به جای آن از روش co_lines() استفاده کنند.
PEP 634: تطبیق الگوی ساختاری¶
تطبیق الگوی ساختاری به شکل دستور match و دستورهای case شامل الگوهایی به همراه کنشهای مرتبط افزوده شده است. الگوها از دنبالهها، نگاشتها، نوعهای دادهای اولیه و همچنین نمونههای کلاس تشکیل میشوند. تطبیق الگو به برنامهها امکان میدهد از نوعهای دادهای پیچیده اطلاعات استخراج کنند، بر پایه ساختار داده انشعاب کنند و بر اساس شکلهای مختلف داده کنشهای مشخصی را اعمال کنند.
سینتکس و عملیات¶
سینتکس کلی تطبیق الگو چنین است:
match subject:
case <pattern_1>:
<action_1>
case <pattern_2>:
<action_2>
case <pattern_3>:
<action_3>
case _:
<action_wildcard>
دستور match یک عبارت را میگیرد و مقدار آن را با الگوهای متوالی که بهصورت یک یا چند بلوک case ارائه شدهاند مقایسه میکند. بهطور خاص، تطبیق الگو به این صورت عمل میکند:
با استفاده از دادههایی با نوع و شکل (subject)
ارزیابی subject در دستور match
مقایسهی موضوع (subject) با هر الگو در دستور case از بالا به پایین تا زمانی که یک تطبیق تأیید شود.
اجرای اکشن مرتبط با الگوی تطبیق تأییدشده
اگر تطبیق دقیقی تأیید نشود، آخرین case، یعنی وایلدکارد _، در صورت وجود، بهعنوان case تطبیقی استفاده خواهد شد. اگر تطبیق دقیقی تأیید نشود و case وایلدکاردی وجود نداشته باشد، کل بلوک match یک عملیات بیاثر خواهد بود.
رویکرد اعلانی¶
ممکن است خوانندگان با تطبیق الگو از طریق مثال سادهی تطبیق یک موضوع (شیء داده) با یک مقدار لفظی (الگو) بهوسیلهی دستور switch موجود در C، جاوا یا جاوااسکریپت (و بسیاری از زبانهای دیگر) آشنا باشند. اغلب دستور switch برای مقایسهی یک شیء/عبارت با دستورهای case حاوی مقادیر لفظی استفاده میشود.
نمونههای قدرتمندتر تطبیق الگو را میتوان در زبانهایی مانند Scala و Elixir یافت. با تطبیق الگوی ساختاری، رویکرد «اعلانی» است و شرایط (الگوها) را که دادهها باید با آنها تطبیق یابند، بهصراحت بیان میکند.
در حالی که میتوان با یک مجموعهی «دستوری» از دستورالعملها که از دستورهای «if» تودرتو استفاده میکنند، کاری مشابه تطبیق الگوی ساختاری انجام داد، این روش نسبت به رویکرد «اعلانی» وضوح کمتری دارد. در عوض، رویکرد «اعلانی» شرایطی را که باید برای یک تطبیق برآورده شوند بیان میکند و از طریق الگوهای صریحش خواناتر است. در حالی که تطبیق الگوی ساختاری در سادهترین شکل خود میتواند در یک دستور case یک متغیر را با یک مقدار لفظی مقایسه کند، ارزش واقعی آن برای پایتون در نحوهی برخوردش با نوع و شکل موضوع نهفته است.
الگوی ساده: تطبیق با یک مقدار لفظی¶
بیایید این مثال را بهعنوان تطبیق الگو در سادهترین شکل آن بررسی کنیم: یک مقدار، یعنی موضوع، که با چندین مقدار لفظی، یعنی الگوها، تطبیق داده میشود. در مثال زیر، status موضوعی دستور match است. الگوها هر یک از دستورهای case هستند که در آنها مقادیر لفظی کدهای وضعیت درخواست را نمایندگی میکنند. کنش مرتبط با case پس از تطبیق اجرا میشود:
def http_error(status):
match status:
case 400:
return "Bad request"
case 404:
return "Not found"
case 418:
return "I'm a teapot"
case _:
return "Something's wrong with the internet"
اگر مقدار 418 بهعنوان status به تابع فوق پاس داده شود، "I'm a teapot" بازگردانده میشود. اگر مقدار 500 بهعنوان status به تابع فوق پاس داده شود، دستور case با _ بهعنوان وایلدکارد تطبیق خواهد یافت و "Something's wrong with the internet" بازگردانده میشود. به آخرین بلوک توجه کنید: نام متغیر _ نقش وایلدکارد را ایفا میکند و تضمین میکند که موضوع همیشه تطبیق خواهد یافت. استفاده از _ اختیاری است.
میتوانید چندین مقدار لفظی را با استفاده از | («یا») در یک الگوی واحد ترکیب کنید:
case 401 | 403 | 404:
return "Not allowed"
رفتار بدون وایلدکارد¶
اگر مثال بالا را با حذف آخرین بلوک case تغییر دهیم، مثال به شکل زیر درمیآید:
def http_error(status):
match status:
case 400:
return "Bad request"
case 404:
return "Not found"
case 418:
return "I'm a teapot"
بدون استفاده از _ در دستور case، ممکن است هیچ تطبیقی وجود نداشته باشد. اگر هیچ تطبیقی وجود نداشته باشد، رفتار، یک عملیات بیاثر است. برای مثال، اگر status با مقدار 500 ارسال شود، یک عملیات بیاثر رخ میدهد.
الگوهای دارای مقدار لفظی و متغیر¶
الگوها میتوانند شبیه انتسابهای واگشایی باشند و از یک الگو میتوان برای مقید کردن متغیرها استفاده کرد. در این مثال، یک نقطه داده میتواند به مختصه x و مختصه y خود واگشایی شود:
# point is an (x, y) tuple
match point:
case (0, 0):
print("Origin")
case (0, y):
print(f"Y={y}")
case (x, 0):
print(f"X={x}")
case (x, y):
print(f"X={x}, Y={y}")
case _:
raise ValueError("Not a point")
الگوی اول دو مقدار لفظی دارد، (0, 0)، و میتوان آن را توسعهای از الگوی لفظی که در بالا نمایش داده شد در نظر گرفت. دو الگوی بعدی یک مقدار لفظی و یک متغیر را ترکیب میکنند و متغیر، مقداری از موضوع (point) را مقید میکند. الگوی چهارم دو مقدار را ثبت میکند، که این امر آن را از نظر مفهومی مشابه انتساب واگشایی (x, y) = point میسازد.
الگوها و کلاسها¶
اگر از کلاسها برای ساختاردهی دادههای خود استفاده میکنید، میتوانید از نام کلاس به همراه فهرستی از آرگومانها که شبیه به سازنده است، بهعنوان الگو استفاده کنید. این الگو توانایی ثبت ویژگیهای نمونه در متغیرها را دارد:
class Point:
def __init__(self, x, y):
self.x = x
self.y = y
def location(point):
match point:
case Point(x=0, y=0):
print("Origin is the point's location.")
case Point(x=0, y=y):
print(f"Y={y} and the point is on the y-axis.")
case Point(x=x, y=0):
print(f"X={x} and the point is on the x-axis.")
case Point():
print("The point is located somewhere else on the plane.")
case _:
print("Not a point")
الگوها با پارامترهای جایگاهی¶
شما میتوانید از پارامترهای جایگاهی با برخی از کلاسهای توکاری که ترتیبی برای ویژگیهایشان فراهم میکنند، استفاده کنید (مثلاً دیتاکلاسها). همچنین میتوانید با تنظیم ویژگی ویژه __match_args__ در کلاسهایتان، موقعیت مشخصی برای ویژگیها در الگوها تعریف کنید. اگر مقدار آن به ("x", "y") تنظیم شده باشد، الگوهای زیر همگی معادلاند (و همگی ویژگی y را به متغیر var مقید میکنند):
Point(1, var)
Point(1, y=var)
Point(x=1, y=var)
Point(y=var, x=1)
الگوهای تودرتو¶
الگوها میتوانند بهطور دلخواه تودرتو شوند. برای مثال، اگر دادههای ما فهرست کوتاهی از نقاط باشد، میتوان آن را به این شکل تطبیق داد:
match points:
case []:
print("No points in the list.")
case [Point(0, 0)]:
print("The origin is the only point in the list.")
case [Point(x, y)]:
print(f"A single point {x}, {y} is in the list.")
case [Point(0, y1), Point(0, y2)]:
print(f"Two points on the Y axis at {y1}, {y2} are in the list.")
case _:
print("Something else is found in the list.")
الگوهای پیچیده و وایلدکارد¶
تا اینجا، مثالها از _ بهتنهایی در آخرین دستور case استفاده کردهاند. میتوان از وایلدکارد در الگوهای پیچیدهتری مانند ('error', code, _) استفاده کرد. برای مثال:
match test_variable:
case ('warning', code, 40):
print("A warning has been received.")
case ('error', code, _):
print(f"An error {code} occurred.")
در حالت بالا، test_variable برای ('error', code, 100) و ('error', code, 800) تطبیق خواهد داشت.
نگهبان¶
میتوانیم یک بند if به الگو اضافه کنیم که به آن «نگهبان» گفته میشود. اگر نگهبان نادرست باشد، match به سراغ امتحان بلوک case بعدی میرود. توجه داشته باشید که ثبت مقدار پیش از ارزیابی نگهبان انجام میشود:
match point:
case Point(x, y) if x == y:
print(f"The point is located on the diagonal Y=X at {x}.")
case Point(x, y):
print(f"Point is not on the diagonal.")
ویژگیهای کلیدی دیگر¶
چندین ویژگی کلیدی دیگر:
مانند انتسابهای واگشایی، الگوهای تاپل و فهرست دقیقاً معنای یکسانی دارند و در واقع با دنبالههای دلخواه تطبیق میکنند. از نظر فنی، موضوع باید یک دنباله باشد. بنابراین، یک استثنای مهم این است که الگوها با پیمایشگرها تطبیق نمیکنند. همچنین، برای جلوگیری از یک اشتباه رایج، الگوهای دنباله با رشتهها تطبیق نمیکنند.
الگوهای دنباله از وایلدکارد پشتیبانی میکنند: [x, y, *rest] و (x, y, *rest) مانند وایلدکاردها در انتسابهای واگشایی کار میکنند. نام پس از * میتواند _ نیز باشد، بنابراین (x, y, *_) با دنبالهای از حداقل دو آیتم بدون مقید کردن آیتمهای باقیمانده تطبیق میکند.
الگوهای نگاشت: {"bandwidth": b, "latency": l} مقادیر "bandwidth" و "latency" را از یک دیکشنری ثبت میکند. برخلاف الگوهای دنباله، کلیدهای اضافی نادیده گرفته میشوند. وایلدکارد **rest نیز پشتیبانی میشود. (اما **_ زائد خواهد بود، بنابراین مجاز نیست.)
زیرالگوها را میتوان با استفاده از کلیدواژهی as ثبت کرد:
case (Point(x1, y1), Point(x2, y2) as p2): ...
این، x1، y1، x2 و y2 را همانطور که بدون بند as انتظار دارید مقید میکند و p2 را به تمام آیتم دومِ موضوع مقید میکند.
بیشتر مقادیر لفظی بر اساس تساوی مقایسه میشوند. با این حال، تکنمونههای True، False و None بر اساس هویت مقایسه میشوند.
میتوان از ثابتهای نامدار در الگوها استفاده کرد. این ثابتهای نامدار باید نامهای نقطهدار باشند تا از تفسیر شدن ثابت بهعنوان متغیر ثبتکننده جلوگیری شود:
from enum import Enum
class Color(Enum):
RED = 0
GREEN = 1
BLUE = 2
color = Color.GREEN
match color:
case Color.RED:
print("I see red!")
case Color.GREEN:
print("Grass is green")
case Color.BLUE:
print("I'm feeling the blues :(")
برای مشخصات کامل به PEP 634 مراجعه کنید. انگیزه و منطق آن در PEP 635 و آموزش مفصلتری در PEP 636 آمده است.
گزینهی اختیاری EncodingWarning و encoding="locale"¶
کدگذاری پیشفرض TextIOWrapper و open() به پلتفرم و locale وابسته است. از آنجا که در بیشتر پلتفرمهای یونیکس از UTF-8 استفاده میشود، حذف گزینهی encoding هنگام باز کردن پروندههای UTF-8 (مثلاً JSON، YAML، TOML، Markdown) اشکال بسیار رایجی است. برای مثال:
# BUG: "rb" mode or encoding="utf-8" should be used.
with open("data.json") as f:
data = json.load(f)
برای یافتن این نوع اشکال، یک EncodingWarning اختیاری اضافه شده است. این هشدار زمانی نشان داده میشود که sys.flags.warn_default_encoding برابر با true باشد و از کدگذاری پیشفرض وابسته به locale استفاده شود.
گزینهی -X warn_default_encoding و PYTHONWARNDEFAULTENCODING برای فعالسازی هشدار افزوده شدهاند.
برای اطلاعات بیشتر به کدگذاری متن مراجعه کنید.
ویژگیهای جدید مرتبط با راهنماهای نوع¶
این بخش تغییرات عمدهای را پوشش میدهد که بر راهنماهای نوع PEP 484 و ماژول typing تأثیر میگذارند.
PEP 604: عملگر جدید اجتماع نوع¶
یک عملگر جدید برای اجتماع نوعها معرفی شد که سینتکس X | Y را ممکن میسازد. این کار راهی تمیزتر برای بیان «نوع X یا نوع Y» بهجای استفاده از typing.Union فراهم میکند، بهویژه در راهنماهای نوع.
در نسخههای قبلی پایتون، برای اعمال راهنمای نوع به توابعی که آرگومانهایی از چندین نوع میپذیرند، از typing.Union استفاده میشد:
def square(number: Union[int, float]) -> Union[int, float]:
return number ** 2
اکنون میتوان راهنماهای نوع را به شیوهای موجزتر نوشت:
def square(number: int | float) -> int | float:
return number ** 2
این سینتکس جدید همچنین به عنوان آرگومان دوم برای isinstance() و issubclass() پذیرفته میشود:
>>> isinstance(1, int | str)
True
برای جزئیات بیشتر به نوع اجتماعی (Union Type) و PEP 604 مراجعه کنید.
(با مشارکت Maggie Moss و Philippe Prados در bpo-41428، و با افزودههای Yurii Karabas و Serhiy Storchaka در bpo-44490.)
PEP 612: متغیرهای مشخصات پارامتر¶
دو گزینه جدید برای بهبود اطلاعاتی که برای Callable مربوط به PEP 484 به بررسیگرهای نوع ایستا ارائه میشود، به ماژول typing اضافه شدهاند.
اولی، متغیر مشخصه پارامتر است. از این متغیرها برای انتقال انواع پارامترهای یک فراخوانیپذیر به فراخوانیپذیر دیگر استفاده میشود -- الگویی که بهطور رایج در توابع مرتبه بالاتر و دکوراتورها دیده میشود. نمونههایی از کاربرد را میتوان در typing.ParamSpec یافت. پیش از این، هیچ راه آسانی برای حاشیهنویسی نوع وابستگی انواع پارامترها با چنین دقتی وجود نداشت.
گزینه دوم، عملگر جدید Concatenate است. این عملگر همراه با متغیرهای مشخصه پارامتر، برای حاشیهنویسی نوع یک فراخوانیپذیر مرتبه بالا که پارامترهای فراخوانیپذیر دیگری را اضافه یا حذف میکند، به کار میرود. نمونههایی از کاربرد آن را میتوان در typing.Concatenate یافت.
برای جزئیات بیشتر به typing.Callable، typing.ParamSpec، typing.Concatenate، typing.ParamSpecArgs، typing.ParamSpecKwargs و PEP 612 مراجعه کنید.
(مشارکتشده توسط کن جین در bpo-41559، با بهبودهای جزئی از سوی یله زیلسترا در bpo-43783. PEP نوشتهشده توسط مارک مندوزا.)
PEP 613: TypeAlias¶
PEP 484 مفهوم مستعارهای نوع را معرفی کرد که تنها لازم بود آنها انتسابهای بدون حاشیهنویسی در سطح بالا باشند. این سادگی گاهی تشخیص مستعارهای نوع از انتسابهای معمولی را برای بررسیگرهای نوع دشوار میکرد، بهویژه هنگامی که ارجاعهای پیشرو یا نوعهای نامعتبر در میان بودند. مقایسه کنید:
StrCache = 'Cache[str]' # a type alias
LOG_PREFIX = 'LOG[DEBUG]' # a module constant
اکنون ماژول typing یک مقدار خاص TypeAlias دارد که به شما اجازه میدهد مستعارهای نوع را بهطور صریحتر اعلان کنید:
StrCache: TypeAlias = 'Cache[str]' # a type alias
LOG_PREFIX = 'LOG[DEBUG]' # a module constant
برای جزئیات بیشتر به PEP 613 مراجعه کنید.
(با مشارکت میخائیل گولوبف در bpo-41923.)
PEP 647: نگهبانهای نوع تعریفشده توسط کاربر¶
TypeGuard برای حاشیهنویسی توابع نگهبان نوع (type guard) و بهبود اطلاعاتی که در حین محدودسازی نوع (type narrowing) به بررسیگرهای نوع ایستا ارائه میشود، به ماژول typing افزوده شده است. برای اطلاعات بیشتر، لطفاً مستندات TypeGuardو PEP 647 را مشاهده کنید.
(ارائهشده توسط Ken Jin و Guido van Rossum در bpo-43766. PEP نوشتهشده توسط Eric Traut.)
سایر تغییرات زبان¶
نوع int متد جدید int.bit_count() دارد که تعداد یکها در گسترش دودویی یک عدد صحیح دادهشده را برمیگرداند؛ این تعداد با نام شمارش جمعیت (population count) نیز شناخته میشود. (مشارکتشده توسط Niklas Fiekas در bpo-29882.)
نماهایی که توسط dict.keys()، dict.values() و dict.items() بازگردانده میشوند، اکنون همگی دارای ویژگی mapping هستند که شیءای از نوع types.MappingProxyType دربرگیرندهی دیکشنری اصلی ارائه میدهد. (مشارکت از Dennis Sweeney در bpo-40890.)
PEP 618: تابع zip() اکنون یک پرچم اختیاری strict دارد که برای الزام به برابر بودن طول همهی پیمایشپذیرها استفاده میشود.
توابع توکار و توسعهای که آرگومانهای عدد صحیح میگیرند، اشیای Decimal و Fraction و سایر اشیایی را که تنها با از دست رفتن اطلاعات قابل تبدیل به اعداد صحیح هستند، دیگر نمیپذیرند (مثلاً اشیایی که متد __int__() را دارند اما متد __index__() را ندارند). (مشارکتشده توسط Serhiy Storchaka در bpo-37999.)
اگر object.__ipow__() مقدار NotImplemented را برگرداند، عملگر همانطور که انتظار میرود، بهدرستی به object.__pow__() و object.__rpow__() بازمیگردد. (با مشارکت Alex Shkop در bpo-38302.)
عبارتهای انتساب اکنون میتوانند بدون پرانتز درون مقادیر لفظی مجموعه و درکهای مجموعه، و همچنین در اندیسهای دنباله (اما نه اسلایسها) استفاده شوند.
توابع دارای ویژگی جدید __builtins__ هستند که هنگام اجرای یک تابع، بهجای جستجو در __globals__['__builtins__']، برای یافتن نمادهای توکار بهکار میرود. این ویژگی در صورت وجود از __globals__["__builtins__"] و در غیر این صورت از توکارهای فعلی مقداردهی اولیه میشود. (ارائهشده توسط مارک شانون در bpo-42990.)
دو تابع توکار جدید -- aiter() و anext() اضافه شدهاند تا بهترتیب همتاهای ناهمگام iter() و next() را فراهم کنند. (مشارکت Joshua Bronson، Daniel Pope و Justin Wang در bpo-31861.)
متدهای ایستا (@staticmethod) و متدهای کلاس (@classmethod) اکنون ویژگیهای متد (__module__، __name__، __qualname__، __doc__، __annotations__) را به ارث میبرند و ویژگی جدید __wrapped__ دارند. علاوه بر این، متدهای ایستا اکنون مانند توابع معمولی فراخوانیپذیرند. (مشارکتشده توسط Victor Stinner در bpo-43682.)
حاشیهنویسی اهداف پیچیده (همهچیز بهجز اهداف simple name تعریفشده توسط PEP 526) با from __future__ import annotations دیگر هیچ اثری در رانتایم ایجاد نمیکنند. (با مشارکت Batuhan Taskaya در bpo-42737.)
اشیای کلاس و ماژول اکنون دیکشنریهای حاشیهنویسی خالی را بهصورت تنبل (lazy) و در صورت نیاز ایجاد میکنند. این دیکشنریهای حاشیهنویسی برای سازگاری با نسخههای پیشین در __dict__ شیء ذخیره میشوند. این امر بهترین شیوهها را برای کار با __annotations__ بهبود میبخشد؛ برای اطلاعات بیشتر، لطفاً به بهترین شیوههای حاشیهنویسی مراجعه کنید. (مشارکتشده توسط لری هستینگز در bpo-43901.)
حاشیهنویسیهایی که از yield، yield from، await یا عبارتهای نامدار تشکیل شدهاند، اکنون به دلیل اثرات جانبیشان تحت from __future__ import annotations ممنوع شدهاند. (مشارکتشده توسط Batuhan Taskaya در bpo-42725.)
استفاده از متغیرهای مقیدنشده، super() و دیگر عبارتهایی که ممکن است پردازش جدول نمادها را تغییر دهند، اکنون بهعنوان حاشیهنویسی تحت from __future__ import annotations بیاثر شده است. (مشارکتشده توسط Batuhan Taskaya در bpo-42725.)
هشهای مقادیر NaN از هر دو نوع float و decimal.Decimal اکنون به هویت شیء وابستهاند. پیشتر، این مقادیر همیشه به 0 هش میشدند، هرچند مقادیر NaN با یکدیگر برابر نیستند. این امر به دلیل برخوردهای هش بیش از حد هنگام ایجاد دیکشنریها و مجموعههای حاوی چندین NaN، میتوانست به رفتار رانتایم درجه دوم منجر شود. (مشارکتشده توسط Raymond Hettinger در bpo-43475.)
هنگام حذف ثابت __debug__، یک SyntaxError (به جای NameError) مطرح خواهد شد. (با مشارکت Donghee Na در bpo-45000.)
استثناهای SyntaxError اکنون ویژگیهای end_lineno و end_offset را دارند. اگر تعیین نشده باشند، None خواهند بود. (مشارکتشده توسط Pablo Galindo در bpo-43914.)
ماژولهای بهبودیافته¶
argparse¶
عبارت گمراهکنندهی «optional arguments» در راهنمای argparse با «options» جایگزین شد. ممکن است برخی آزمونها در صورتی که به تطبیق دقیق خروجی تکیه دارند، نیازمند اصلاح باشند. (مشارکتشده توسط Raymond Hettinger در bpo-9694.)
asynchat, asyncore, smtpd¶
این ماژولها از پایتون 3.6 در مستندات ماژولشان بهعنوان منسوک علامتگذاری شدهاند. اکنون یک DeprecationWarning در زمان ایمپورت به هر سهی این ماژولها اضافه شده است.
bdb¶
افزودن clearBreakpoints() برای بازنشانی همهی نقطههای توقف تنظیمشده. (مشارکتشده توسط Irit Katriel در bpo-24160.)
bisect¶
امکان ارائه یک تابع کلید به APIهای ماژول bisect افزوده شد. (مشارکت Raymond Hettinger در bpo-4356.)
collections.abc¶
__args__ مربوط به عام پارامتریشده برای collections.abc.Callable اکنون با typing.Callable سازگار است. عام collections.abc.Callable اکنون پارامترهای نوع را تختسازی میکند، مشابه کاری که typing.Callable در حال حاضر انجام میدهد. این بدان معناست که collections.abc.Callable[[int, str], str] دارای __args__ برابر با (int, str, str) خواهد بود؛ پیشتر این مقدار ([int, str], str) بود. برای امکانپذیر کردن این تغییر، اکنون میتوان از types.GenericAlias زیرکلاس ساخت و هنگام زیرنویسی نوع collections.abc.Callable، یک زیرکلاس بازگردانده خواهد شد. توجه داشته باشید که ممکن است برای صورتهای نامعتبر پارامتریسازی collections.abc.Callable که ممکن است در پایتون 3.9 بیسروصدا عبور کرده باشند، TypeError مطرح شود. (مشارکتشده توسط کن جین در bpo-42195.)
dataclasses¶
فیلدهای فقط کلیدواژهای¶
dataclasses اکنون از فیلدهایی پشتیبانی میکند که در متد __init__ تولیدشده فقط کلیدواژهای هستند. روشهای متعددی برای مشخص کردن فیلدهای فقط کلیدواژهای وجود دارد.
میتوانید بگویید که هر فیلد فقط کلیدواژهای است:
from dataclasses import dataclass
@dataclass(kw_only=True)
class Birthday:
name: str
birthday: datetime.date
هر دو name و birthday پارامترهای فقطکلیدواژهای متد __init__ تولیدشده هستند.
میتوانید فقط کلیدواژهای بودن را به ازای هر فیلد مشخص کنید:
from dataclasses import dataclass, field
@dataclass
class Birthday:
name: str
birthday: datetime.date = field(kw_only=True)
در اینجا تنها birthday فقط-کلیدواژهای است. اگر kw_only را روی فیلدهای جداگانه تنظیم کنید، آگاه باشید که چون فیلدهای فقط-کلیدواژهای باید پس از فیلدهای غیر فقط-کلیدواژهای قرار بگیرند، قواعدی دربارهی تغییر ترتیب فیلدها وجود دارد. برای جزئیات، به مستندات کامل dataclasses مراجعه کنید.
همچنین میتوانید مشخص کنید که تمام فیلدهای پس از نشانگر KW_ONLY فقط کلیدواژهای باشند. این احتمالاً رایجترین کاربرد خواهد بود:
from dataclasses import dataclass, KW_ONLY
@dataclass
class Point:
x: float
y: float
_: KW_ONLY
z: float = 0.0
t: float = 0.0
در اینجا، z و t پارامترهای فقطکلیدواژهای هستند، در حالی که x و y چنین نیستند. (مشارکتشده توسط Eric V. Smith در bpo-43532.)
distutils¶
کل بستهی distutils منسوخ شده است و در پایتون 3.12 حذف خواهد شد. کارکرد آن برای مشخصکردن ساخت بستهها پیشتر بهطور کامل توسط بستههای شخص ثالث setuptools و packaging جایگزین شده است و بیشتر APIهای پرکاربرد دیگر نیز در جای دیگری از کتابخانه استاندارد در دسترس هستند (مانند platform، shutil، subprocess یا sysconfig). هیچ برنامهای برای انتقال کارکردهای دیگر از distutils وجود ندارد و برنامههایی که از توابع دیگر استفاده میکنند باید برای تهیهی رونوشتهای خصوصی از کد برنامهریزی کنند. برای بحث به PEP 632 مراجعه کنید.
فرمان bdist_wininst که در پایتون 3.8 منسوخ شده بود، حذف شد. فرمان bdist_wheel اکنون برای توزیع بستههای دودویی در ویندوز توصیه میشود. (مشارکتشده توسط Victor Stinner در bpo-42802.)
doctest¶
هنگامی که یک ماژول __loader__ را تعریف نمیکند، به __spec__.loader بازمیگردد. (مشارکتشده توسط Brett Cannon در bpo-42133.)
enum¶
__repr__() کلاس Enum اکنون enum_name.member_name را برمیگرداند و __str__() اکنون member_name را برمیگرداند. enumهای کتابخانه استاندارد که بهصورت ثابتهای ماژول در دسترساند، repr`ی برابر با ``module_name.member_name`() دارند. (مشارکتشده توسط Ethan Furman در bpo-40066.)
افزودن enum.StrEnum برای enumهایی که همهی اعضای آنها رشته هستند. (مشارکتشده توسط Ethan Furman در bpo-41816.)
faulthandler¶
ماژول faulthandler اکنون تشخیص میدهد که آیا خطای مهلکی در حین زبالهروبی رخ داده است. (مشارکتشده توسط Victor Stinner در bpo-44466.)
glob¶
افزودن پارامترهای root_dir و dir_fd به glob() و iglob() که امکان تعیین پوشه ریشه برای جستجو را فراهم میکنند. (مشارکت Serhiy Storchaka در bpo-38144.)
hashlib¶
ماژول hashlib به OpenSSL 1.1.1 یا جدیدتر نیاز دارد. (مشارکتشده توسط Christian Heimes در PEP 644 و bpo-43669.)
ماژول hashlib پشتیبانی اولیهای از OpenSSL 3.0.0 دارد. (مشارکت Christian Heimes در bpo-38820 و مسائل دیگر.)
جایگزین پایتون خالصِ pbkdf2_hmac() منسوخ شده است. در آینده PBKDF2-HMAC تنها زمانی دسترسپذیر خواهد بود که پایتون با پشتیبانی OpenSSL ساخته شده باشد. (مشارکتشده توسط Christian Heimes در bpo-43880.)
hmac¶
ماژول hmac اکنون بهطور داخلی از پیادهسازی HMAC در OpenSSL استفاده میکند. (مشارکتشده توسط Christian Heimes در bpo-40645.)
IDLE و idlelib¶
کاری شد که IDLE تابع sys.excepthook() را فراخوانی کند (هنگامی که بدون '-n' اجرا شود). قلابهای کاربر پیشتر نادیده گرفته میشدند. (مشارکت کن هیلتون در bpo-43008.)
گفتوگوی تنظیمات بازآرایی شد. زبانهی General به زبانههای Windows و Shell/Ed تقسیم شد. منابع راهنما که منوی Help را گسترش میدهند، به زبانهی Extensions منتقل شدند. برای گزینههای جدید فضایی ایجاد شد و گفتوگو کوتاهتر شد. مورد اخیر باعث میشود گفتوگو در صفحهنمایشهای کوچک بهتر جا بگیرد. (مشارکتشده توسط Terry Jan Reedy در bpo-40468.) تنظیم فضای تورفتگی از زبانهی Font به زبانهی جدید Windows منتقل شد. (مشارکتشده توسط Mark Roseman و Terry Jan Reedy در bpo-33962.)
تغییرات فوق به یک نسخهی نگهداری 3.9 بکپورت شدند .
نوار کناری پوسته اضافه شد. اعلان اصلی («>>>») به نوار کناری منتقل شد. اعلانهای ثانویه («...») به نوار کناری اضافه شدند. کلیک چپ و کشیدن اختیاری، یک یا چند سطر از متن را انتخاب میکند، مانند نوار کناری شماره سطر در ویرایشگر. کلیک راست پس از انتخاب سطرهای متن، منوی زمینهای را با گزینه «کپی همراه با اعلانها» نمایش میدهد. این کار، اعلانهای نوار کناری و سطرهای متن انتخابشده را با هم زیپ میکند. این گزینه در منوی زمینه متن نیز ظاهر میشود. (مشارکتشده توسط Tal Einat در bpo-37903.)
برای تورفتگی دادن به کد تعاملی، بهجای تب از فاصله استفاده کنید. این کار باعث میشود ورودیهای کد تعاملی «درست به نظر برسند». امکانپذیر کردن این کار، انگیزهی اصلی برای افزودن نوار کناری پوسته بود. (مشارکتشده توسط تری جان ریدی در bpo-37892.)
کلیدواژههای نرم جدید match، case و _ در دستورهای تطبیق الگو برجستهسازی میشوند. با این حال، این برجستهسازی بینقص نیست و در برخی موارد نادر، از جمله برخی _ ها در الگوهای case، نادرست خواهد بود. (مشارکتشده توسط Tal Einat در bpo-44010.)
جدید در نسخههای نگهداری 3.10.
اعمال برجستهسازی سینتکس به پروندههای .pyi. (مشارکتشده توسط Alex Waygood و Terry Jan Reedy در bpo-45447.)
هنگام ذخیرهی پوسته به همراه ورودیها و خروجیها، اعلانها نیز درج میشوند. (مشارکتشده توسط Terry Jan Reedy در gh-95191.)
inspect¶
هنگامی که یک ماژول __loader__ را تعریف نمیکند، به __spec__.loader بازمیگردد. (مشارکتشده توسط Brett Cannon در bpo-42133.)
افزودن inspect.get_annotations() که حاشیهنویسیهای تعریفشده روی یک شیء را بهصورت ایمن محاسبه میکند. این تابع پیچیدگیهای دسترسی به حاشیهنویسیها روی انواع مختلف اشیاء را مدیریت میکند و درباره شیءای که بررسی میکند، فرضهای بسیار کمی دارد. inspect.get_annotations() همچنین میتواند حاشیهنویسیهای رشتهشده (stringized) را بهدرستی از حالت رشته خارج کند (un-stringize). inspect.get_annotations() اکنون بهعنوان بهترین روش برای دسترسی به دیکشنری حاشیهنویسیهای تعریفشده روی هر شیء پایتون در نظر گرفته میشود؛ برای اطلاعات بیشتر درباره بهترین روشهای کار با حاشیهنویسیها، لطفاً بهترین شیوههای حاشیهنویسی را ببینید. در همین راستا، inspect.signature()، inspect.Signature.from_callable() و inspect.Signature.from_function() اکنون برای بازیابی حاشیهنویسیها inspect.get_annotations() را فراخوانی میکنند. این بدان معناست که inspect.signature() و inspect.Signature.from_callable() نیز اکنون میتوانند حاشیهنویسیهای رشتهشده را از حالت رشته خارج کنند. (مشارکت از Larry Hastings در bpo-43817.)
linecache¶
هنگامی که یک ماژول __loader__ را تعریف نمیکند، به __spec__.loader بازمیگردد. (مشارکتشده توسط Brett Cannon در bpo-42133.)
افزودن پشتیبانی از os.cpu_count() برای VxWorks RTOS. (با مشارکت Peixing Xin در bpo-41440.)
تابع جدید os.eventfd() و توابع کمکی مرتبط برای پوشش دادن فراخوانی سیستمی eventfd2 در لینوکس اضافه شد. (مشارکتشده توسط Christian Heimes در bpo-41001.)
افزودن os.splice() که اجازه میدهد دادهها بین دو توصیفگر پرونده، بدون کپیبرداری میان فضای نشانی هسته و فضای نشانی کاربر، جابهجا شوند، که در آن یکی از توصیفگرهای پرونده باید به یک پایپ اشاره کند. (مشارکت Pablo Galindo در bpo-41625.)
افزودن O_EVTONLY، O_FSYNC، O_SYMLINK و O_NOFOLLOW_ANY برای macOS. (مشارکتشده توسط Donghee Na در bpo-43106.)
os.path¶
os.path.realpath() اکنون یک آرگومان فقطکلیدواژهای به نام strict را میپذیرد. وقتی روی True تنظیم شود، اگر مسیری وجود نداشته باشد یا با حلقهی پیوند نمادین مواجه شود، OSError مطرح میشود. (مشارکتشده توسط Barney Gale در bpo-43757.)
py_compile¶
افزودن گزینهی --quiet به رابط خط فرمان py_compile. (مشارکتشده توسط گریگوری شِوچنکو در bpo-38731.)
site¶
هنگامی که یک ماژول __loader__ را تعریف نمیکند، به __spec__.loader بازمیگردد. (مشارکتشده توسط Brett Cannon در bpo-42133.)
socket¶
استثنای socket.timeout اکنون مستعار TimeoutError است. (مشارکت Christian Heimes در bpo-42413.)
افزودن گزینهای برای ایجاد سوکتهای MPTCP با IPPROTO_MPTCP (مشارکتشده توسط Rui Cunha در bpo-43571.)
افزودن گزینهی IP_RECVTOS برای دریافت نوع سرویس (ToS) یا فیلدهای DSCP/ECN (مشارکتشده توسط Georg Sauthoff در bpo-44077.)
ssl¶
ماژول ssl به OpenSSL 1.1.1 یا جدیدتر نیاز دارد. (مشارکتشده توسط کریستین هایمز در PEP 644 و bpo-43669.)
ماژول ssl پشتیبانی اولیه از OpenSSL 3.0.0 و گزینه جدید OP_IGNORE_UNEXPECTED_EOF دارد. (مشارکتشده توسط Christian Heimes در bpo-38820، bpo-43794، bpo-43788، bpo-43791، bpo-43799، bpo-43920، bpo-43789 و bpo-43811.)
تابع منسوخ و استفاده از ثابتهای منسوخ اکنون به یک DeprecationWarning منجر میشوند. ssl.SSLContext.options بهطور پیشفرض دارای OP_NO_SSLv2 و OP_NO_SSLv3 است و بنابراین نمیتواند دربارهی تنظیم مجدد پرچم هشدار دهد. بخش منسوخشدهها فهرستی از قابلیتهای منسوخ را در بر میگیرد. (مشارکتشده توسط Christian Heimes در bpo-43880.)
ماژول ssl اکنون تنظیمات پیشفرض امنتری دارد. رمزهای فاقد محرمانگی پیشرو (forward secrecy) یا SHA-1 MAC بهطور پیشفرض غیرفعال هستند. سطح امنیتی ۲، کلیدهای ضعیف RSA، DH و ECC با امنیت کمتر از ۱۱۲ بیت را ممنوع میکند. SSLContext بهطور پیشفرض حداقل نسخهی پروتکل TLS 1.2 را به کار میبرد. این تنظیمات بر اساس پژوهشهای Hynek Schlawack است. (نوشتهی Christian Heimes در bpo-43998.)
پروتکلهای منسوخ SSL 3.0، TLS 1.0 و TLS 1.1 دیگر بهطور رسمی پشتیبانی نمیشوند. پایتون بهطور فعال آنها را مسدود نمیکند. با این حال، گزینههای ساخت OpenSSL، پیکربندیهای توزیع، وصلهای فروشنده و بدنههای رمز ممکن است مانع از یک دستدهی موفق شوند.
پارامتر timeout به تابع ssl.get_server_certificate() افزوده شد. (با مشارکت Zackery Spytz در bpo-31870.)
ماژول ssl از نوعهای هیپ (heap-types) و مقداردهی اولیه چندمرحلهای (multi-phase initialization) استفاده میکند. (مشارکتشده توسط کریستین هایمز در bpo-42333.)
پرچم راستیآزمایی جدید VERIFY_X509_PARTIAL_CHAIN افزوده شده است. (مشارکتشده توسط l0x در bpo-40849.)
sys¶
افزودن ویژگی sys.orig_argv: فهرست آرگومانهای اصلی خط فرمان که به پرونده اجرایی پایتون ارسال شدهاند. (مشارکتشده توسط Victor Stinner در bpo-23427.)
افزودن sys.stdlib_module_names که شامل فهرست نام ماژولهای کتابخانه استاندارد است. (نوشتهی Victor Stinner در bpo-42955.)
typing¶
برای تغییرات عمده، به ویژگیهای جدید مرتبط با راهنماهای نوع مراجعه کنید.
رفتار typing.Literal تغییر یافت تا با PEP 586 همخوانی داشته باشد و با رفتار بررسیگرهای نوع ایستای مشخصشده در آن PEP مطابقت کند.
Literal اکنون پارامترهای تکراری را حذف میکند.
مقایسههای برابری بین شیءهای Literal اکنون مستقل از ترتیب هستند.
مقایسههای Literal اکنون نوعها را در نظر میگیرند. برای مثال، Literal[0] == Literal[False] قبلاً به True ارزیابی میشد. اکنون False است. برای پشتیبانی از این تغییر، نهانگاه نوع که بهطور داخلی استفاده میشود، اکنون از تمایز نوعها پشتیبانی میکند.
اشیاء Literal اکنون هنگام مقایسههای برابری، اگر هر یک از پارامترهایشان hashable نباشد، استثنای TypeError ایجاد میکنند. توجه داشته باشید که تعریف Literal با پارامترهای هشناپذیر خطایی ایجاد نمیکند:
>>> from typing import Literal
>>> Literal[{0}]
>>> Literal[{0}] == Literal[{False}]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'set'
(مشارکتشده توسط یوری کاراباس در bpo-42345.)
افزودن تابع جدید typing.is_typeddict() برای دروننگری اینکه آیا یک حاشیهنویسی typing.TypedDict است یا خیر. (مشارکتشده توسط Patrick Reader در bpo-41792.)
زیرکلاسهای typing.Protocol که تنها متغیرهای داده در آنها تعریف شدهاند، اکنون هنگام بررسی با isinstance استثنای TypeError ایجاد میکنند، مگر آنکه با @runtime_checkable دکوراتور شده باشند. پیشتر، این بررسیها بیصدا پاس میشدند. کاربرانی که پروتکلهای زمان اجرا میخواهند، باید زیرکلاسهای خود را با دکوراتور runtime_checkable دکوراتور کنند. (مشارکتشده توسط Yurii Karabas در bpo-38908.)
ایمپورت کردن از زیرماژولهای typing.io و typing.re اکنون DeprecationWarning نشان میدهد. این زیرماژولها از پایتون 3.8 منسوخ شدهاند و در نسخهی آیندهی پایتون حذف خواهند شد. هر چیزی که متعلق به آن زیرماژولهاست، باید بهجای آنها مستقیماً از typing ایمپورت شود. (مشارکتشده توسط Sebastian Rittau در bpo-38291.)
urllib.parse¶
نسخههای پایتون پیش از پایتون 3.10 اجازه میدادند که از هر دو ; و & بهعنوان جداساز پارامترهای پرسوجو در urllib.parse.parse_qs() و urllib.parse.parse_qsl() استفاده شود. بهدلیل نگرانیهای امنیتی، و برای انطباق با توصیههای جدیدتر W3C، این رفتار تغییر کرده است تا تنها یک کلید جداساز واحد مجاز باشد و & بهعنوان پیشفرض باشد. این تغییر بر cgi.parse() و cgi.parse_multipart() نیز تأثیر میگذارد، زیرا این توابع در درون خود از توابع مذکور استفاده میکنند. برای جزئیات بیشتر، لطفاً به مستندات مربوط به هر یک مراجعه کنید. (مشارکتشده توسط آدام گلدشمیت، سنتیل کوماران و کن جین در bpo-42967.)
وجود نویسههای سطر جدید یا تب در بخشهایی از یک URL امکان برخی انواع حملات را فراهم میکند. مطابق مشخصات WHATWG که RFC 3986 را بهروزرسانی میکند، نویسههای سطر جدید اسکی \n، \r و تب \t توسط پارسر در urllib.parse از URL حذف میشوند و از این طریق از چنین حملاتی جلوگیری میشود. نویسههای حذفشونده توسط یک متغیر جدید در سطح ماژول با نام urllib.parse._UNSAFE_URL_BYTES_TO_REMOVE کنترل میشوند. (نگاه کنید به gh-88048)
بهینهسازیها¶
سازندههای str()، bytes() و bytearray() اکنون سریعتر هستند (حدود ۳۰ تا ۴۰ درصد برای اشیاء کوچک). (مشارکتشده توسط Serhiy Storchaka در bpo-41334.)
ماژول runpy اکنون ماژولهای کمتری را ایمپورت میکند. زمان راهاندازی دستور python3 -m module-name بهطور میانگین ۱.۴ برابر سریعتر شده است. در لینوکس، python3 -I -m module-name در پایتون 3.9 تعداد ۶۹ ماژول را ایمپورت میکند، در حالی که در پایتون 3.10 تنها ۵۱ ماژول (-۱۸) را ایمپورت میکند. (مشارکتشده توسط Victor Stinner در bpo-41006 و bpo-41718.)
دستور LOAD_ATTR اکنون از سازوکار جدید «نهانگاه به ازای هر آپکد» (per opcode cache) استفاده میکند. این دستور اکنون برای ویژگیهای معمولی حدود ۳۶٪ و برای جایگاهها ۴۴٪ سریعتر است. (مشارکت توسط Pablo Galindo و Yury Selivanov در bpo-42093 و Guido van Rossum در bpo-42927، بر پایهی ایدههایی که در ابتدا در PyPy و MicroPython پیادهسازی شده بودند.)
هنگام ساخت پایتون با --enable-optimizations، اکنون -fno-semantic-interposition به هر دو سطر کامپایل و پیوند افزوده میشود. این کار ساخت مفسر پایتونی را که با --enable-shared ایجاد میشود، با gcc تا ۳۰ درصد سریعتر میکند. برای جزئیات بیشتر این مقاله را ببینید. (مشارکتشده توسط Victor Stinner و Pablo Galindo در bpo-38980.)
استفاده از کد جدید مدیریت بافر خروجی برای ماژولهای bz2 / lzma / zlib، و افزودن تابع .readall() به کلاس _compression.DecompressReader. واگشایی bz2 اکنون 1.09x ~ 1.17x سریعتر است، واگشایی lzma 1.20x ~ 1.32x سریعتر، و GzipFile.read(-1) 1.11x ~ 1.18x سریعتر. (مشارکتشده توسط Ma Lin، بازبینیشده توسط Gregory P. Smith، در bpo-41486)
هنگام استفاده از حاشیهنویسیهای رشتهایشده، دیکشنریهای حاشیهنویسی برای توابع هنگام ایجاد تابع، دیگر ساخته نمیشوند. در عوض، آنها بهصورت یک تاپل از رشتهها ذخیره میشوند و شیء تابع آن را بهصورت تنبل و در صورت نیاز به دیکشنری حاشیهنویسیها تبدیل میکند. این بهینهسازی زمان CPU مورد نیاز برای تعریف یک تابع حاشیهنویسیشده را به نصف کاهش میدهد. (مشارکتشده توسط یوری کاراباس و اینادا نائوکی در bpo-42202.)
توابع جستجوی زیررشته مانند str1 in str2 و str2.find(str1) اکنون گاهی از الگوریتم جستجوی رشتهی «دوطرفه» (Two-Way) کروچمور و پرین (Crochemore & Perrin) استفاده میکنند تا از رفتار درجه دوم روی رشتههای طولانی اجتناب کنند. (مشارکتشده توسط Dennis Sweeney در bpo-41972)
افزودن ریزبهینهسازیهایی به _PyType_Lookup() برای بهبود کارایی جستجوی نهانگاه ویژگیهای نوع در حالت رایج اصابت نهانگاه. این کار مفسر را بهطور میانگین ۱٫۰۴ برابر سریعتر میکند. (با مشارکت Dino Viehland در bpo-43452.)
توابع توکار زیر اکنون از قرارداد فراخوانی vectorcall سریعترِ PEP 590 پشتیبانی میکنند: map()، filter()، reversed()، bool() و float(). (مشارکتشده توسط Donghee Na و Jeroen Demeyer در bpo-43575، bpo-43287، bpo-41922، bpo-41873 و bpo-41870.)
کارایی BZ2File با حذف RLock داخلی بهبود یافته است. این کار BZ2File را در مواجهه با چندین خواننده یا نویسندهی همزمان نخناامن میکند، همانطور که کلاسهای معادل آن در gzip و lzma همیشه چنین بودهاند. (مشارکتشده از طرف Inada Naoki در bpo-43785.)
منسوخ¶
در حال حاضر پایتون مقادیر لفظی عددی را میپذیرد که بلافاصله کلیدواژهای پس از آنها بیاید، برای مثال 0in x، 1or x، 0if 1else 2. این امر اجازه میدهد عبارتهای گیجکننده و مبهمی مانند [0x1for x in y] وجود داشته باشند (که میتوان آن را به صورت [0x1 for x in y] یا [0x1f or x in y] تفسیر کرد). از این نسخه به بعد، اگر بلافاصله پس از مقدار لفظی عددی یکی از کلیدواژههای and، else، for، if، in، is و or بیاید، هشدار منسوخشدن نشان داده میشود. در نسخههای آینده این به هشدار نحوی و در نهایت به خطای نحوی تغییر خواهد کرد. (مشارکتشده توسط Serhiy Storchaka در bpo-43833.)
با شروع از این نسخه، تلاشی هماهنگ برای شروع پاکسازی معناشناسی ایمپورت قدیمی که برای سازگاری با پایتون 2.7 نگه داشته شده بودند، انجام خواهد شد. بهطور خاص، find_loader()/find_module() (که با find_spec() جایگزین شدهاند)، importlib.abc.Loader.load_module (که با exec_module() جایگزین شده است)، module_repr() (که سیستم ایمپورت آن را برای شما انجام میدهد)، ویژگی __package__ (که با __spec__.parent جایگزین شده است)، ویژگی __loader__ (که با __spec__.loader جایگزین شده است) و ویژگی __cached__ (که با __spec__.cached جایگزین شده است) به آرامی حذف خواهند شد (به همراه سایر کلاسها و متدها در importlib). هشدار ImportWarning و/یا DeprecationWarning به عنوان هشدار مناسب بالا آورده خواهند شد تا به شناسایی کدهایی که در طول این انتقال نیاز به بهروزرسانی دارند کمک کنند.
کل فضای نام distutils منسوخ شده است و در پایتون 3.12 حذف خواهد شد. برای اطلاعات بیشتر به بخش تغییرات ماژول مراجعه کنید.
آرگومانهای غیر عدد صحیح برای random.randrange() منسوخ شدهاند. ValueError به نفع TypeError منسوخ شده است. (مشارکت Serhiy Storchaka و Raymond Hettinger در bpo-37319.)
متدهای گوناگون load_module() در importlib از پایتون 3.6 بهعنوان منسوخ مستند شدهاند، اما اکنون علاوه بر آن، یک DeprecationWarning نیز ایجاد خواهند کرد. بهجای آن از exec_module() استفاده کنید. (مشارکتشده توسط Brett Cannon در bpo-26131.)
zimport.zipimporter.load_module() به نفع exec_module() منسوخ شده است. (مشارکتشده توسط Brett Cannon در bpo-26131.)
استفاده از importlib.abc.Loader.load_module توسط سیستم ایمپورت اکنون یک ImportWarning را فعال میکند زیرا ترجیح بر استفاده از exec_module() است. (مشارکتکرده توسط Brett Cannon در bpo-26131.)
استفاده از importlib.abc.MetaPathFinder.find_module() و importlib.abc.PathEntryFinder.find_module() توسط سیستم ایمپورت اکنون موجب صدور ImportWarning میشود، زیرا importlib.abc.MetaPathFinder.find_spec() و importlib.abc.PathEntryFinder.find_spec() به ترتیب ترجیح داده میشوند. میتوانید از importlib.util.spec_from_loader() برای کمک به انتقال استفاده کنید. (مشارکتشده توسط Brett Cannon در bpo-42134.)
استفاده از importlib.abc.PathEntryFinder.find_loader() توسط سیستم ایمپورت اکنون ImportWarning را فعال میکند، زیرا importlib.abc.PathEntryFinder.find_spec() ترجیح داده میشود. میتوانید از importlib.util.spec_from_loader() برای کمک به انتقال استفاده کنید. (مشارکت از Brett Cannon در bpo-43672.)
پیادهسازیهای گوناگون importlib.abc.MetaPathFinder.find_module() ( importlib.machinery.BuiltinImporter.find_module()، importlib.machinery.FrozenImporter.find_module()، importlib.machinery.WindowsRegistryFinder.find_module()، importlib.machinery.PathFinder.find_module()، importlib.abc.MetaPathFinder.find_module() )، importlib.abc.PathEntryFinder.find_module() ( importlib.machinery.FileFinder.find_module() ) و importlib.abc.PathEntryFinder.find_loader() ( importlib.machinery.FileFinder.find_loader() ) اکنون استثنای DeprecationWarning را ایجاد میکنند و برای حذف در پایتون 3.12 در نظر گرفته شدهاند (پیشتر در پایتون 3.4 بهعنوان منسوخ مستند شده بودند). (مشارکتشده توسط Brett Cannon در bpo-42135.)
کلاس importlib.abc.Finder منسوخ شده است (به همراه تنها متد آن، find_module()). هر دو کلاس importlib.abc.MetaPathFinder و importlib.abc.PathEntryFinder دیگر از این کلاس ارثبری نمیکنند. کاربران باید بهجای آن، بسته به نیازشان از یکی از این دو کلاس ارثبری کنند. (مشارکت Brett Cannon در bpo-42135.)
منسوخشدگیهای imp، importlib.find_loader()، importlib.util.set_package_wrapper()، importlib.util.set_loader_wrapper()، importlib.util.module_for_loader()، pkgutil.ImpImporter و pkgutil.ImpLoader همگی بهروزرسانی شدهاند تا پایتون 3.12 را بهعنوان نسخه حذف برنامهریزیشده فهرست کنند (آنها در نسخههای قبلی پایتون شروع به ایجاد DeprecationWarning کرده بودند). (نوشتهشده توسط Brett Cannon در bpo-43720.)
سیستم ایمپورت اکنون پیش از بازگشت به module_repr() برای متد __repr__() یک ماژول، از ویژگی __spec__ روی ماژولها استفاده میکند. حذف استفاده از module_repr() برای پایتون 3.12 برنامهریزی شده است. (مشارکتشده توسط Brett Cannon در bpo-42137.)
importlib.abc.Loader.module_repr()، importlib.machinery.FrozenLoader.module_repr() و importlib.machinery.BuiltinLoader.module_repr() منسوخ شدهاند و قرار است در پایتون 3.12 حذف شوند. (مشارکتشده توسط Brett Cannon در bpo-42136.)
sqlite3.OptimizedUnicode از زمان پایتون 3.3 که به یک نام مستعار برای str تبدیل شد، مستندنشده و از رده خارج بوده است. اکنون منسوخ شده و حذف آن برای پایتون 3.12 برنامهریزی شده است. (مشارکتشده توسط Erlend E. Aasland در bpo-42264.)
تابع توکار فاقد مستندات sqlite3.enable_shared_cache اکنون منسوخ شده است و حذف آن در پایتون 3.12 برنامهریزی شده است. مستندات SQLite3 بهشدت توصیه میکنند که از استفاده از آن پرهیز شود. برای جزئیات بیشتر به مستندات SQLite3 مراجعه کنید. اگر ناچار به استفاده از نهانگاه اشتراکی هستید، پایگاه داده را در حالت URI با استفاده از پارامتر پرسوجوی cache=shared باز کنید. (مشارکتشده توسط Erlend E. Aasland در bpo-24464.)
متدهای زیر از threading اکنون منسوخ شدهاند:
(مشارکتشده توسط Jelle Zijlstra در gh-87889.)
pathlib.Path.link_to() منسوخشده و قرار است در Python 3.12 حذف شود. به جای آن از pathlib.Path.hardlink_to() استفاده کنید. (مشارکتشده توسط Barney Gale در bpo-39950.)
cgi.log() منسوخ شده و قرار است در پایتون 3.12 حذف شود. (مشارکتشده توسط Inada Naoki در bpo-41139.)
قابلیتهای زیر در ماژول ssl از زمان Python 3.6، Python 3.7 یا OpenSSL 1.1.0 منسوخ شدهاند و در نسخهی 3.11 حذف خواهند شد:
اشکالزدایی نخبندی (متغیر محیطی PYTHONTHREADDEBUG) در پایتون 3.10 منسوخ شده است و در پایتون 3.12 حذف خواهد شد. این قابلیت نیازمند نسخهی اشکالزدایی پایتون است. (ارائهشده توسط ویکتور استینر در bpo-44584.)
ایمپورت کردن از زیرماژولهای typing.io و typing.re از این پس هشدار DeprecationWarning نشان میدهد. این زیرماژولها در نسخهای آینده از پایتون حذف خواهند شد. هر آنچه که به این زیرماژولها تعلق دارد، باید بهجای آن مستقیماً از typing ایمپورت شود. (مشارکتشده توسط سباستین ریتاو در bpo-38291.)
حذفشده¶
متدهای ویژه __int__، __float__، __floordiv__، __mod__، __divmod__، __rfloordiv__، __rmod__ و __rdivmod__ از کلاس complex حذف شدند. این متدها همیشه استثنای TypeError ایجاد میکردند. (مشارکتشده توسط Serhiy Storchaka در bpo-41974.)
متد ParserBase.error() از ماژول خصوصی و مستندنشدهی _markupbase حذف شده است. html.parser.HTMLParser تنها زیرکلاس ParserBase است و پیادهسازی error() آن پیشتر در Python 3.5 حذف شده بود. (مشارکتشده توسط Berker Peksag در bpo-31844.)
ویژگی unicodedata.ucnhash_CAPI که یک شیء PyCapsule داخلی بود، حذف شد. ساختار خصوصی مرتبط _PyUnicode_Name_CAPI به API داخلی C منتقل شد. (مشارکتشده توسط Victor Stinner در bpo-42157.)
ماژول parser که در نسخهی 3.9 به دلیل تغییر به پارسر جدید PEG منسوخ شده بود، به همراه تمام پروندههای منبع C و سرآیندهایی که تنها توسط پارسر قدیمی استفاده میشدند — از جمله node.h، parser.h، graminit.h و grammar.h — حذف شد.
توابع API عمومی C PyParser_SimpleParseStringFlags، PyParser_SimpleParseStringFlagsFilename، PyParser_SimpleParseFileFlags و PyNode_Compile که در 3.9 به دلیل تغییر به پارسر جدید PEG منسوخ شده بودند، حذف شدند.
ماژول formatter که در پایتون 3.4 منسوخ شده بود، حذف شد. این ماژول تا حدی از رده خارج است، کم استفاده میشود و آزمایش نشده است. در ابتدا قرار بود این ماژول در پایتون 3.6 حذف شود، اما چنین حذفهایی تا پس از پایان عمر (EOL) پایتون 2.7 به تعویق افتادند. کاربران فعلی باید هر کلاسی را که استفاده میکنند، در کد خود کپی کنند. (مشارکتشده توسط دونگهی نا و تری جی. ریدی در bpo-42299.)
تابع PyModule_GetWarningsModule() که اکنون به دلیل تبدیل ماژول _warnings به یک ماژول توکار در نسخهی 2.6 بیفایده شده بود، حذف شد. (مشارکتشده توسط Hai Shi در bpo-42599.)
نامهای مستعار منسوخ به کلاسهای پایه انتزاعی مجموعهها از ماژول collections حذف شدند. (مشارکتشده توسط Victor Stinner در bpo-37324.)
پارامتر loop پس از منسوخ شدن در پایتون 3.8، از بیشتر API سطح بالای asyncio حذف شده است. انگیزهی این تغییر چندگانه است:
این کار، API سطح بالا را سادهتر میکند.
توابع API سطح بالا از پایتون 3.7 به بعد بهطور ضمنی حلقه رویداد در حال اجرا در نخ جاری را دریافت میکنند. در بیشتر موارد استفادهی معمول، نیازی به پاس دادن حلقه رویداد به API نیست.
منتقل کردن حلقه رویداد مستعد خطا است، بهویژه هنگام کار با حلقههایی که در نخهای مختلف در حال اجرا هستند.
توجه داشته باشید که API سطح پایین همچنان loop را میپذیرد. برای مثالهایی از نحوهی جایگزینی کد موجود، به تغییرات در API پایتون مراجعه کنید.
(مشارکتشده توسط Yurii Karabas، Andrew Svetlov، Yury Selivanov و Kyle Stanley در bpo-42392.)
انتقال به پایتون 3.10¶
این بخش، تغییرات پیشتر شرحدادهشده و سایر رفع اشکالهایی را که ممکن است نیازمند تغییراتی در کد شما باشند، فهرست میکند.
تغییرات در سینتکس پایتون¶
تغییرات در API پایتون¶
پارامترهای etype توابع format_exception()، format_exception_only() و print_exception() در ماژول traceback به exc تغییر نام دادهشدهاند. (مشارکتشده توسط Zackery Spytz و Matthias Bussonnier در bpo-26389.)
atexit: در زمان خروج از پایتون، اگر کالبکی که با atexit.register() ثبتشده است شکست بخورد، استثنای آن اکنون گزارش میشود. پیشتر، تنها برخی از استثناها گزارش میشدند و آخرین استثنا همیشه بیصدا نادیده گرفته میشد. (مشارکتشده توسط Victor Stinner در bpo-42639.)
collections.abc.Callable عام اکنون پارامترهای نوع را تختسازی میکند، مشابه کاری که typing.Callable در حال حاضر انجام میدهد. این بدان معناست که collections.abc.Callable[[int, str], str] دارای __args__ برابر (int, str, str) خواهد بود؛ پیشتر این مقدار ([int, str], str) بود. کدی که به آرگومانها از طریق typing.get_args() یا __args__ دسترسی دارد، باید این تغییر را در نظر بگیرد. علاوه بر این، ممکن است برای صورتهای نامعتبر پارامتریسازی collections.abc.Callable که ممکن است در پایتون 3.9 بیسروصدا عبور کرده باشند، TypeError مطرح شود. (مشارکتشده توسط کن جین در bpo-42195.)
socket.htons() و socket.ntohs() اکنون در صورتی که پارامتر دادهشده در یک عدد صحیح بدون علامت ۱۶بیتی جا نشود، به جای DeprecationWarning استثنای OverflowError ایجاد میکنند. (مشارکتشده توسط ارلند ای. آسلند در bpo-42393.)
پارامتر loop پس از منسوخ شدن در پایتون 3.8، از بیشترِ API سطح بالای asyncio حذف شده است.
یک همروال که در حال حاضر به این شکل است:
async def foo(loop):
await asyncio.sleep(1, loop=loop)
باید با این جایگزین شود:
async def foo():
await asyncio.sleep(1)
اگر foo() بهطور خاص بهگونهای طراحی شده است که در حلقه رویدادِ در حال اجرا در نخ فعلی اجرا نشود (مثلاً در حلقه رویدادِ نخ دیگری اجرا شود)، بهجای آن استفاده از asyncio.run_coroutine_threadsafe() را در نظر بگیرید.
(مشارکتشده توسط Yurii Karabas، Andrew Svetlov، Yury Selivanov و Kyle Stanley در bpo-42392.)
سازندهی types.FunctionType اکنون در صورتی که دیکشنری globals کلید "__builtins__" نداشته باشد، توکارهای فعلی را به ارث میبرد، به جای اینکه از {"None": None} به عنوان توکارها استفاده کند: رفتاری مشابه توابع eval() و exec(). تعریف تابع با def function(...): ... در پایتون تحت تأثیر قرار نمیگیرد و با این سینتکس نمیتوان globals را بازنویسی کرد: این تابع نیز توکارهای فعلی را به ارث میبرد. (مشارکتشده توسط Victor Stinner در bpo-42990.)
تغییرات در API زبان C¶
توابع API زبان C PyParser_SimpleParseStringFlags، PyParser_SimpleParseStringFlagsFilename، PyParser_SimpleParseFileFlags و PyNode_Compile و همچنین نوع استفادهشده توسط این توابع، struct _node، به دلیل تغییر به پارسر جدید PEG حذف شدند.
اکنون باید کد منبع مستقیماً به یک شیء کد کامپایل شود، برای مثال با استفاده از Py_CompileString(). سپس میتوان شیء کد حاصل را با استفاده از، برای مثال، PyEval_EvalCode() ارزیابی کرد.
بهطور خاص:
فراخوانی PyParser_SimpleParseStringFlags و سپس PyNode_Compile را میتوان با فراخوانی Py_CompileString() جایگزین کرد.
هیچ جایگزین مستقیمی برای PyParser_SimpleParseFileFlags وجود ندارد. برای کامپایل کد از یک آرگومان FILE *، باید پرونده را در C بخوانید و بافر حاصل را به Py_CompileString() ارسال کنید.
برای کامپایل پروندهای که نام آن بهصورت char * داده شده است، پرونده را بهطور صریح باز کنید، آن را بخوانید و نتیجه را کامپایل کنید. یکی از راههای انجام این کار، استفاده از ماژول io بههمراه PyImport_ImportModule()، PyObject_CallMethod()، PyBytes_AsString() و Py_CompileString() است، همانطور که در ادامه بهصورت طرحوار نشان داده شده است. (اعلانها و مدیریت خطا حذف شدهاند.)
io_module = Import_ImportModule("io");
fileobject = PyObject_CallMethod(io_module, "open", "ss", filename, "rb");
source_bytes_object = PyObject_CallMethod(fileobject, "read", "");
result = PyObject_CallMethod(fileobject, "close", "");
source_buf = PyBytes_AsString(source_bytes_object);
code = Py_CompileString(source_buf, filename, Py_file_input);
برای شیءهای FrameObject، عضو f_lasti اکنون بهجای آفست سادهای در رشته بایتکد، آفست واژهکد (wordcode) را نشان میدهد. این بدان معناست که این عدد باید در ۲ ضرب شود تا با APIهایی که بهجای آن آفست بایتی را انتظار دارند، قابل استفاده باشد (برای مثال PyCode_Addr2Line()). همچنین توجه داشته باشید که عضو f_lasti در شیءهای FrameObject پایدار تلقی نمیشود: لطفاً بهجای آن از PyFrame_GetLineNumber() استفاده کنید.
تغییرات بایتکد سیپایتون¶
تغییرات ساخت¶
PEP 644: پایتون اکنون به OpenSSL 1.1.1 یا جدیدتر نیاز دارد. OpenSSL 1.0.2 دیگر پشتیبانی نمیشود. (مشارکتشده توسط Christian Heimes در bpo-43669.)
توابع C99 snprintf() و vsnprintf() اکنون برای ساخت پایتون الزامی هستند. (مشارکتشده توسط Victor Stinner در bpo-36020.)
sqlite3 نیازمند SQLite 3.7.15 یا بالاتر است. (مشارکتشده توسط Sergey Fedoseev و Erlend E. Aasland در bpo-40744 و bpo-40810.)
ماژول atexit باید از این پس همیشه بهصورت یک ماژول توکار ساخته شود. (مشارکتشده توسط Victor Stinner در bpo-42639.)
افزودن گزینهی --disable-test-modules به اسکریپت configure: ماژولهای آزمون ساخته و نصب نمیشوند. (مشارکتشده توسط Xavier de Gaye، Thomas Petazzoni و Peixing Xin در bpo-27640.)
گزینهی --with-wheel-pkg-dir=PATH به اسکریپت ./configure افزوده شد. اگر تعیین شود، ماژول ensurepip در این پوشه به دنبال بستههای wheel setuptools و pip میگردد: اگر هر دو موجود باشند، از این بستههای wheel بهجای بستههای wheel همراه ensurepip استفاده میشود.
برخی از سیاستهای بستهبندی توزیعهای لینوکس توصیه میکنند که وابستگیها باندل نشوند. برای مثال، فدورا بستههای wheel را در پوشهی /usr/share/python-wheels/ نصب میکند و بستهی ensurepip._bundled را نصب نمیکند.
(مشارکتشده توسط Victor Stinner در bpo-42856.)
یک configure --without-static-libpython option جدید اضافه شد تا کتابخانه ایستا libpythonMAJOR.MINOR.a ساخته نشود و پرونده شیء python.o نصب نشود.
(مشارکتشده توسط Victor Stinner در bpo-43103.)
اسکریپت configure اکنون در صورت وجود از ابزار pkg-config برای تشخیص مکان سرآیندها و کتابخانههای Tcl/Tk استفاده میکند. مانند قبل، میتوان این مکانها را بهطور صریح با گزینههای پیکربندی --with-tcltk-includes و --with-tcltk-libs مشخص کرد. (مشارکتشده توسط Manolis Stamatogiannakis در bpo-42603.)
افزودن گزینهی --with-openssl-rpath به اسکریپت configure. این گزینه ساخت پایتون با یک نصب سفارشی OpenSSL را سادهتر میکند، برای مثال ./configure --with-openssl=/path/to/openssl --with-openssl-rpath=auto. (مشارکتشده توسط Christian Heimes در bpo-43466.)
تغییرات API زبان C¶
PEP 652: نگهداری رابط دودویی پایدار برنامه (ABI)¶
رابط دودویی پایدار (Application Binary Interface) برای ماژولهای توسعهای یا تعبیه پایتون اکنون بهطور صریح تعریف شده است. پایداری رابط برنامهنویسی کاربردی و رابط دودویی کاربردی C تضمینهای پایداری C API و ABI را همراه با بهترین روشها برای استفاده از رابط دودویی پایدار شرح میدهد.
(مشارکتشده توسط پتر ویکتورین در PEP 652 و bpo-43795.)
انتقال به پایتون 3.10¶
اکنون برای استفاده از قالبهای PyArg_ParseTuple() و Py_BuildValue() که از # استفاده میکنند، باید ماکروی PY_SSIZE_T_CLEAN تعریف شود: es#، et#، s#، u#، y#، z#، U# و Z#. به تجزیه آرگومانها و ساخت مقادیر و PEP 353 مراجعه کنید. (مشارکتشده توسط Victor Stinner در bpo-40943.)
از آنجا که Py_REFCNT() به تابع ایستای درونخطی تبدیل شده است، Py_REFCNT(obj) = new_refcnt باید با Py_SET_REFCNT(obj, new_refcnt) جایگزین شود: به Py_SET_REFCNT() مراجعه کنید (از پایتون 3.9 در دسترس است). برای سازگاری با گذشته، میتوان از این ماکرو استفاده کرد:
#if PY_VERSION_HEX < 0x030900A4
# define Py_SET_REFCNT(obj, refcnt) ((Py_REFCNT(obj) = (refcnt)), (void)0)
#endif
(مشارکتشده توسط ویکتور استینر در bpo-39573.)
فراخوانی PyDict_GetItem() بدون در اختیار داشتن قفل مفسر سراسری به دلایل تاریخی مجاز بود. این کار دیگر مجاز نیست. (مشارکتشده توسط Victor Stinner در bpo-40839.)
PyUnicode_FromUnicode(NULL, size) و PyUnicode_FromStringAndSize(NULL, size) اکنون DeprecationWarning ایجاد میکنند. برای تخصیص دادن شیء یونیکد بدون دادهی اولیه از PyUnicode_New() استفاده کنید. (مشارکتشده توسط Inada Naoki در bpo-36346.)
ساختار خصوصی _PyUnicode_Name_CAPI از PyCapsule API unicodedata.ucnhash_CAPI به API داخلی C منتقل شده است. (با مشارکت Victor Stinner در bpo-42157.)
توابع Py_GetPath()، Py_GetPrefix()، Py_GetExecPrefix()، Py_GetProgramFullPath()، Py_GetPythonHome() و Py_GetProgramName() اکنون اگر پیش از Py_Initialize() فراخوانی شوند (پیش از اینکه پایتون مقداردهی اولیه شود)، مقدار NULL برمیگردانند. از API جدید پیکربندی راهاندازی پایتون برای دریافت پیکربندی مسیر پایتون استفاده کنید. (مشارکتکرده توسط Victor Stinner در bpo-42260.)
ماکروهای PyList_SET_ITEM()، PyTuple_SET_ITEM() و PyCell_SET() دیگر نمیتوانند بهعنوان مقدار چپ (l-value) یا مقدار راست (r-value) به کار روند. برای مثال، x = PyList_SET_ITEM(a, b, c) و PyList_SET_ITEM(a, b, c) = x اکنون با خطای کامپایلر شکست میخورند. این امر از باگهایی مانند آزمون if (PyList_SET_ITEM (a, b, c) < 0) ... جلوگیری میکند. (مشارکتشده توسط Zackery Spytz و Victor Stinner در bpo-30459.)
پروندههای API غیرمحدود odictobject.h، parser_interface.h، picklebufobject.h، pyarena.h، pyctype.h، pydebug.h، pyfpe.h و pytime.h به پوشهی Include/cpython منتقل شدهاند. این پروندهها نباید مستقیماً include شوند، زیرا از قبل در Python.h include شدهاند؛ پروندههای include را ببینید. اگر این پروندهها مستقیماً include شدهاند، بهجای آنها include کردن Python.h را در نظر بگیرید. (نوشتهشده توسط Nicholas Sim در bpo-35134.)
برای ایجاد اشیاء نوع تغییرناپذیر، از پرچم نوع Py_TPFLAGS_IMMUTABLETYPE استفاده کنید. برای تشخیص اینکه یک شیء نوع تغییرپذیر است یا خیر، به Py_TPFLAGS_HEAPTYPE تکیه نکنید؛ در عوض بررسی کنید که Py_TPFLAGS_IMMUTABLETYPE تنظیمشده باشد. (مشارکتشده توسط Victor Stinner و Erlend E. Aasland در bpo-43908.)
تابع مستندسازینشده Py_FrozenMain از API محدود حذف شده است. این تابع عمدتاً برای ساختهای سفارشی پایتون مفید است. (مشارکتشده توسط پتر ویکتورین در bpo-26241.)
حذفشده¶
توابع Py_UNICODE_str* برای دستکاری رشتههای Py_UNICODE* حذف شدند. (مشارکتشده توسط Inada Naoki در bpo-41123.)
PyUnicode_GetMax() حذف شد. لطفاً به APIهای جدید (PEP 393) مهاجرت کنید. (مشارکتشده توسط Inada Naoki در bpo-41103.)
PyLong_FromUnicode() حذف شد. لطفاً به PyLong_FromUnicodeObject() مهاجرت کنید. (مشارکتشده توسط Inada Naoki در bpo-41103.)
PyUnicode_AsUnicodeCopy() حذف شد. لطفاً از PyUnicode_AsUCS4Copy() یا PyUnicode_AsWideCharString() استفاده کنید (ارائهشده توسط Inada Naoki در bpo-41103.)
متغیر _Py_CheckRecursionLimit حذف شد: این متغیر با ceval.recursion_limit از ساختار PyInterpreterState جایگزین شده است. (مشارکتشده توسط Victor Stinner در bpo-41834.)
ماکروهای مستندنشده Py_ALLOW_RECURSION و Py_END_ALLOW_RECURSION و فیلد recursion_critical از ساختار PyInterpreterState حذف شدند. (مشارکتشده توسط Serhiy Storchaka در bpo-41936.)
تابع مستندنشدهی PyOS_InitInterrupts() حذف شد. راهاندازی پایتون از قبل بهطور ضمنی هندلرهای سیگنال را نصب میکند: به PyConfig.install_signal_handlers مراجعه کنید. (مشارکتشده توسط Victor Stinner در bpo-41713.)
تابع PyAST_Validate() حذف شد. دیگر نمیتوان شیء AST (نوع mod_ty) را با API عمومی C ساخت. این تابع پیشتر از API محدود C مستثنی شده بود (PEP 384). (مشارکتشده توسط Victor Stinner در bpo-43244.)
حذف پروندهی سرآیند symtable.h و توابع مستندنشده:
تابع Py_SymtableString() به اشتباه بخشی از ABI پایدار بود، اما قابل استفاده نبود، زیرا پروندهی سرآیند symtable.h از C API محدود مستثنی شده بود.
به جای آن از ماژول symtable پایتون استفاده کنید. (مشارکتشده توسط Victor Stinner در bpo-43244.)
حذف PyOS_ReadlineFunctionPointer() از سرآیندهای C API محدود و از python3.dll، کتابخانهای که ABI پایدار را در ویندوز فراهم میکند. از آنجا که این تابع یک آرگومان FILE* میگیرد، نمیتوان پایداری ABI آن را تضمین کرد. (مشارکتشده توسط Petr Viktorin در bpo-43868.)
پروندههای سرآیند ast.h، asdl.h و Python-ast.h حذف شدند. این توابع مستند نشده بودند و از API محدود C مستثنا بودند. بیشتر نامهای تعریفشده توسط این پروندههای سرآیند پیشوند Py نداشتند و در نتیجه میتوانستند تداخل نام ایجاد کنند. برای مثال، Python-ast.h یک ماکروی Yield تعریف میکرد که با نام Yield استفادهشده در سرآیند <winbase.h> ویندوز تداخل داشت. به جای آن از ماژول ast پایتون استفاده کنید. (مشارکت توسط Victor Stinner در bpo-43244.)
توابع کامپایلر و پارسر که از نوع struct _mod استفاده میکنند حذف شدند، زیرا API عمومی C برای AST حذف شده است:
PyAST_Compile()
PyAST_CompileEx()
PyAST_CompileObject()
PyFuture_FromAST()
PyFuture_FromASTObject()
PyParser_ASTFromFile()
PyParser_ASTFromFileObject()
PyParser_ASTFromFilename()
PyParser_ASTFromString()
PyParser_ASTFromStringObject()
این توابع مستندسازینشده بودند و از C API محدود مستثنی بودند. (مشارکتشده توسط Victor Stinner در bpo-43244.)
پروندهی سرآیند pyarena.h همراه با توابع حذف شده است:
PyArena_New()
PyArena_Free()
PyArena_Malloc()
PyArena_AddPyObject()
این توابع فاقد مستندات بودند، از C API محدود مستثنی شده بودند و تنها بهصورت داخلی توسط کامپایلر استفاده میشدند. (مشارکت توسط Victor Stinner در bpo-43244.)
عضو PyThreadState.use_tracing برای بهینهسازی پایتون حذف شده است. (مشارکتشده توسط مارک شنون در bpo-43760.)
ویژگی امنیتی قابل توجه در 3.10.7¶
اکنون تبدیل بین int و str در مبناهایی غیر از ۲ (دودویی)، ۴، ۸ (هشتایی)، ۱۶ (مبنای شانزده) یا ۳۲، مانند مبنای ۱۰ (دهدهی)، در صورتی که تعداد ارقام در شکل رشتهای از حدی فراتر رود، یک ValueError ایجاد میکند تا از حملات احتمالی انکار سرویس ناشی از پیچیدگی الگوریتمی جلوگیری شود. این یک اقدام کاهشی برای CVE 2020-10735 است. این محدودیت را میتوان از طریق متغیر محیطی، پرچم خط فرمان، یا APIهای sys پیکربندی یا غیرفعال کرد. مستندات محدودیت طول تبدیل رشتهای عدد صحیح را ببینید. محدودیت پیشفرض ۴۳۰۰ رقم در شکل رشتهای است.
ویژگی امنیتی قابل توجه در 3.10.8¶
ماژول منسوخ mailcap اکنون از تزریق متن ناامن (نام پروندهها، نوعهای MIME، پارامترها) به دستورهای پوسته خودداری میکند. بهجای استفاده از چنین متنی، هشدار میدهد و طوری رفتار میکند که گویی هیچ تطبیقی یافت نشده است (یا برای دستورهای آزمون، گویی که آزمون شکست خورده است). (ارائهشده توسط Petr Viktorin در gh-98966.)
تغییرات قابل توجه در 3.10.12¶
© حق نشر 2001 Python Software Foundation.
این صفحه تحت مجوز بنیاد نرمافزار پایتون نسخه ۲ منتشر شده است.
مثالها، دستورالعملها، و سایر کدهای موجود در مستندات همچنین تحت مجوز بدون بند BSD منتشر شدهاند.
برای اطلاعات بیشتر به تاریخچه و مجوز مراجعه کنید.
بنیاد نرمافزار پایتون یک شرکت غیرانتفاعی است.
لطفاً کمک مالی کنید.
آخرین بهروزرسانی در نوامبر 12, 2026 (06:19 UTC).
آیا اشکالی یافتید؟
ساخته شده با Sphinx 9.1.0.
|