این مقاله ویژگیهای جدید پایتون 3.7 را در مقایسه با 3.6 توضیح میدهد. پایتون 3.7 در ۲۷ ژوئن ۲۰۱۸ منتشر شد. برای جزئیات کامل، فهرست تغییرات را ببینید.
قابلیتهای جدید¶
PEP 563: ارزیابی معوق حاشیهنویسیها¶
با ظهور راهنماهای نوع در پایتون، دو مشکل چشمگیر کاربردپذیری در کارکرد حاشیهنویسیهایی که در PEP 3107 افزوده شده و در PEP 526 بیش از پیش پالایش یافته بودند، آشکار شد:
حاشیهنویسیها تنها میتوانستند از نامهایی استفاده کنند که از قبل در محدوده فعلی در دسترس بودند، به عبارت دیگر آنها هیچگونه ارجاع پیشرو را پشتیبانی نمیکردند؛ و
حاشیهنویسی کد منبع اثرات نامطلوبی بر زمان راهاندازی برنامههای پایتون داشت.
هر دوی این مشکلات با به تعویق انداختن ارزیابی حاشیهنویسیها رفع میشوند. بهجای کامپایل کردن کدی که عبارتهای درون حاشیهنویسیها را در زمان تعریفشان اجرا میکند، کامپایلر حاشیهنویسی را به شکل رشتهای معادل درخت سینتکس انتزاعی (AST) عبارت مورد نظر ذخیره میکند. در صورت نیاز، میتوان حاشیهنویسیها را در زمان اجرا با استفاده از typing.get_type_hints() حل کرد. در حالت رایجی که این کار لازم نیست، حاشیهنویسیها ارزانتر ذخیره میشوند (چون مفسر رشتههای کوتاه را درونیسازی (interning) میکند) و زمان راهاندازی را سریعتر میکنند.
از نظر کاربردپذیری، حاشیهنویسیها اکنون از ارجاعهای پیشرو پشتیبانی میکنند و همین امر سینتکس زیر را معتبر میسازد:
class C:
@classmethod
def from_string(cls, source: str) -> C:
...
def validate_b(self, obj: B) -> bool:
...
class B:
...
از آنجا که این تغییر سازگاری را میشکند، لازم است رفتار جدید در پایتون 3.7 به ازای هر ماژول با استفاده از یک ایمپورت __future__ فعال شود:
from __future__ import annotations
این در پایتون 3.10 به پیشفرض تبدیل خواهد شد.
همچنین ببینید
- PEP 563 -- ارزیابی معوق حاشیهنویسیها
PEP نوشته و پیادهسازیشده توسط Łukasz Langa.
PEP 538: اجبار locale C قدیمی¶
یک چالش مداوم در سری پایتون ۳، تعیین راهبرد پیشفرض منطقی برای برخورد با فرض کدگذاری متن «اسکی ۷-بیتی» بوده است؛ فرضی که در حال حاضر استفاده از locale پیشفرض C یا POSIX در پلتفرمهای غیر ویندوزی بر آن دلالت میکند.
PEP 538 رابط خط فرمان پیشفرض مفسر را بهروزرسانی میکند تا آن locale را بهطور خودکار به یک locale موجود مبتنی بر UTF-8 تبدیل کند، همانطور که در مستندات متغیر محیطی جدید PYTHONCOERCECLOCALE شرح داده شده است. تنظیم خودکار LC_CTYPE به این شکل بدین معناست که هم هستهی مفسر و هم افزونههای C که از locale آگاهاند (مانند readline)، استفاده از UTF-8 را بهعنوان کدگذاری متن پیشفرض فرض خواهند کرد، نه اسکی.
تعریف پشتیبانی پلتفرم در PEP 11 نیز بهروزرسانی شده است تا پشتیبانی کامل از مدیریت متن به localeهای مبتنی بر غیراسکی که بهدرستی پیکربندی شدهاند محدود شود.
بهعنوان بخشی از این تغییر، هنگامی که از هر یک از localeهای هدف الزام (coercion) تعریفشده استفاده میشود (در حال حاضر C.UTF-8، C.utf8 و UTF-8)، هندلر خطای پیشفرض برای stdin و stdout اکنون surrogateescape است (بهجای strict). هندلر خطای پیشفرض برای stderr همچنان backslashreplace است، بدون توجه به locale.
اجبار locale (locale coercion) بهطور پیشفرض بیصدا است، اما برای کمک به اشکالزدایی مشکلات یکپارچهسازی که احتمالاً به locale مرتبط هستند، میتوان با تنظیم PYTHONCOERCECLOCALE=warn هشدارهای صریح (که مستقیماً روی stderr منتشر میشوند) را درخواست کرد. این تنظیم همچنین باعث میشود در صورتی که locale قدیمی C هنگام مقداردهی اولیهی هستهی مفسر همچنان فعال باشد، رانتایم پایتون هشداری منتشر کند.
اگرچه اجبار locale در PEP 538 این مزیت را دارد که بر ماژولهای توسعهای (مانند GNU readline) و همچنین فرایندهای فرزند (از جمله آنهایی که برنامههای غیرپایتونی و نسخههای قدیمیتر پایتون را اجرا میکنند) نیز اثر میگذارد، این عیب را دارد که نیازمند آن است که locale هدف مناسبی روی سیستم در حال اجرا وجود داشته باشد. برای مدیریت بهتر حالتی که هیچ locale هدف مناسبی در دسترس نیست (همانطور که برای مثال در RHEL/CentOS 7 رخ میدهد)، پایتون 3.7 همچنین PEP 540: حالت اجباری UTF-8 در رانتایم را پیادهسازی میکند.
همچنین ببینید
- PEP 538 -- تبدیل اجباری locale قدیمی C به locale مبتنی بر UTF-8
PEP توسط Nick Coghlan نوشته و پیادهسازیشده است.
PEP 540: حالت اجباری UTF-8 در رانتایم¶
از گزینهی جدید خط فرمان -X utf8 و متغیر محیطی PYTHONUTF8 میتوان برای فعالسازی حالت UTF-8 پایتون استفاده کرد.
در حالت UTF-8، سیپایتون تنظیمات locale را نادیده میگیرد و بهطور پیشفرض از کدگذاری UTF-8 استفاده میکند. هندلرهای خطا برای جریانهای sys.stdin و sys.stdout روی surrogateescape تنظیم میشوند.
از حالت اجباری UTF-8 میتوان برای تغییر رفتار مدیریت متن در یک مفسر پایتون تعبیهشده، بدون تغییر تنظیمات locale برنامهی تعبیهکننده استفاده کرد.
اگرچه حالت UTF-8 PEP 540 این مزیت را دارد که فارغ از اینکه کدام localeها روی سیستم در حال اجرا در دسترس هستند، کار میکند، اما این عیب را دارد که هیچ تأثیری بر ماژولهای توسعهای (مانند GNU readline)، فرایندهای فرزندی که برنامههای غیرپایتونی را اجرا میکنند و فرایندهای فرزندی که نسخههای قدیمیتر پایتون را اجرا میکنند، ندارد. برای کاهش خطر خرابی دادههای متنی هنگام برقراری ارتباط با چنین کامپوننتهایی، پایتون 3.7 همچنین PEP 540: حالت اجباری UTF-8 در رانتایم را پیادهسازی میکند).
حالت UTF-8 بهطور پیشفرض فعال میشود زمانی که locale برابر با C یا POSIX باشد و ویژگی اجبار locale در PEP 538 نتواند آن را به جایگزینی مبتنی بر UTF-8 تغییر دهد (چه این شکست به دلیل تنظیمشدن PYTHONCOERCECLOCALE=0 باشد، چه به دلیل تنظیمشدن LC_ALL، و چه به دلیل نبود locale هدف مناسب).
همچنین ببینید
- PEP 540 -- افزودن حالت جدید UTF-8
PEP (پیشنهاد بهبود پایتون) نوشته و پیادهسازیشده توسط Victor Stinner
PEP 553: تابع توکار breakpoint()¶
پایتون 3.7 تابع توکار جدید breakpoint() را بهعنوان راهی آسان و سازگار برای ورود به اشکالزدای پایتون در بر میگیرد.
تابع توکار breakpoint()، sys.breakpointhook() را فراخوانی میکند. بهصورت پیشفرض، دومی pdb را ایمپورت میکند و سپس pdb.set_trace() را فراخوانی میکند، اما با مقید کردن sys.breakpointhook() به تابع دلخواه خودتان، breakpoint() میتواند وارد هر دیباگری شود. علاوه بر این، میتوان متغیر محیط PYTHONBREAKPOINT را برابر با فراخوانیپذیر دیباگر دلخواه خودتان قرار داد. برای غیرفعالسازی کامل breakpoint() توکار، PYTHONBREAKPOINT=0 را تنظیم کنید.
همچنین ببینید
- PEP 553 -- تابع توکار breakpoint()
PEP (پیشنهاد بهبود پایتون) توسط Barry Warsaw نوشته و پیادهسازی شده است
PEP 539: C API جدید برای ذخیرهسازی نخمحلی¶
در حالی که پایتون یک C API برای پشتیبانی از ذخیرهسازی نخمحلی ارائه میدهد، API ذخیرهسازی نخمحلی (TLS) موجود از int برای نمایش کلیدهای TLS در همهی پلتفرمها استفاده کرده است. این موضوع بهطور کلی برای پلتفرمهای دارای پشتیبانی رسمی مشکلی نبوده است، اما این نه با POSIX سازگار است و نه به هیچ معنای عملی قابل حمل است.
PEP 539 این وضعیت را با فراهم کردن یک API ذخیرهسازی اختصاصی نخ (TSS) جدید برای سیپایتون تغییر میدهد که جایگزین استفاده از API موجود TLS درون مفسر سیپایتون میشود و همزمان API موجود را منسوخ میکند. API مربوط به TSS بهجای int از نوع جدید Py_tss_t برای نمایش کلیدهای TSS استفاده میکند — نوعی مات که تعریف آن ممکن است به پیادهسازی TLS زیرین بستگی داشته باشد. بنابراین، این امر امکان ساخت سیپایتون روی پلتفرمهایی را فراهم میکند که کلید TLS بومی در آنها به شکلی تعریف شده که نمیتوان آن را بهطور ایمن به int تبدیل نوع کرد.
توجه داشته باشید که در سکوهایی که کلید TLS بومی بهگونهای تعریف شده است که نتوان آن را بهطور امن به int قالبریزی کرد، تمام توابع API موجود TLS عملیات بیاثر خواهند بود و بلافاصله شکست را برمیگردانند. این بهوضوح نشان میدهد که API قدیمی در سکوهایی که نمیتوان از آن بهطور قابلاعتماد استفاده کرد، پشتیبانی نمیشود و هیچ تلاشی برای افزودن چنین پشتیبانیای انجام نخواهد شد.
همچنین ببینید
- PEP 539 -- C-API جدید برای ذخیرهسازی نخمحلی در سیپایتون
PEP نوشتهشده توسط Erik M. Bray؛ پیادهسازی توسط Masayuki Yamamoto.
PEP 562: سفارشیسازی دسترسی به ویژگیهای ماژول¶
پایتون 3.7 اجازه میدهد __getattr__() را روی ماژولها تعریف کنید و هرگاه ویژگی ماژول از طریقهای دیگر یافت نشود، آن را فراخوانی میکند. اکنون تعریف __dir__() روی ماژولها نیز مجاز است.
یک مثال نمونه از مواردی که این ممکن است مفید باشد، منسوخسازی ویژگیهای ماژول و بارگذاری تنبل (lazy loading) است.
همچنین ببینید
- PEP 562 -- ماژول
__getattr__ و __dir__ PEP نوشتهشده و پیادهسازیشده توسط ایوان لِوکیوسکی
PEP 564: توابع زمانی جدید با وضوح نانوثانیهای¶
وضوح ساعتها در سیستمهای مدرن میتواند از دقت محدودِ عدد ممیز شناوری که تابع time.time() و گونههای آن بازمیگردانند فراتر رود. برای جلوگیری از افت دقت، PEP 564 شش گونهی جدید «نانوثانیهای» از توابع زمانسنج موجود را به ماژول time اضافه میکند:
توابع جدید تعداد نانوثانیهها را به صورت یک مقدار عدد صحیح برمیگردانند.
اندازهگیریها نشان میدهند که در لینوکس و ویندوز، وضوح time.time_ns() تقریباً ۳ برابر بهتر از وضوح time.time() است.
همچنین ببینید
- PEP 564 -- افزودن توابع زمانی جدید با وضوح نانوثانیه
PEP (پیشنهاد بهبود پایتون) نوشته و پیادهسازیشده توسط Victor Stinner
PEP 565: نمایش DeprecationWarning در __main__¶
برخورد پیشفرض با DeprecationWarning بهگونهای تغییر کرده است که این هشدارها یکبار دیگر بهصورت پیشفرض نمایش داده میشوند، اما تنها زمانی که کد فعالکنندهی آنها مستقیماً در ماژول __main__ در حال اجرا باشد. در نتیجه، توسعهدهندگان اسکریپتهای تکپروندهای و کسانی که پایتون را بهصورت تعاملی به کار میبرند، باید دوباره شروع کنند به دیدن هشدارهای منسوخشدن برای APIهایی که استفاده میکنند، اما هشدارهای منسوخشدنی که توسط ماژولهای ایمپورتشدهی برنامه، کتابخانه و چارچوب فعال میشوند، همچنان بهصورت پیشفرض پنهان باقی خواهند ماند.
در نتیجهی این تغییر، کتابخانه استاندارد اکنون به توسعهدهندگان اجازه میدهد تا بین سه رفتار مختلف برای هشدار منسوخشدگی یکی را انتخاب کنند:
FutureWarning: همیشه بهصورت پیشفرض نمایش داده میشود و برای هشدارهایی که در نظر گرفتهشدهاند تا کاربران نهایی برنامه آنها را ببینند، توصیه میشود (مثلاً برای تنظیمات پیکربندی برنامه که منسوخ شدهاند).
DeprecationWarning: بهطور پیشفرض فقط در __main__ و هنگام اجرای آزمونها نمایش داده میشود؛ برای هشدارهایی که در نظر گرفته شدهاند تا توسط سایر توسعهدهندگان پایتون دیده شوند، در مواردی که ارتقای نسخه ممکن است به تغییر رفتار یا بروز خطا منجر شود، توصیه میشود.
PendingDeprecationWarning: بهطور پیشفرض فقط هنگام اجرای آزمونها نمایش داده میشود و برای مواردی در نظر گرفته شده است که ارتقای نسخهی آینده، دستهی هشدار را به DeprecationWarning یا FutureWarning تغییر خواهد داد.
پیشتر هر دو DeprecationWarning و PendingDeprecationWarning تنها هنگام اجرای آزمونها قابل مشاهده بودند، که این بدان معنا بود که توسعهدهندگانی که عمدتاً اسکریپتهای تکپروندهای مینوشتند یا بهصورت تعاملی از پایتون استفاده میکردند، ممکن بود از تغییرات ناسازگار در APIهایی که به کار میبردند غافلگیر شوند.
همچنین ببینید
- PEP 565 -- نمایش DeprecationWarning در
__main__ PEP (پیشنهاد بهبود پایتون) نوشته و پیادهسازیشده توسط Nick Coghlan
PEP 560: پشتیبانی هستهای از ماژول typing و نوعهای عام¶
در ابتدا، PEP 484 به گونهای طراحی شده بود که هیچ تغییری در هستهی مفسر سیپایتون ایجاد نکند. اکنون راهنماهای نوع و ماژول typing بهطور گسترده توسط کامیونیتی استفاده میشوند، بنابراین این محدودیت برداشته شده است. این PEP دو متد ویژه __class_getitem__() و __mro_entries__() را معرفی میکند؛ این متدها اکنون توسط اکثر کلاسها و ساختارهای ویژه در ماژول typing استفاده میشوند. در نتیجه، سرعت عملیاتهای مختلف با انواع تا ۷ برابر افزایش یافته است، میتوان انواع عام را بدون تعارض فراکلاس به کار برد و چندین اشکال طولانیمدت در ماژول typing رفع شدهاند.
همچنین ببینید
- PEP 560 -- پشتیبانی هستهای از ماژول typing و نوعهای عام
PEP نوشتهشده و پیادهسازیشده توسط ایوان لِوکیوسکی
PEP 552: پروندههای .pyc مبتنی بر هش¶
پایتون بهطور سنتی بهروز بودن پروندههای نهانگاه بایتکد (یعنی پروندههای .pyc) را از طریق مقایسهی فرادادهی منبع (مهر زمانی آخرین تغییر و اندازه) با فرادادهی منبعِ ذخیرهشده در سرآیند پروندهی نهانگاه هنگام تولید آن بررسی کرده است. هرچند مؤثر است، این روش بیاعتبارسازی معایب خود را دارد. هنگامی که مهرهای زمانی سامانه فایلبندی بیش از حد درشت باشند، پایتون ممکن است بهروزرسانیهای منبع را از دست بدهد که این امر باعث سردرگمی کاربر میشود. علاوه بر این، وجود مهر زمانی در پروندهی نهانگاه برای بازتولیدپذیری ساخت و سیستمهای ساخت مبتنی بر محتوا مشکلساز است.
PEP 552 قالب pyc را توسعه میدهد تا بهجای مهر زمانی منبع، از هش پرونده منبع برای بیاعتبارسازی استفاده شود. پروندههای .pyc از این نوع «مبتنی بر هش» نامیده میشوند. بهطور پیشفرض، پایتون همچنان از بیاعتبارسازی مبتنی بر مهر زمانی استفاده میکند و در رانتایم پروندههای .pyc مبتنی بر هش تولید نمیکند. پروندههای .pyc مبتنی بر هش را میتوان با py_compile یا compileall تولید کرد.
پروندههای .pyc مبتنی بر هش در دو گونه ارائه میشوند: بررسیشده و بررسینشده. پایتون پروندههای .pyc مبتنی بر هشِ بررسیشده را در زمان اجرا در برابر پروندههای منبع متناظر اعتبارسنجی میکند، اما این کار را برای pycهای مبتنی بر هشِ بررسینشده انجام نمیدهد. پروندههای .pyc مبتنی بر هشِ بررسینشده بهینهسازی کارایی مفیدی برای محیطهایی هستند که در آنها سیستمی خارج از پایتون (مثلاً سیستم ساخت) مسئول بهروز نگهداشتن پروندههای .pyc است.
برای اطلاعات بیشتر به بیاعتبارسازی بایتکد نهانشده مراجعه کنید.
همچنین ببینید
- PEP 552 -- pycهای قطعی
PEP نوشته و پیادهسازیشده توسط بنجامین پترسون
PEP 545: ترجمههای مستندات پایتون¶
PEP 545 فرایند ایجاد و نگهداری ترجمههای مستندات پایتون را شرح میدهد.
سه ترجمهی جدید افزوده شده است:
همچنین ببینید
- PEP 545 -- ترجمههای مستندات پایتون
PEP توسط Julien Palard، Inada Naoki و Victor Stinner نوشته و پیادهسازی شده است.
حالت توسعه پایتون (-X dev)¶
میتوان از گزینهی جدید خط فرمان -X dev یا متغیر محیطی جدید PYTHONDEVMODE برای فعال کردن حالت توسعهی پایتون استفاده کرد. در حالت توسعه، پایتون بررسیهای اضافی زمان اجرا را انجام میدهد که فعال کردن آنها بهطور پیشفرض بیش از حد پرهزینه است. برای توضیح کامل، به مستندات حالت توسعهی پایتون مراجعه کنید.
ماژولهای بهبودیافته¶
asyncio¶
ماژول asyncio ویژگیهای جدید فراوانی، بهبودهای قابلیت استفاده و بهبودهای کارایی دریافت کرده است. تغییرات قابل توجه عبارتاند از:
چندین API از asyncio منسوخ شدهاند.
binascii¶
تابع b2a_uu() اکنون یک آرگومان کلیدواژهای اختیاری بکتیک (backtick) را میپذیرد. زمانی که مقدار آن درست باشد، صفرها بهجای فاصله، با '`' نمایش داده میشوند. (مشارکتشده توسط Xiang Zhang در bpo-30103.)
calendar¶
کلاس HTMLCalendar دارای ویژگیهای کلاس جدیدی است که سفارشیسازی کلاسهای CSS در گاهشماری HTML تولیدشده را آسان میکنند. (مشارکت Oz Tiram در bpo-30095.)
collections¶
collections.namedtuple() اکنون از مقادیر پیشفرض پشتیبانی میکند. (مشارکتشده توسط Raymond Hettinger در bpo-32320.)
cProfile¶
خط فرمان cProfile اکنون -m module_name را بهعنوان جایگزینی برای مسیر اسکریپت میپذیرد. (مشارکتشده توسط Sanyam Khurana در bpo-21862.)
crypt¶
ماژول crypt اکنون از روش هش Blowfish پشتیبانی میکند. (ارائهشده توسط Serhiy Storchaka در bpo-31664.)
تابع mksalt() اکنون امکان تعیین تعداد دورها برای هشکردن را فراهم میکند. (مشارکتشده توسط Serhiy Storchaka در bpo-31702.)
dbm¶
dbm.dumb اکنون از خواندن پروندههای فقطخواندنی پشتیبانی میکند و وقتی پرونده اندیس تغییر نکرده باشد، دیگر آن را نمینویسد.
dis¶
تابع dis() اکنون میتواند اشیاء کد تودرتو را واسازی کند (کد درکها، عبارتهای تولیدگر و توابع تودرتو، و کدی که برای ساخت کلاسهای تودرتو استفاده میشود). حداکثر عمق بازگشت واسازی توسط پارامتر جدید depth کنترل میشود. (مشارکت Serhiy Storchaka در bpo-11822.)
distutils¶
README.rst اکنون در فهرست READMEهای استاندارد distutils قرار گرفته و بنابراین در توزیعهای منبع نیز گنجانده میشود. (با مشارکت Ryan Gonzalez در bpo-11913.)
enum¶
کلاس Enum ویژگی کلاس جدید _ignore_ را دریافت کرد که امکان فهرستکردن نام ویژگیهایی را فراهم میکند که نباید عضو enum شوند. (ارائهشده توسط Ethan Furman در bpo-31801.)
در پایتون 3.8، تلاش برای بررسی وجود اشیاء غیر Enum در کلاسهای Enum باعث بالا آمدن TypeError میشود (مثلاً 1 in Color)؛ به طور مشابه، تلاش برای بررسی وجود اشیاء غیر Flag در یک عضو Flag باعث بالا آمدن TypeError میشود (مثلاً 1 in Perm.RW)؛ در حال حاضر، هر دو عملیات به جای آن مقدار False را برمیگردانند و منسوخ شدهاند. (مشارکتشده توسط Ethan Furman در bpo-33217.)
تابع جدید gc.freeze() اجازه میدهد تمام اشیاء پیگیریشده توسط زبالهروب فریزشده و از زبالهروبیهای آینده مستثنا شوند. از این قابلیت میتوان پیش از فراخوانی fork() در POSIX برای سازگار کردن GC با کپی هنگام نوشتن (copy-on-write) یا برای سرعت بخشیدن به زبالهروبی استفاده کرد. تابع جدید gc.unfreeze() این عملیات را معکوس میکند. علاوه بر این، میتوان از gc.get_freeze_count() برای به دست آوردن تعداد اشیاء فریزشدهشده استفاده کرد. (مشارکتشده توسط Li Zekun در bpo-31558.)
hmac¶
ماژول hmac اکنون یک تابع یکبارهی بهینهشدهی digest() دارد که تا سه برابر سریعتر از HMAC() است. (مشارکتشده توسط کریستین هایمز در bpo-32433.)
http.server¶
SimpleHTTPRequestHandler اکنون از سرآیند If-Modified-Since در HTTP پشتیبانی میکند. اگر پروندهی هدف پس از زمان مشخصشده در سرآیند تغییری نکرده باشد، سرور وضعیت پاسخ 304 را برمیگرداند. (مشارکت Pierre Quentel در bpo-29654.)
SimpleHTTPRequestHandler علاوه بر آرگومان جدید خط فرمان --directory، آرگومان جدید directory را نیز میپذیرد. با این پارامتر، سرور پوشهی مشخصشده را ارائه میدهد؛ بهطور پیشفرض از پوشهی کاری جاری استفاده میکند. (مشارکتشده توسط Stéphane Wirtel و Julien Palard در bpo-28707.)
کلاس جدید ThreadingHTTPServer با بهرهگیری از ThreadingMixIn، از نخها برای رسیدگی به درخواستها استفاده میکند. این کلاس زمانی استفاده میشود که http.server با -m اجرا شود. (مشارکت Julien Palard در bpo-31639.)
idlelib و IDLE¶
چندین اصلاح برای تکمیل خودکار. (مشارکتشده توسط Louie Lu در bpo-15786.)
مرورگر ماژول (Module Browser) (در منوی File، که پیشتر مرورگر کلاس (Class Browser) نامیده میشد) اکنون علاوه بر توابع و کلاسهای سطح بالا، توابع و کلاسهای تودرتو را نیز نمایش میدهد. (مشارکتشده توسط Guilherme Polo، Cheryl Sabella و Terry Jan Reedy در bpo-1612262.)
گفتوگوی تنظیمات (Options, Configure IDLE) تا حدی بازنویسی شده است تا هم ظاهر و هم عملکرد آن بهبود یابد. (مشارکت Cheryl Sabella و Terry Jan Reedy در چندین مسئله .)
نمونه قلم اکنون شامل گزیدهای از نویسههای غیرلاتین است تا کاربران بتوانند اثر انتخاب یک قلم خاص را بهتر ببینند. (مشارکتشده توسط Terry Jan Reedy در bpo-13802.) نمونه را میتوان ویرایش کرد تا نویسههای دیگری را نیز در بر بگیرد. (مشارکتشده توسط Serhiy Storchaka در bpo-31860.)
قابلیتهای IDLE که پیشتر بهصورت افزونه پیادهسازی شده بودند، بهعنوان قابلیتهای عادی بازپیادهسازی شدهاند. تنظیمات آنها از زبانهی افزونهها به زبانههای دیگر کادر گفتوگو منتقل شدهاند. (مشارکتشده توسط Charles Wohlganger و Terry Jan Reedy در bpo-27099.)
گزینهی زمینه کد ویرایشگر بازنگری شد. جعبه، تمام سطرهای زمینه را تا maxlines نمایش میدهد. با کلیک روی یک سطر زمینه، ویرایشگر به آن سطر پرش میکند. رنگهای زمینه برای پوستههای سفارشی به زبانهی برجستهسازی (Highlights) در گفتوگوی تنظیمات اضافه شد. (مشارکتشده توسط Cheryl Sabella و Terry Jan Reedy در bpo-33642، bpo-33768 و bpo-33679.)
در ویندوز، یک فراخوانی API جدید به ویندوز اعلام میکند که tk مقیاسبندی DPI را انجام میدهد. در Windows 8.1+ یا 10، در صورتی که ویژگیهای سازگاری DPI دودویی پایتون بدون تغییر باشد و وضوح نمایشگر بیشتر از 96 DPI باشد، این کار باید متن و سطرها را واضحتر کند. در غیر این صورت نباید هیچ تأثیری داشته باشد. (مشارکتشده توسط Terry Jan Reedy در bpo-33656.)
جدید در نسخه 3.7.1:
خروجی بیش از N سطر (بهطور پیشفرض ۵۰) در یک دکمه جمع میشود. مقدار N را میتوان در بخش PyShell از صفحهی عمومی در گفتوگوی تنظیمات تغییر داد. سطرهای کمتر — اما احتمالاً بسیار بلند — را میتوان با کلیک راست روی خروجی جمع کرد. خروجی جمعشده را میتوان با دوبار کلیک روی دکمه در جای خود باز کرد، یا با کلیک راست روی دکمه به کلیپبورد یا یک پنجرهی جداگانه منتقل کرد. (مشارکت Tal Einat در bpo-1529353.)
تغییرات بالا به نسخههای نگهداری 3.6 بکپورت شدهاند .
جدید در 3.7.4:
گزینهی «Run Customized» به منوی Run افزوده شد تا بتوان یک ماژول را با تنظیمات سفارشی اجرا کرد. هر آرگومان خط فرمانی که وارد شود به sys.argv افزوده میشود. این آرگومانها برای اجرای سفارشی بعدی دوباره در جعبه ظاهر میشوند. همچنین میتوان از راهاندازی مجدد عادی ماژول اصلی Shell جلوگیری کرد. (با مشارکت Cheryl Sabella، Terry Jan Reedy و دیگران در bpo-5680 و bpo-37627.)
تازه در نسخهی 3.7.5:
افزودن شماره سطرهای اختیاری برای پنجرههای ویرایشگر IDLE. پنجرهها بدون شماره سطر باز میشوند، مگر آنکه در زبانهی General گفتوگوی پیکربندی خلاف آن تنظیم شود. شماره سطرهای یک پنجرهی موجود از طریق منوی Options نمایش داده و پنهان میشوند. (مشارکتشده توسط Tal Einat و Saimadhav Heblikar در bpo-17535.)
math¶
تابع جدید math.remainder() عملیات باقیمانده به سبک IEEE 754 را پیادهسازی میکند. (ارائهشده توسط Mark Dickinson در bpo-29962.)
mimetypes¶
نوع MIME مربوط به .bmp از 'image/x-ms-bmp' به 'image/bmp' تغییر کرده است. (نوشتهشده توسط Nitish Chandra در bpo-22589.)
msilib¶
از متد جدید Database.Close() میتوان برای بستن پایگاه داده MSI استفاده کرد. (مشارکتشده توسط Berker Peksag در bpo-20486.)
چندپردازشی (multiprocessing)¶
متد جدید Process.close() بهطور صریح شیء فرایند را میبندد و تمام منابع مرتبط با آن را آزاد میکند. اگر فرایند زیرین هنوز در حال اجرا باشد، ValueError پرتاب میشود. (مشارکت Antoine Pitrou در bpo-30596.)
از متد جدید Process.kill() میتوان برای خاتمه دادن به فرایند با استفاده از سیگنال SIGKILL در یونیکس استفاده کرد. (مشارکتشده توسط Vitor Pereira در bpo-30794.)
نخهای غیر دِیمِنی که توسط Process ایجاد میشوند، اکنون هنگام خروج فرایند پیوست میشوند. (مشارکت آنتوان پیترو در bpo-18966.)
pathlib¶
متد جدید Path.is_mount() اکنون در سیستمهای POSIX در دسترس است و میتوان از آن برای تعیین اینکه آیا یک مسیر نقطه اتصال (mount point) است یا خیر استفاده کرد. (مشارکتشده توسط Cooper Ry Lees در bpo-30897.)
pdb¶
pdb.set_trace() اکنون یک آرگومان فقطکلیدواژهای اختیاری به نام header میپذیرد. اگر این آرگومان ارائه شود، درست پیش از آغاز اشکالزدایی در کنسول چاپ میشود. (مشارکتشده توسط Barry Warsaw در bpo-31389.)
خط فرمان pdb اکنون -m module_name را بهعنوان جایگزینی برای پرونده اسکریپت میپذیرد. (مشارکتشده توسط Mario Corchero در bpo-32206.)
py_compile¶
py_compile.compile() — و بهتبع آن، compileall — اکنون با ایجاد بیقیدوشرط پروندههای .pyc برای اعتبارسنجی مبتنی بر هش، متغیر محیطی SOURCE_DATE_EPOCH را رعایت میکند. این امر امکان تضمین ساختهای تکرارپذیر (reproducible builds) پروندههای .pyc را زمانی که بهطور فوری ایجاد میشوند فراهم میکند. (مشارکتشده توسط Bernhard M. Wiedemann در bpo-29708.)
pydoc¶
سرور pydoc اکنون میتواند به نام میزبان دلخواهی که با آرگومان جدید خط فرمان -n مشخص میشود، مقید شود. (مشارکتشده توسط Feanil Patel در bpo-31128.)
پرچمهای re.ASCII، re.LOCALE و re.UNICODE را میتوان در محدودهی یک گروه تنظیم کرد. (ارائهشده توسط Serhiy Storchaka در bpo-31690.)
re.split() اکنون از تقسیم بر اساس الگویی مانند r'\b'، '^$' یا (?=-) که با رشتهی تهی تطبیق مییابد، پشتیبانی میکند. (با مشارکت Serhiy Storchaka در bpo-25054.)
عبارتهای باقاعدهای که با پرچم re.LOCALE کامپایل شدهاند، دیگر در زمان کامپایل به locale وابسته نیستند. تنظیمات locale تنها زمانی اعمال میشوند که عبارت باقاعدهی کامپایلشده استفاده شود. (با مشارکت Serhiy Storchaka در bpo-30215.)
FutureWarning اکنون منتشر میشود اگر عبارت باقاعدهای شامل ساختارهای مجموعه نویسه باشد که در آینده از نظر معنایی تغییر خواهند کرد، مانند مجموعههای تودرتو و عملیات مجموعه. (مشارکتشده توسط Serhiy Storchaka در bpo-30349.)
اکنون میتوان اشیاء عبارت باقاعدهی کامپایلشده و اشیاء تطبیق را با استفاده از copy.copy() و copy.deepcopy() کپی کرد. (مشارکتشده توسط Serhiy Storchaka در bpo-10076.)
signal¶
آرگومان جدید warn_on_full_buffer برای تابع signal.set_wakeup_fd() این امکان را فراهم میکند که مشخص کنید آیا پایتون هنگامی که بافر بیدارسازی (wakeup buffer) سرریز میشود، هشداری روی stderr چاپ میکند یا خیر. (مشارکتشده توسط Nathaniel J. Smith در bpo-30050.)
ssl¶
ماژول ssl اکنون بهجای match_hostname() از API توکار OpenSSL برای بررسی نام میزبان یا نشانی IP استفاده میکند. مقادیر در طول دستدهی TLS اعتبارسنجی میشوند. هر خطای اعتبارسنجی گواهی، از جمله شکست در بررسی نام میزبان، اکنون استثنای SSLCertVerificationError را ایجاد میکند و دستدهی را با یک پیام هشدار TLS مناسب لغو میکند. استثنای جدید حاوی اطلاعات اضافی است. اعتبارسنجی نام میزبان را میتوان با SSLContext.hostname_checks_common_name سفارشیسازی کرد. (ارائهشده توسط Christian Heimes در bpo-31399.)
نکته
بررسی بهبودیافتهی نام میزبان به پیادهسازی libssl سازگار با OpenSSL 1.0.2 یا 1.1 نیاز دارد. در نتیجه، OpenSSL 0.9.8 و 1.0.1 دیگر پشتیبانی نمیشوند (برای جزئیات بیشتر به حذف پشتیبانی از پلتفرمها مراجعه کنید). ماژول ssl عمدتاً با LibreSSL 2.7.2 و نسخههای جدیدتر سازگار است.
ماژول ssl دیگر نشانیهای IP را در افزونهی SNI از TLS ارسال نمیکند. (با مشارکت Christian Heimes در bpo-32185.)
match_hostname() دیگر از وایلدکاردهای جزئی مانند www*.example.org پشتیبانی نمیکند. (مشارکتشده توسط ماندیپ سینگ در bpo-23033 و کریستین هایمز در bpo-31399.)
انتخاب پیشفرض بدنه رمز در ماژول ssl اکنون بهجای فهرست سفید هاردکدشده، از رویکرد فهرست سیاه استفاده میکند. پایتون دیگر رمزهایی را که توسط بهروزرسانیهای امنیتی OpenSSL مسدود شدهاند، دوباره فعال نمیکند. انتخاب پیشفرض بدنه رمزها را میتوان در زمان کامپایل پیکربندی کرد. (با مشارکت کریستین هایمز در bpo-31429.)
اکنون از اعتبارسنجی گواهیهای سرور حاوی دامنههای اینترنتی بینالمللی (IDN) پشتیبانی میشود. به عنوان بخشی از این تغییر، ویژگی SSLSocket.server_hostname اکنون نام میزبان مورد انتظار را به شکل برچسب A (A-label) ("xn--pythn-mua.org") ذخیره میکند، نه به شکل برچسب U (U-label) ("pythön.org"). (با مشارکت Nathaniel J. Smith و Christian Heimes در bpo-28414.)
ماژول ssl پشتیبانی مقدماتی و آزمایشی برای TLS 1.3 و OpenSSL 1.1.1 دارد. در زمان انتشار پایتون 3.7.0، OpenSSL 1.1.1 هنوز در حال توسعه است و TLS 1.3 هنوز نهایی نشده است. دستدهی و پروتکل TLS 1.3 رفتاری کمی متفاوت از TLS 1.2 و نسخههای پیشین دارند، به TLS 1.3 مراجعه کنید. (مشارکت Christian Heimes در bpo-32947، bpo-20995، bpo-29136، bpo-30622 و bpo-33618)
SSLSocket و SSLObject دیگر سازندهی عمومی ندارند. نمونهسازی مستقیم هرگز قابلیتی مستند و پشتیبانیشده نبوده است. نمونهها باید با متدهای SSLContext یعنی wrap_socket() و wrap_bio() ایجاد شوند. (با مشارکت کریستین هایمز در bpo-32951)
APIهای OpenSSL 1.1 برای تنظیم کمینه و بیشینه نسخهی پروتکل TLS، بهصورت SSLContext.minimum_version و SSLContext.maximum_version در دسترس هستند. پروتکلهای پشتیبانیشده با چندین پرچم جدید مانند HAS_TLSv1_1 نشان داده میشوند. (مشارکتشده توسط Christian Heimes در bpo-32609.)
ssl.SSLContext.post_handshake_auth برای فعالسازی و ssl.SSLSocket.verify_client_post_handshake() برای آغاز احراز هویت پس از دستدهی در TLS 1.3 افزوده شد. (مشارکتشده توسط Christian Heimes در gh-78851.)
string¶
string.Template اکنون به شما اجازه میدهد الگوی عبارت باقاعده برای جاینگهدارهای داخل آکولاد و جاینگهدارهای بدون آکولاد را بهصورت اختیاری و بهطور جداگانه تغییر دهید. (مشارکتشده توسط Barry Warsaw در bpo-1198569.)
subprocess¶
تابع subprocess.run() آرگومان کلیدواژهای جدید capture_output را میپذیرد. در صورت درست بودن، stdout و stderr ضبط خواهند شد. این معادل ارسال subprocess.PIPE بهعنوان آرگومانهای stdout و stderr است. (مشارکتشده توسط Bo Bayles در bpo-32102.)
تابع subprocess.run و سازندهی subprocess.Popen اکنون آرگومان کلیدواژهای text را بهعنوان نام مستعاری برای universal_newlines میپذیرند. (مشارکتشده توسط Andrew Clegg در bpo-31756.)
در ویندوز، مقدار پیشفرض close_fds هنگام تغییر مسیر دستههای استاندارد از False به True تغییر یافت. اکنون میتوانید هنگام تغییر مسیر دستههای استاندارد، close_fds را روی true تنظیم کنید. subprocess.Popen را ببینید. این بدان معناست که close_fds اکنون در همهی پلتفرمهای پشتیبانیشده بهطور پیشفرض True است. (مشارکت Segev Finer در bpo-19764.)
ماژول subprocess اکنون هنگام مدیریت KeyboardInterrupt در حین subprocess.call()، subprocess.run() یا در یک مدیر زمینهی Popen رفتار مناسبتری دارد. اکنون پیش از ادامهی مدیریت استثنای KeyboardInterrupt، مدت کوتاهی برای خروج فرزند صبر میکند. (مشارکتشده توسط گرگوری پی. اسمیت در bpo-25942.)
time¶
PEP 564 شش تابع جدید با وضوح نانوثانیهای را به ماژول time اضافه میکند:
شناسههای جدید ساعت اضافه شدهاند:
time.CLOCK_BOOTTIME (Linux): یکسان با time.CLOCK_MONOTONIC است، بهجز اینکه مدتزمانی را که سیستم در حالت تعلیق است نیز شامل میشود.
time.CLOCK_PROF (FreeBSD، NetBSD و OpenBSD): زمانسنج CPU با وضوح بالا به ازای هر فرایند.
time.CLOCK_UPTIME (FreeBSD, OpenBSD): زمانی که مقدار مطلق آن برابر است با مدتزمانی که سیستم در حال اجرا بوده و به حالت تعلیق درنیامده است، و اندازهگیری دقیق زمان کارکرد (uptime) را فراهم میکند.
از توابع جدید time.thread_time() و time.thread_time_ns() میتوان برای بهدستآوردن اندازهگیریهای زمان CPU به ازای هر نخ استفاده کرد. (مشارکتشده توسط آنتوان پیترو در bpo-32025.)
تابع جدید time.pthread_getcpuclockid() شناسه ساعتِ زمان CPU مخصوصِ نخ را برمیگرداند.
tracemalloc¶
tracemalloc.Traceback رفتاری شبیهتر به ردگیریهای معمولی دارد و فریمها را از قدیمیترین به جدیدترین مرتب میکند. Traceback.format() اکنون limit منفی را میپذیرد و نتیجه را به قدیمیترین abs(limit) فریم اسلایس میدهد. برای به دست آوردن رفتار پیشین، از آرگومان جدید most_recent_first در Traceback.format() استفاده کنید. (مشارکتشده توسط جسی باکر در bpo-32121.)
unicodedata¶
پایگاه دادهی داخلی unicodedata برای استفاده از Unicode 11 ارتقا یافته است. (با مشارکت Benjamin Peterson.)
unittest¶
گزینه جدید خط فرمان -k اجازه میدهد آزمونها بر اساس زیررشتهای از نام یا الگویی شبیه پوسته یونیکس پالایش شوند. برای مثال، python -m unittest -k foo آزمونهای foo_tests.SomeTest.test_something و bar_tests.SomeTest.test_foo را اجرا میکند، اما bar_tests.FooTest.test_something را اجرا نمیکند. (مشارکتشده توسط Jonas Haag در bpo-32071.)
unittest.mock¶
ویژگیهای sentinel اکنون هنگامی که کپی یا پیکل میشوند، همانی خود را حفظ میکنند. (مشارکتشده توسط Serhiy Storchaka در bpo-20804.)
تابع جدید seal() امکان مهر و موم کردن نمونههای Mock را فراهم میکند؛ این کار ایجاد ماکهای ویژگی بیشتر را ممنوع میکند. مهر و موم بهصورت بازگشتی به تمام ویژگیهایی که خود ماک هستند اعمال میشود. (مشارکت Mario Corchero در bpo-30541.)
تابع uu.encode() اکنون یک آرگومان کلیدواژهای اختیاری backtick را میپذیرد. وقتی درست باشد، صفرها بهجای فاصلهها با '`' نمایش داده میشوند. (مشارکتشده توسط Xiang Zhang در bpo-30103.)
uuid¶
ویژگی جدید UUID.is_safe اطلاعاتی را از پلتفرم دربارهی اینکه آیا UUIDها با روشی چندپردازشایمن تولید میشوند یا خیر، منتقل میکند. (مشارکتشده توسط بری ورشو در bpo-22807.)
uuid.getnode() اکنون آدرسهای MAC با مدیریت همگانی (universally administered) را به آدرسهای MAC با مدیریت محلی (locally administered) ترجیح میدهد. این کار تضمین بهتری برای یکتایی سراسری UUIDهایی که از uuid.uuid1() بازگردانده میشوند فراهم میکند. اگر فقط آدرسهای MAC با مدیریت محلی در دسترس باشند، نخستین مورد یافتشده از آنها بازگردانده میشود. (مشارکت Barry Warsaw در bpo-32107.)
warnings¶
مقداردهی اولیهی فیلترهای پیشفرض هشدارها به شرح زیر تغییر کرده است:
هشدارهایی که از طریق گزینههای خط فرمان فعال میشوند (از جمله هشدارهای مربوط به -b و گزینهی جدید -X dev که مخصوص سیپایتون است) همیشه از طریق ویژگی sys.warnoptions به سازوکار هشدارها منتقل میشوند.
فیلترهای هشدار که از طریق خط فرمان یا محیط فعال شدهاند، اکنون ترتیب تقدم زیر را دارند:
فیلتر BytesWarning برای -b (یا -bb)
هر فیلتری که با گزینهی -W مشخص شده است
هر فیلتری که با متغیر محیطی PYTHONWARNINGS مشخص شده باشد
سایر فیلترهای مخصوص سیپایتون (مثلاً فیلتر default افزودهشده برای حالت جدید -X dev)
هر فیلتر ضمنی که مستقیماً توسط سازوکار هشدارها تعریف شده است
در ساختهای اشکالزدایی سیپایتون، اکنون همهی هشدارها بهطور پیشفرض نمایش داده میشوند (فهرست پالایههای ضمنی خالی است)
(با مشارکت Nick Coghlan و Victor Stinner در bpo-20361، bpo-32043 و bpo-32230.)
هشدارهای منسوخشدن بار دیگر بهصورت پیشفرض در اسکریپتهای تکپروندهای و در اعلان تعاملی نمایش داده میشوند. برای جزئیات به PEP 565: نمایش DeprecationWarning در __main__ مراجعه کنید. (مشارکتشده توسط Nick Coghlan در bpo-31975.)
xml¶
برای کاهش خطر بازیابی DTD و موجودیتهای خارجی، ماژولهای xml.dom.minidom و xml.sax دیگر بهطور پیشفرض موجودیتهای خارجی را پردازش نمیکنند. (مشارکت Christian Heimes در gh-61441.)
xml.etree¶
محمولهای ElementPath در متدهای find() اکنون میتوانند متن گره فعلی را با [. = "text"] مقایسه کنند، نه فقط متن فرزندان. محمولها همچنین اجازه میدهند برای خوانایی بهتر فاصله افزوده شود. (مشارکتشده توسط Stefan Behnel در bpo-31648.)
xmlrpc.server¶
SimpleXMLRPCDispatcher.register_function() اکنون میتواند بهعنوان دکوراتور استفاده شود. (مشارکتشده توسط Xiang Zhang در bpo-7769.)
zipapp¶
تابع create_archive() اکنون یک آرگومان filter اختیاری را میپذیرد تا به کاربر اجازه دهد انتخاب کند کدام پروندهها باید در آرشیو گنجانده شوند. (مشارکتشده توسط Irmen de Jong در bpo-31072.)
تابع create_archive() اکنون یک آرگومان اختیاری compressed را برای تولید بایگانی فشرده میپذیرد. یک گزینهی خط فرمان --compress نیز برای پشتیبانی از فشردهسازی افزوده شده است. (مشارکتشده توسط Zhiming Wang در bpo-31638.)
zipfile¶
ZipFile اکنون پارامتر جدید compresslevel را برای کنترل سطح فشردهسازی میپذیرد. (با مشارکت Bo Bayles در bpo-21417.)
زیرپوشهها در آرشیوهای ایجادشده توسط ZipFile اکنون به ترتیب الفبایی ذخیره میشوند. (مشارکتشده توسط Bernhard M. Wiedemann در bpo-30693.)
بهینهسازیها¶
سربار فراخوانی بسیاری از متدهای کلاسهای مختلف کتابخانه استاندارد که به زبان C پیادهسازی شدهاند، با انتقال کد بیشتر برای استفاده از قرارداد METH_FASTCALL بهطور چشمگیری کاهش یافته است. (مشارکتشده توسط Victor Stinner در bpo-29300، bpo-29507، bpo-29452 و bpo-29286.)
بهینهسازیهای گوناگون زمان راهاندازی پایتون را در لینوکس به میزان ۱۰٪ و در macOS تا ۳۰٪ کاهش دادهاند. (مشارکتشده توسط Victor Stinner و INADA Naoki در bpo-29585، و Ivan Levkivskyi در bpo-31333.)
فراخوانی متدها اکنون به دلیل تغییرات بایتکدی که از ایجاد نمونههای متد مقید جلوگیری میکنند، تا ۲۰٪ سریعتر شده است. (با مشارکت Yury Selivanov و INADA Naoki در bpo-26110.)
ماژول asyncio تعدادی بهینهسازی قابل توجه برای توابع پرکاربرد دریافت کرد:
در نتیجهی کار روی PEP 560، زمان ایمپورت typing به میزان ۷ برابر کاهش یافته است و بسیاری از عملیاتهای typing اکنون سریعتر شدهاند. (مشارکتشده توسط Ivan Levkivskyi در bpo-32226.)
sorted() و list.sort() برای موارد رایج بهینهسازی شدهاند و تا ۴۰ تا ۷۵ درصد سریعتر هستند. (با مشارکت Elliot Gorokhovsky در bpo-28685.)
dict.copy() اکنون تا ۵.۵ برابر سریعتر شده است. (مشارکتشده توسط یوری سلیوانوف در bpo-31179.)
hasattr() و getattr() اکنون وقتی name یافت نشود و obj object.__getattr__() یا object.__getattribute__() را بازنویسی نکند، حدود ۴ برابر سریعتر هستند. (مشارکت INADA Naoki در bpo-32544.)
جستجوی برخی نویسههای یونیکد (مانند حرف بزرگ اوکراینی «Є») در یک رشته، تا ۲۵ بار کندتر از جستجوی نویسههای دیگر بود. اکنون در بدترین حالت تنها ۳ بار کندتر است. (مشارکت Serhiy Storchaka در bpo-24821.)
تابع کارخانهای collections.namedtuple() بازپیادهسازی شده است تا ساخت تاپلهای نامدار ۴ تا ۶ برابر سریعتر شود. (مشارکتشده توسط Jelle Zijlstra و با بهبودهای بیشتر از سوی INADA Naoki، Serhiy Storchaka و Raymond Hettinger در bpo-28638.)
datetime.date.fromordinal() و datetime.date.fromtimestamp() اکنون در حالت رایج تا ۳۰٪ سریعتر هستند. (مشارکتشده توسط Paul Ganssle در bpo-32403.)
تابع os.fwalk() اکنون به لطف استفاده از os.scandir() تا ۲ برابر سریعتر شده است. (مشارکتشده توسط Serhiy Storchaka در bpo-25996.)
سرعت تابع shutil.rmtree() با استفاده از تابع os.scandir() به میزان ۲۰--۴۰٪ بهبود یافته است. (مشارکتشده توسط Serhiy Storchaka در bpo-28564.)
بهینهسازی تطبیق و جستجوی بدون حساسیت به بزرگی و کوچکی حروف در عبارتهای باقاعده. جستجوی برخی از الگوها اکنون میتواند تا ۲۰ برابر سریعتر باشد. (مشارکتشده توسط Serhiy Storchaka در bpo-30285.)
re.compile() اکنون پارامتر flags را در صورتی که RegexFlag باشد به شیء int تبدیل میکند. سرعت آن اکنون برابر با پایتون 3.5 است و بسته به الگو، حدود ۱۰٪ سریعتر از پایتون 3.6 است. (مشارکتشده توسط INADA Naoki در bpo-31671.)
متدهای modify() از کلاسهای selectors.EpollSelector، selectors.PollSelector و selectors.DevpollSelector ممکن است تحت بارهای سنگین حدود ۱۰٪ سریعتر باشند. (مشارکتشده توسط Giampaolo Rodola' در bpo-30014)
تاشدگی ثابت (constant folding) از بهینهساز پنجرهای (peephole optimizer) به بهینهساز جدید درخت سینتکس انتزاعی (AST) منتقل شده است که میتواند بهینهسازیها را با سازگاری بیشتری انجام دهد. (ارائه شده توسط Eugene Toder و INADA Naoki در bpo-29469 و bpo-11549.)
بیشتر توابع و متدهای abc به زبان C بازنویسی شدهاند. این کار ایجاد کلاسهای پایه انتزاعی و فراخوانی isinstance() و issubclass() روی آنها را ۱٫۵ برابر سریعتر میکند. همچنین زمان راهاندازی پایتون را تا ۱۰ درصد کاهش میدهد. (مشارکت Ivan Levkivskyi و INADA Naoki در bpo-31333)
بهبودهای چشمگیر سرعت در سازندههای جایگزین datetime.date و datetime.datetime از طریق استفاده از سازندههای مسیر سریع (fast-path) در حالتی که زیرکلاسی ساخته نمیشود. (مشارکت Paul Ganssle در bpo-32403)
سرعت مقایسهی نمونههای array.array در موارد خاصی بهطور قابلتوجهی بهبود یافته است. اکنون هنگام مقایسهی آرایههایی که مقادیری از یک نوع عدد صحیح در خود دارند، از ۱۰ تا ۷۰ برابر سریعتر است. (مشارکتشده توسط Adrian Wielgosik در bpo-24700.)
توابع math.erf() و math.erfc() اکنون در بیشتر پلتفرمها از پیادهسازی (سریعتر) کتابخانهی C استفاده میکنند. (مشارکتشده توسط Serhiy Storchaka در bpo-26121.)