Розробку вбудованого JIT-компілятора для CPython, основного інтерпретатора мови Python, зупиняють в основній гілці проєкту. Рада з управління Python (Steering Council) не отримала від розробників чіткого плану того, хто і як підтримуватиме цю технологію в довгостроковій перспективі. Про це повідомляє InfoWorld, а на сайті Highload.tech з’явилася відповідна новина.
Нагадаємо, що в червні 2026 року рада проєкту офіційно призупинила роботу над JIT. Умова полягала в тому, що проєкт відновлять лише після затвердження пропозиції PEP, яка пояснить, як перетворити експеримент на повноцінну, підтримувану частину CPython. Однак 19 жовтня 2026 року автори відкликали PEP 836, на яку покладали ці надії.
Над JIT працювали розробники Брандт Бухер (Brandt Bucher) та Саванна Островскі (Savannah Ostrowski). Спершу вони підготували PEP 744, у якому описали принцип роботи компілятора. Проте в документі не було відповіді на головне питання: хто і як підтримуватиме JIT та інтегруватиме його в CPython. Цю прогалину мав закрити PEP 836, але рада знайшла в ній три слабкі місця.
По-перше, бракувало деталей про те, як JIT супроводжуватимуть у довгостроковій перспективі. По-друге, не було чіткої методики, за якою вимірювали б ефективність компілятора. По-третє, не описали, як JIT працюватиме з налагодженням і профілюванням, що критично важливо для розробників. Окрема претензія стосувалася надмірного оптимізму щодо приросту швидкості: прискорення справді можна було виміряти, але воно було невеликим і з’являлося лише в окремих сценаріях, наприклад у програмах із тривалими циклами.
Островскі пояснила відкликання PEP 836 нестачею ресурсів. За її словами, рада слушно встановлює високу планку для таких масштабних змін, а в авторів немає особистої можливості «тягнути поточну версію далі». Водночас розробниця наголосила, що команда вірить у технічний напрямок проєкту. Серед його складників вона назвала підтримку вільної багатопотоковості (free-threaded) та метод-орієнтований фронтенд, а також зберегла оптимізм щодо потенціалу JIT у CPython.
Відкликання PEP означає лише те, що в основній гілці CPython робота над JIT далі не рухатиметься. Заборони на її продовження немає. Інші розробники можуть розвивати проєкт самостійно, зокрема в альтернативній збірці CPython. Але якщо вони захочуть повернути напрацювання в основний код, їм доведеться пройти ту саму високу планку вимог.
Ідея прискорити Python за допомогою JIT не нова. Найвідомішим прикладом є PyPy, альтернативний інтерпретатор із високооптимізованим JIT, який може прискорювати програми на порядок і більше. Його слабкі місця в тому, що розробка відстає від основної версії CPython, а також трапляються проблеми з продуктивністю та сумісністю із зовнішніми модулями на C. Ще один приклад — Cinder X від Facebook, який пропонує JIT як додаток до інтерпретатора, але також вважається експериментальним.
Рідний JIT був лише одним із напрямків. Останніми роками команда CPython більше зосереджується на загальному прискоренні мови. Помітних результатів досягли завдяки адаптивному інтерпретатору, який з’явився в Python 3.11. Він використовує типізований байткод і, як і JIT, не вимагає переписувати наявні програми.
Історія з JIT задала орієнтир для майбутніх проєктів такого роду: всередині CPython вони мають довести, що їх можна підтримувати і що їхній ефект можна виміряти.
3
