Чому PyPy не був включений у стандартний Python?

Я дивився на PyPy, і мені було просто цікаво, чому він не був прийнятий в основні дистрибутиви Python. Чи не такі речі, як компіляція JIT та менший слід пам’яті, значно покращують швидкість усього коду Python?

Якщо коротко, то які основні недоліки PyPy змушують його залишатися окремим проектом?

PyPy не є форкою CPython, тому його ніколи не можна об'єднати безпосередньо в CPython.

Теоретично спільнота Python могла б повсюдно прийняти PyPy, PyPy могла бути виконана еталонною реалізацією, а CPython може бути припинено. Однак у PyPy є свої слабкі сторони:

• CPython легко інтегрувати з модулями Python, написаними на C, що традиційно так, як додатки Python вирішували завдання, що вимагають процесора (див., Наприклад, проект SciPy).
• Сам крок компіляції PyPy JIT коштує часу процесора - лише завдяки повторному виконанню скомпільованого коду він загалом стає швидшим. Це означає, що час запуску може бути більшим, і тому PyPy не обов'язково є настільки ефективним для запуску клейового коду або тривіальних сценаріїв.
• Поведінка PyPy та CPython не є однаковою в усіх відношеннях, особливо якщо мова йде про "деталі реалізації" (поведінка, яка не визначена мовою, але все ще важлива на практичному рівні).
• CPython працює на більшій кількості архітектур, ніж PyPy, і він був успішно адаптований для роботи у вбудованих архітектурах способами, які можуть бути непрактичними для PyPy.
• Схема опорного підрахунку CPython для управління пам’яттю, мабуть, має більш передбачувані ефекти на продуктивність, ніж різні системи GP PyPy, хоча це не обов'язково стосується всіх «чистих GC» стратегій.
• PyPy ще не повністю підтримує Python 3.x, хоча це активний робочий елемент.

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

Ще один приклад: ви можете подумати, що PyPy буде чудовим для ігор, але більшість стратегій GC, як ті, що використовуються в PyPy, викликають помітне тремтіння. Для CPython більша частина ігор, що вимагає процесора, завантажується в бібліотеку PyGame, якою PyPy не може скористатися, оскільки PyGame в основному реалізований як розширення C (хоча див .: pygame-cffi). Я все ще думаю, що PyPy може бути чудовою платформою для ігор, але я ніколи не бачив, щоб її фактично використовували.

У PyPy та CPython докорінно різні підходи до фундаментальних питань дизайну і роблять різні компроміси, тому жоден не є "кращим", ніж інший у кожному випадку.

Для одного, він не на 100% сумісний з Python 2.x, і має лише попередню підтримку для 3.x.

Це також не те, що можна об'єднати - реалізація Python, що надається PyPy, генерується за допомогою створеної ними структури, яка надзвичайно крута, але також повністю розходиться з існуючою реалізацією CPython. Це мало б бути повноцінною заміною.

Існують деякі дуже конкретні відмінності між PyPy та CPython, велика проблема полягає в тому, як підтримуються модулі розширення - що, якщо ви хочете вийти за рамки стандартної бібліотеки, - це велика справа.

Варто також зазначити, що PyPy не є універсально швидшим.

Дивіться це відео Гідо ван Россума . Він розповідає про те саме питання, яке ви задали за 12 хв 33 сек.

Основні моменти:

• відсутність сумісності Python 3
• відсутність підтримки для розширення
• не підходить як код клею
• швидкість - це не все

Зрештою, він вирішує ...

Однією з причин може бути те, що за даними сайту PyPy , він наразі працює лише на 32- та 64-бітній архітектурі Intel x86, тоді як CPython працює і на інших платформах. Можливо, це пов’язано з підвищенням швидкості в PyPy, що залежить від платформи. Хоча швидкість - це хороша річ, люди часто хочуть, щоб реалізація мови була максимально незалежною від платформи.

Я рекомендую переглянути цю основну довідку Девіда Бізлі для отримання більш детальної інформації. Він відповідає на ваше запитання, надаючи зрозумілість природі та тонкощам PyPy.

На додаток до всього, що тут говориться, PyPy не є майже таким твердим, як CPython з точки зору помилок. За допомогою SymPy ми знайшли близько десятка помилок у PyPy протягом останніх кількох років, як у випущених версіях, так і в солов'їнах.

З іншого боку, ми знайшли лише одну помилку в CPython, і це було в попередньому випуску.

Крім того, не варто знижувати відсутність підтримки Python 3. Ніхто з основної спільноти Python навіть не піклується про Python 2. Вони працюють над наступними великими речами в Python 3.4, який стане п’ятім головним випуском Python 3. Хлопці з PyPy досі не отримали жодного з них. Таким чином, вони мають щось наздогнати, перш ніж вони зможуть стати претендентами.

Не зрозумійте мене неправильно. PyPy - приголомшливий. Але це ще далеко не краще, ніж CPython у багатьох дуже важливих способах.

І до речі, якщо ви використовуєте SymPy в PyPy, ви не побачите менший слід пам’яті (або прискорення). Див. Https://bitbucket.org/pypy/pypy/isissue/1447/ .