JIT آزمایشی پایتون حذف می شود

به LWN.net خوش آمدید محتوای زیر فقط برای اشتراک توسط یک مشترک LWN در دسترس شما قرار گرفته است. هزاران مشترک برای دریافت بهترین اخبار از جوامع لینوکس و نرم افزار رایگان به LWN وابسته هستند. اگر از این مقاله لذت می برید، لطفا اشتراک LWN را در نظر بگیرید. از اینکه از LWN.net بازدید کردید متشکریم! توسط Joe Brockmeier 26 اکتبر 2026 کامپایلر آزمایشی به موقع پایتون (JIT) که در سال 2024 برای نسخه 3.13 به CPython اضافه شد، در راه است.

در ماه ژوئن، شورای راهبری پایتون اعلام کرد که کار بر روی JIT در شعبه اصلی CPython را متوقف می کند تا زمانی که یک پیشنهاد افزایش پایتون (PEP) پذیرفته شود که به نگرانی ها در مورد تعمیر و نگهداری، سازگاری، و تعیین معیارهای موفقیت واضح و همچنین جدول زمانی برای تکمیل پرداخت. پس از ایجاد PEP 836 ("JIT Go Brrr: The Path to a Supported JIT Compiler for CPython") برای پاسخگویی به درخواست شورا، و پس از ماه ها بحث، نگهبانان JIT PEP را پس گرفتند. در حال حاضر، به نظر می رسد که توسعه پروژه زمانی امیدوارکننده به پایان رسیده است.

JIT در اوایل سال 2024 توسط Brandt Bucher به CPython اضافه شد. به طور کلی، انتظار می‌رود که چنین ویژگی مهمی تنها پس از تصویب PEP استاندارد پیگیری توسط شورا به وجود بیاید. بوچر یک سخنرانی (ویدیو یوتیوب، اسلایدها) در مورد JIT در یک برنامه توسعه دهنده هسته پایتون انجام داده بود و قصد خود را برای ادغام این ویژگی اعلام کرده بود - اما او قدمی برای نگارش یا ارسال PEP برای تایید آن برنداشته بود. توماس واترز، عضو شورای راهبری، که به عنوان مدیر انتشار پایتون 3.13 نیز خدمت می کرد، او را به انجام این کار تشویق کرد.

Bucher و Savannah Ostrowski پیش‌نویس PEP 744 ("جمع‌آوری JIT") را تهیه کردند که یک PEP اطلاعاتی بود - به این معنی که فقط اطلاعات را در اختیار جامعه پایتون قرار می‌دهد و اجماع رسمی برای ادامه روی یک ویژگی یا پروژه را نشان نمی‌دهد. LWN بحث PEP 744 را در آوریل 2024 پوشش داد، و بعدا سخنرانی بوچر در مورد JIT در PyCon US 2024، و همچنین صحبت های بعدی در PyCon US 2025 را پوشش داد.

کار بر روی JIT تا ژوئن امسال بر اساس PEP 744 ادامه داشت، زمانی که شورا درخواست رسمی خود را از نگهبانان JIT برای ایجاد یک PEP ردیابی استاندارد ارائه کرد. ممکن است کسی بپرسد، همانطور که آنتوان پیترو کرد، چرا شورا تصمیم گرفته است که زمان صحبت کردن و درخواست یک PEP جدید است. واترز گفت که هیچ "رویداد محرک واحدی برای این درخواست" وجود نداشت، اما شورا مدتی در مورد این موضوع بحث می کرد و نشان داد که به دنبال اطمینان از عدم تداخل کار JIT با پروژه های دیگر است.

تلاش‌هایی برای اینکه JIT با ابزار دقیق، اشکال‌زدایی و نمایه‌سازی به خوبی اجرا شود، وجود دارد. همچنین JIT‌های خارجی (مانند CinderX)، چیزهای مجاور JIT (مانند کامپایل Numba و PyTorch) و بحث‌هایی در مورد JIT سطح 3 وجود دارد.» شورا منتظر بود تا پس از Python 3.15 برای انتشار نسخه OK15 وضعیت ما مشخص شود. ".

شورا درخواست یک PEP کرد که برای JIT "به عنوان یک بخش غیر آزمایشی و پشتیبانی شده CPython: تضمین های آن، تعهدات تعمیر و نگهداری و تاثیر آن بر توزیع کنندگان مجدد" مورد استفاده قرار گیرد. شورا مهلت شش ماهه ای را برای ارسال و پذیرش PEP تعیین کرد. در صورت عدم موفقیت، شورا باید کد JIT را از شاخه اصلی CPython حذف کند.

بوچر، اوستروفسکی و کن جین پیش‌نویس PEP 836 را تهیه کردند و آن را در انجمن پایتون برای بازخورد جامعه در 3 ژوئیه منتشر کردند. بحث‌های بسیار کمی ایجاد کرد، برخی مطلوب و برخی انتقادی. یکی از موضوعات کلیدی در نظرات، مانند این مورد توسط Wouters، و این نظر مارک شانون، این بود که پیش نویس احساس می کرد باید دو PEP جداگانه باشد. به عنوان مثال، شانون فکر می کرد که PEP فقط باید اهداف پذیرش کار JIT را پوشش دهد و احساس می کرد که باید جزئیات پیاده سازی را کنار بگذارد. همچنین چندین تماس برای کسب اطلاعات بیشتر وجود داشت.

بوچر از این پیشنهاد که باید دو PEP باشد کمی عقب نشینی کرد و اوستروفسکی از ساختار PEP همانطور که بود دفاع کرد. "تشریح اهدافی مانند آنچه در PEP داریم بدون اینکه بتوانیم برنامه را به اشتراک بگذاریم و همه چیزهایی که در کنار آن فکر کرده ایم باعث ناراحتی من می شود. برای من اهداف بدون برنامه پشت سر آنها واقعا هدف نیستند."

وقتی آخرین بار در سپتامبر به این موضوع نگاه کردیم، بحث در مورد PEP بدون تعهد به توسعه PEP های جدید یا بیانیه رسمی شورا کند شده بود. آخرین حرف شورا در آن زمان، در قالب خلاصه‌ای از جلسه 6 آگوست، این بود که با نویسندگان PEP ملاقات کرده بود و در حال "بحث در مورد وضعیت PEP و اینکه آیا این شورا به سوالاتی که SC در درخواست خود برای PEP پرسیده بود، پاسخ داد یا خیر".

در 21 سپتامبر، ووترز بیانیه ای از شورای راهبری، منهای اوستروفسکی (که در حال حاضر یکی از اعضای شورای راهبری است، اما از آنجایی که یکی از نویسندگان مشترک PEP است، در آن شرکت نکرد) منتشر کرد که موضع آن را خلاصه می کرد. در این بیانیه آمده است که PEP به تمام سوالاتی که در درخواست شورا برجسته شده بود، پاسخ داد، "اگرچه شاید برخی از آنها کمتر متقاعد کننده تر از دیگران باشند".

شورا می خواست روشن کند که به دنبال معیارهایی نیست که JIT باید دارای آن باشد تا یک ویژگی پشتیبانی شده باشد یا اینکه آیا باید چنین تلقی شود. در عوض، شورا در حال ارزیابی بود که آیا JIT باید به عنوان یک آزمایش در شاخه اصلی CPython ادامه یابد یا خیر.

شورا گفت که PEP به اندازه کافی در مورد برنامه های حمایتی، معیارهای عملکرد، و در مورد تعدادی از زمینه های دیگر خیلی مبهم یا خیلی خوش بینانه نیست. این بیانیه شامل فهرست ده ماده‌ای از مواردی بود که شورا می‌خواست «یا در PEP مشخص شود، یا حداقل مورد بحث و بررسی قرار گرفته و رد شود». فهرست شورا نگرانی‌هایی از تأثیر حافظه گرفته تا امنیت را بیان می‌کرد. به عنوان مثال، در موضوع برابری پلت فرم، شورا می خواست اطمینان حاصل کند که JIT به گونه ای طراحی شده است که به راحتی برای پلتفرم های جدید به کار گرفته شود.

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

حوزه دیگری که شورا به آن اشاره کرد تأثیر کاربر بود. گفته می‌شود که PEP نسبت به تفاوت‌های قابل مشاهده توسط کاربر با JIT فعال «بیش از حد خوش‌بین» است. موارد زیادی وجود داشت که کاربران به ویژگی‌های منحصر به فرد در طراحی مفسر وابسته بودند، "همانطور که در مورد سایر پیاده‌سازی‌های پایتون یا حتی فقط بین نسخه‌های اصلی پایتون دیده‌ایم"، و خواستار توضیح در مورد نحوه رسیدگی به این تفاوت‌ها بود. آیا آنها را اشکال در نظر می گیرند، اگر تفاوت در رفتار اجتناب ناپذیر بود، چگونه با موقعیت ها برخورد می شود و غیره.

به گفته شورا، امنیت "منطقه ای تحت حمایت PEP" بود. پیشنهاد می‌کند که بحث با تیم پاسخ امنیتی پایتون مناسب است و بررسی امنیتی باید بخشی از معیارهای وضعیت پشتیبانی نیز باشد.

PEP 836 یک نقطه عطف بررسی سازگاری را برای مطابقت با اولین نامزد انتشار Python 3.17 مشخص کرد - که در آگوست 2028 انتظار می رود - که شامل اجرای مجموعه های آزمایشی بسته های برتر PyPI برای دیدن اینکه آیا JIT آنها را شکست می دهد یا خیر. شورا می خواست این جدول زمانی به میزان قابل توجهی افزایش یابد. "ما فکر می کنیم که خیلی دیر است، و بررسی سازگاری باید یک روند مداوم و مستمر باشد که در اسرع وقت شروع شود."

شورا همچنین نگران این بود که تصمیمات طراحی JIT "بدون بررسی انتقادی توسط گروه بزرگتری از توسعه دهندگان که در نهایت مسئولیت توسعه، نگهداری و پشتیبانی [CPython] را بر عهده دارند" گرفته شود. به گفته آن، نتیجه نهایی این بود که PEP 836 "بیشتر به سوالاتی که ما پرسیده ایم پاسخ می دهد" بدون هیچ قطعه از دست رفته ای، اما می خواست بحث بیشتری در مورد آن موضوعات داشته باشد تا بتواند "قبل از اینکه از ما خواسته شود در مورد این PEP اظهار نظر کنیم، حمایت و اجماع جامعه را بسنجد".

جین چند روز بعد پاسخ داد و از شورا برای بازخورد دقیقش تشکر کرد و گفت که گروه روی پیشنهاداتش کار خواهد کرد.

به نظر می‌رسد پس از بررسی، نویسندگان PEP تصمیم گرفته‌اند که به دنبال تصویب شورا نباشند. در 19 اکتبر، Ostrowski (که همچنین مدیر انتشار Python 3.16 و 3.17 است) اعلام کرد که PEP در حال خارج شدن است:

بری اسکات پرسید که آیا این بدان معناست که کار روی JIT متوقف شده است؟ برت کانن پاسخ داد که کار در مخزن اصلی متوقف خواهد شد، اما این به جامعه بستگی دارد که آیا کار در جای دیگری ادامه خواهد یافت. دانک گراهام پیشنهاد کرد که ممکن است زمانی برای ارائه یک PEP جایگزین قبل از مهلت شورا وجود داشته باشد. کانن گفت که این محتمل نیست، "زیرا همه افرادی که به طور فعال JIT را هدایت می کنند، یا نویسندگان آن PEP یا مشارکت کنندگان در آن بودند".

با برداشته شدن PEP، JIT احتمالا به زودی از اصلی CPython حذف خواهد شد تا اطمینان حاصل شود که مشکلات ناشی از حذف آن در اوایل چرخه توسعه Python 3.16 قابل رسیدگی است. مشخص نیست که آیا گردانندگان اصلی کار JIT اصلا قصد ادامه کار بر روی آن را دارند یا اینکه در صورت وجود علاقه کافی جامعه، صرفا به دیگران واگذار می شود تا آن را انتخاب کنند. من برای توضیح بیشتر به نویسندگان PEP ایمیل زده ام، اما هنوز پاسخی دریافت نکرده ام.

به نظر مدنی ارسال شده در 26 اکتبر 2026 ساعت 21:54 UTC (دوشنبه) توسط ballombe (مشترک، #9523) [ پیوند ] (3 پاسخ)

به نظر مدنی ارسال شده در 27 اکتبر 2026 ساعت 1:53 UTC (سه شنبه) توسط acarno (مشترک، #123476) [ پیوند ]

برای یک چیز، pypy فقط پایتون 3.12، 3.11 و 2.7 را پشتیبانی می کند. مهمتر از آن، pypy CPython نیست - این یک پیاده سازی جایگزین است که عمدتا سازگار است اما با چند تفاوت قابل توجه (وب سایت pypy این موارد را فهرست می کند). این یک JIT را مستقیما به CPython (اجرای مرجع) اضافه می کرد، به این معنی که تمام نسخه های جدید Python - و همه ماژول های موجود و غیره - به کامپایل JIT دسترسی دارند. به قول خود نویسندگان PEP 836:

پیاده سازی های جایگزین پایتون، مانند PyPy و GraalPy، نشان می دهد که افزایش سرعت بیشتر برای برخی از برنامه های پایتون امکان پذیر است و ما عمیقا برای این پروژه ها ارزش قائل هستیم. با این حال، بسیاری از کاربران نمی‌توانند زمان اجرای جایگزینی را انتخاب کنند، حتی زمانی که ممکن است به دلیل عواملی مانند نسخه‌های پایتون پشتیبانی‌شده، سازگاری برنامه‌های افزودنی، الزامات جاسازی، محدودیت‌های استقرار و پشتیبانی از ابزار، عملکرد بهتری روی کدشان داشته باشد.

به نظر مدنی ارسال شده در 27 اکتبر 2026 ساعت 14:15 UTC (سه شنبه) توسط markkitt (مهمان، #181598) [ پیوند ] (1 پاسخ)

به نظر مدنی ارسال شده در 27 اکتبر 2026 ساعت 14:45 UTC (سه شنبه) توسط LtWorf (مشترک، #124958) [ پیوند ]

آزمایش در اصل؟ ارسال شده در 27 اکتبر 2026 ساعت 12:26 UTC (سه شنبه) توسط مارس (مشترک، #57642) [ پیوند ] (2 پاسخ)

با عرض پوزش اگر آن را از دست دادم: چرا این اتفاق در شعبه اصلی رخ داد؟ تضادهای بیش از حد زیادی با تغییرات دیگر نیز در اصل اتفاق می افتد؟ (برای توجیه IMHO کافی نیست، اما می تواند توضیح دهد) > [بررسی سازگاری] که شامل اجرای مجموعه های آزمایشی بسته های برتر PyPI برای دیدن اینکه آیا JIT آنها را خراب کرده است یا خیر. شورا می خواست این جدول زمانی به میزان قابل توجهی افزایش یابد. "ما فکر می کنیم که [آگوست 2028] خیلی دیر است، و بررسی سازگاری باید یک روند مداوم و مستمر باشد که در اسرع وقت شروع شود."

شاید دوباره چیزی را از دست بدهم، اما این برای شعبه اصلی عادی و مورد انتظار به نظر می رسد - حتی اگر به طور پیش فرض فعال نباشد. من شخصا آن را زیاد تجربه نکردم اما رگرسیون ها (در نسخه های اصلی) به نظر یک شکایت نسبتا مکرر در مورد پایتون است... آزمایش در اصل؟ ارسال شده در 27 اکتبر 2026 ساعت 12:46 UTC (سه شنبه) توسط mathstuf (مشترک، #69389) [ پیوند ]

من فکر می کنم ممکن است، اما استفاده باید سیگنالی داشته باشد که کاربر بداند در حال "بازی با آتش" است. روشی که ما این کار را برای CMake انجام می دهیم این است که متغیری وجود دارد که باید روی یک مقدار مشخص (یک UUID تولید شده به طور تصادفی) تنظیم شود تا آزمایش "فعال" شود (و اولین استفاده از آن هشداری در مورد فعال شدن آن ایجاد می کند). اگر مقدار صحیح نباشد، ویژگی نادیده گرفته می شود. سپس هر زمان که رفتار را به روز می کنیم، مقدار مورد انتظار را تغییر می دهیم. با این کار، پروژه ها نمی توانند از "اما ارزش دفعه قبل کار کرد!" بهانه

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

آزمایش در اصل؟ ارسال شده در 27 اکتبر 2026 ساعت 16:11 UTC (سه شنبه) توسط danilo (مهمان، #57549) [ پیوند ]