معرفیPython 3.15.0rc1 ؛ مرز بین اسکریپت نویسی و زبان Production-Grade را کمتر می‌کند

مقدمه؛ چرا Python 3.15 یک نسخه معمولی نیست؟

هر سال یک نسخه‌ی جدید پایتون منتشر می‌شود و اغلب اوقات، این انتشارها ترکیبی از چند بهبود جزئی و چند syntax sugar هستند. اما Python 3.15 از آن دسته نسخه‌هایی است که چند مسئله‌ی ساختاری و دیرینه را هم‌زمان هدف قرار داده: زمان راه‌اندازی کند، نبود ساختار داده‌ی immutable در هسته‌ی زبان، وابستگی به الگوهای دستی برای sentinel، و البته سایه‌ی سنگین GIL روی هم‌روندی. این نسخه UTF-8 را به‌عنوان encoding پیش‌فرض ورودی/خروجی در همه‌ی پلتفرم‌ها تثبیت می‌کند، یک profiler نمونه‌برداری با فرکانس بالا ارائه می‌دهد، C API جدیدی برای ساخت بافر معرفی می‌کند و پیشنهادهای AttributeError را برای اعضای تودرتو بهبود می‌بخشد.

فعلاً نسخه‌ی نهایی منتشر نشده و آنچه در دسترس است، Release Candidate اول (rc1) است.

وضعیت Python در سال ۲۰۲۶؛ رقابت سرعت، تایپ و مقیاس‌پذیری

پایتون سال‌هاست زیر فشار سه جبهه است: زبان‌های سریع‌تر مثل Rust و Go در بک‌اند، فشار برای type-safety شبیه TypeScript در پروژه‌های بزرگ، و رشد انفجاری بارهای کاری AI/ML که به هم‌روندی واقعی نیاز دارند. تیم CPython در چند سال اخیر مسیر مشخصی را دنبال کرده: افزودن JIT تجربی، آزاد کردن GIL به‌صورت اختیاری PEP 703، و اکنون تثبیت تدریجی این ابزارها. Python 3.15 نقطه‌ای است که بسیاری از این خط‌های موازی به هم می‌رسند.

Python 3.15.0rc  چیست و چرا Release Candidate اهمیت دارد؟

 Python 3.15.0rc1 اولین نسخه از دو release candidate برنامه‌ریزی‌شده است. با ورود به فاز release candidate، فقط تغییرات کد بازبینی‌شده که به‌وضوح رفع باگ باشند مجاز هستند و از این به بعد هیچ تغییری در ABI رخ نخواهد داد. به زبان ساده، rc1 یعنی فهرست ویژگی‌ها قفل شده و آنچه می‌بینید همان چیزی است که در نسخه‌ی نهایی خواهید داشت؛ فقط باگ‌ها اصلاح می‌شوند.

نسخه‌ی بعدی، rc2، برای تاریخ ۱ سپتامبر ۲۰۲۶ برنامه‌ریزی شده است و نسخه‌ی نهایی برای اکتبر ۲۰۲۶ هدف‌گذاری شده. برای توسعه‌دهندگانی که کتابخانه نگه‌داری می‌کنند، این یعنی الان زمان تست wheel های باینری در برابر rc1 است، چون از این نقطه به بعد ABI پایدار می‌ماند.

تغییرات بنیادین در موتور CPython

بهبود Interpreter

نسخه‌ی ویندوز از تفسیرگر tail-calling استفاده می‌کند که به بهبود عملکرد کلی کمک می‌کند.

  نسل جدید بهینه‌سازی‌ها

بخشی از سرعت این نسخه از بهینه‌سازی‌های سطح بایت‌کد و کاهش overhead فراخوانی‌های داخلی می‌آید، نه صرفاً از .JIT

  نقش JIT

<cite index="1-1"> کامپایلر JIT ارتقای قابل‌توجهی یافته و بهبود عملکرد ۸ تا ۹ درصدی (geometric mean) روی x86-64 لینوکس نسبت به تفسیرگر استاندارد، و ۱۲ تا ۱۳ درصد سرعت بیشتر روی AArch64 مک روی نسبت به تفسیرگر tail-calling ارائه می‌دهد.  این JIT  هنوز تجربی است، اما فاصله‌اش با production کوچک‌تر شده است.

Lazy Imports؛ آیا مشکل کندی Startup بالاخره حل می‌شود؟

مهم‌ترین ویژگی این نسخه از نظر بسیاری از توسعه‌دهندگان، PEP 810 است. این نسخه با کلیدواژه‌ی lazy برای بارگذاری معوق ماژول‌ها معرفی می‌شود که طبق گزارش تیم توسعه می‌تواند زمان راه‌اندازی را تا ۷۰ درصد در کدبیس‌های بزرگ در شرکت‌هایی مثل Meta کاهش دهد.

عملاً این یعنی import هایی که در نوک فایل نوشته می‌شوند اما بلافاصله استفاده نمی‌شوند، تا لحظه‌ی نیاز واقعی بارگذاری نمی‌شوند. برای پروژه‌های بزرگ با صدها ماژول وابسته مثلاً یک مونولیت Django یا یک سرویس داده با ده‌ها کتابخانه‌ی سنگین مثل pandas، این تفاوت به‌شدت محسوس است.

frozendict؛ ورود رسمی Immutable Data Structures به هسته پایتون

 PEP 814 نوع built-in به‌نام frozendict را اضافه می‌کند .تا امروز، برنامه‌نویسان برای دیکشنری غیرقابل‌تغییر یا از types.MappingProxyType  استفاده می‌کردند یا کتابخانه‌ی شخص‌ثالث. اکنون frozendict به‌عنوان نوع درجه‌یک زبان در دسترس است ، نکته‌ای که برای الگوهای functional، کش‌کردن ایمن و پاس‌دادن config های immutable بین thread ها به‌خصوص در دنیای  free-threaded اهمیت دارد.

Sentinel استاندارد؛ پایان الگوهای قدیمی object()

 PEP 661 نوع built-in sentinel را اضافه می‌کند. الگوی رایج _MISSING = object()  برای نشان‌دادن «مقدار داده نشده» اکنون یک معادل رسمی و قابل serialize/repr در استاندارد کتابخانه دارد. تغییر کوچکی است اما دردی واقعی را در APIهای عمومی (مثل پارامترهای پیش‌فرض توابع) رفع می‌کند.

تحول Type System و آینده پایتون تایپ‌محور

پایتون تایپ‌محور دیگر یک گرایش حاشیه‌ای نیست، بلکه استاندارد de facto در تیم‌های بزرگ شده است. (TypeForm) طبق PEP 747 نحوی درجه‌یک برای annotate کردن  type expressionها فراهم می‌کند که برای ابزارهایی مثل mypy و pyright که خودشان type را به‌عنوان مقدار پاس می‌دهند، اهمیت زیادی دارد.

TypedDict ، TypeForm  و تأثیر آن‌ها روی پروژه‌های بزرگ

 TypedDict قابلیت closed و extra_items را طبق PEP 728 دریافت می‌کند. این یعنی توسعه‌دهنده می‌تواند صراحتاً مشخص کند که یک  TypedDict اجازه‌ی کلیدهای اضافی دارد یا خیر ، مشکلی که تا امروز باعث false negative های زیاد در type checkerها هنگام کار با پاسخ‌های API یا داده‌های JSON می‌شد.

همچنین ماژول جدید math.integer توابع مختص اعداد صحیح را در یک‌جا گرد می‌آورد .(PEP 791)

Profiling و Observability ؛ پایتون برای Production آماده‌تر می‌شود

یک بسته‌ی profiling اختصاصی برای سازمان‌دهی ابزارهای profiling پایتون اضافه شده و درون آن، Tachyon به‌عنوان یک نمونه‌بردار آماری با فرکانس بالا معرفی می‌شود. Tachyon می‌تواند تا فرکانس یک میلیون هرتز نمونه‌برداری کند، با overhead نزدیک به صفر به یک پردازش در حال اجرا متصل شود، و خروجی‌هایی مانند flamegraph، فایل‌های سازگار با Gecko در فایرفاکس و یک TUI زنده تولید کند.

علاوه بر این،  frame pointer ها به‌صورت پیش‌فرض برای بهبود observability  در سطح سیستم فعال شده‌اند (PEP 831) .این یعنی ابزارهای سیستمی مثل perf در لینوکس می‌توانند بدون نیاز به build سفارشی، استک فراخوانی پایتون را با دقت بیشتری ببینند قابلیتی حیاتی برای دیباگ عملکرد در محیط‌های production در مقیاس بزرگ.

UTF-8 پیش‌فرض؛ پایان یکی از مشکلات قدیمی Cross-platform

طبق PEP 686، عملیات text I/O بدون تعیین صریح encoding اکنون به‌صورت پیش‌فرض از UTF-8 استفاده می‌کند و این رفتار عجیب مختص ویندوز را از بین می‌برد؛ این رفتار با متغیر محیطی PYTHONUTF8 = 0) ) قابل غیرفعال‌سازی است .برای تیم‌هایی که کد را روی ویندوز و لینوکس/مک هم‌زمان اجرا می‌کنند، این یکی از قدیمی‌ترین منابع باگ‌های ناسازگار encoding را حذف می‌کند.

تغییرات C API و تأثیر آن بر  Extensionها

این نسخه C API جدیدی به‌نام PyBytesWriter برای ساخت بافر به‌شکل کارآمدتر معرفی می‌کند. نگهدارندگان extensionهای  C/Cython/pybind11  باید توجه داشته باشند که با ورود به فاز rc، دیگر تغییری در ABI رخ نخواهد داد، پس الان بهترین زمان برای build و انتشار wheel های سازگار با 3.15 است.

Free-threading ؛ آیا دوران محدودیت‌های GIL نزدیک است؟

اینجا باید واقع‌بین بود Python 3.15 :هنوز GIL را به‌صورت پیش‌فرض حذف نمی‌کند .با تصویب PEP 779، تفسیرگر

 free-threaded از Python 3.14 دیگر تجربی محسوب نمی‌شود، هرچند هنوز build پیش‌فرض تفسیرگر نیست.

در build آزاد از GIL، هنگام import یک ماژول C-API که صراحتاً پشتیبانی از free threading را اعلام نکرده، ممکن است GIL به‌صورت خودکار دوباره فعال شود و در این حالت هشداری چاپ می‌شود .یعنی اکوسیستم هنوز در حال catch-up است هر کتابخانه‌ی C که آپدیت نشده باشد، عملاً free-threading را خنثی می‌کند.

از نظر کارایی،  buildآزاد از GIL هنگام اجرای کد پایتون overhead بیشتری نسبت به build پیش‌فرض دارد و این overhead بسته به بار کاری و سخت‌افزار متفاوت است؛ در benchmark مجموعه‌ی pyperformance، این overhead به‌طور میانگین از حدود ۱ درصد در  macOS aarch64  تا ۸ درصد در سیستم‌های x86-64 لینوکس متغیر است .بنابراین free-threading رایگان نیست؛ یک trade-off بین موازی‌سازی واقعی و سرعت تک‌رشته‌ای است.

Python 3.15 در برابر  Python 3.14؛ چه چیزی واقعاً تغییر کرده؟

نقاط قوت Python 3.15

·       کاهش واقعی و قابل‌اندازه‌گیری زمان startup برای پروژه‌های بزرگ

·       ابزارهای profiling درجه‌یک و آماده‌ی production (Tachyon)

·       بلوغ تدریجی و بدون‌شتاب type system، بدون شکستن سازگاری

·       رفع دردهای قدیمی encoding)، (sentinel بدون نیاز به کتابخانه‌ی شخص‌ثالث

·       ABI  پایدار از rc1 به بعد، یعنی ریسک کمتر برای maintainerها

نقاط ضعف و نگرانی‌های مهاجرت

·       free-threading هنوز default نیست و خیلی از C extensionها آماده نیستند

·       JIT  هنوز experimental است و برای همه‌ی بارهای کاری سود یکسان ندارد

·       lazy imports  می‌تواند رفتار برنامه‌هایی را که به side effect زمان import متکی‌اند تغییر دهد(باید صراحتاً با کلیدواژه‌ی lazy فعال شود، اما تیم‌ها باید الگوهای import خود را بازبینی کنند)

·       برای تیم‌هایی با کتابخانه‌های  legacy C، باز هم لازم است صبر کرد تا ecosystem کامل sync شود

آیا توسعه‌دهندگان باید به Python 3.15 مهاجرت کنند؟

برای پروژه‌های production در حال حاضر: هنوز نه با نسخه‌ی rc اما اکنون بهترین زمان برای:

·       تست کدبیس در برابر rc1)بدون تغییر ABI بیشتر)

·       ساخت و انتشار wheel های سازگار روی  PyPI

·       ارزیابی سود lazy imports روی زمان startup واقعی پروژه

برای پروژه‌های جدید یا کتابخانه‌های در حال توسعه: بله، ارزش برنامه‌ریزی برای سازگاری را دارد، مخصوصاً اگر پروژه به CLI tool یا سرویسی با startup مکرر وابسته باشد.

آینده پایتون بعد از نسخه 3.15

روند مشخص است JIT :قوی‌تر می‌شود، free-threading  به سمت default  حرکت می‌کند (هرچند احتمالاً نه در 3.15 یا حتی 3.16)، و type system  همچنان به سمت TypeScript-like بودن پیش می‌رود. Lazy imports  و frozendict نشان می‌دهند CPython دیگر فقط دنبال syntax sugar نیست، بلکه مشکلات ساختاری واقعی مقیاس بزرگ را هدف قرار داده است.

  چکیده مقاله