CPython позбавляється свого експериментального JIT-компілятора: розробники не подали Раді з управління Python (Steering Council) достатньо переконливого плану його довгострокової підтримки, тож роботу над цією технологією в основній гілці інтерпретатора припиняють. Про це повідомляє InfoWorld.

Ще в червні 2026 року Рада проєкту тимчасово заморозила розвиток JIT, поставивши умову: відновити роботу можна буде лише після ухвалення окремого PEP, який пояснить, як перетворити експериментальну розробку на повноцінну та підтримувану частину CPython. 19 жовтня 2026 року автори самі відкликали PEP 836 — саме той документ, на який покладали основні сподівання.

Чому Рада не підтримала ініціативу

Над компілятором працювали розробники Брандт Бухер (Brandt Bucher) та Саванна Островскі (Savannah Ostrowski). Спочатку вони подали PEP 744, у якому описали сам принцип роботи JIT. Однак документ обходив головне питання — хто саме відповідатиме за супровід технології та її інтеграцію в CPython.

Закрити цю прогалину мав PEP 836, але Рада виявила в ньому три слабкі місця:

  • Підтримка — бракувало конкретики щодо того, як JIT супроводжуватимуть у довгостроковій перспективі
  • Оцінка продуктивності — не було чіткої методики для вимірювання ефективності компілятора
  • Інструменти розробника — не пояснили, як JIT взаємодіятиме з налагодженням і профілюванням

Окремо Раду не влаштував надто оптимістичний опис приросту швидкості. Прискорення справді фіксувалося, проте було скромним і проявлялося лише в окремих випадках — наприклад, у програмах із довгими циклами.

Позиція авторів

Островскі пояснила відкликання PEP 836 браком ресурсів у команди. На її думку, Рада має право встановлювати високу планку для змін такого масштабу, а в авторів просто немає сил самотужки «тягнути поточну версію далі».

Попри це розробниця наголосила, що команда й надалі вірить у обраний технічний напрямок. Серед перспективних складників вона назвала підтримку вільної багатопотоковості (free-threaded) та метод-орієнтований фронтенд, зберігаючи оптимізм щодо майбутнього JIT у CPython.

Чи це остаточне рішення

Ні. Відкликання PEP означає лише призупинення роботи над JIT саме в основній гілці CPython — формальної заборони на продовження розробки немає. Будь-хто з розробників може розвивати проєкт окремо, скажімо, у вигляді альтернативної збірки CPython. Проте якщо згодом напрацювання захочуть повернути до основного коду, їм доведеться виконати ті самі жорсткі вимоги.

Альтернативні JIT-рішення для Python

Ідея пришвидшити Python за допомогою JIT не нова. Серед наявних варіантів:

  • PyPy — альтернативний інтерпретатор із високооптимізованим JIT, здатний прискорювати програми на порядок і більше, але його розробка відстає від основної версії CPython, а також трапляються проблеми з продуктивністю та сумісністю із зовнішніми C-модулями
  • CinderX від Facebook — пропонує JIT як додаток до інтерпретатора, проте також залишається експериментальним рішенням

Інші способи прискорення CPython

Рідний JIT був лише одним із напрямків роботи. Останніми роками команда CPython дедалі більше зосереджується на загальному прискоренні мови загалом. Помітного результату вже досягли завдяки адаптивному інтерпретатору, що з'явився в Python 3.11: він використовує типізований байткод і, як і JIT, не вимагає переписування наявного коду.

Пошуки швидшого Python на цьому не припиняються. Проте історія з JIT задала орієнтир для всіх майбутніх схожих ініціатив: щоб потрапити в CPython, вони мають довести — їх можна підтримувати, а їхню ефективність можна об'єктивно виміряти.

Джерело: Highload.tech