Pourquoi PyPy n'a-t-il pas été inclus dans Python standard?

Je regardais PyPy et je me demandais simplement pourquoi il n'a pas été adopté dans les distributions Python principales. Des choses comme la compilation JIT et une faible empreinte mémoire n'amélioreraient-elles pas considérablement la vitesse de tout le code Python?

Bref, quels sont les principaux inconvénients de PyPy qui font qu'il reste un projet à part?

PyPy n'est pas un fork de CPython, il ne pourrait donc jamais être fusionné directement dans CPython.

Théoriquement, la communauté Python pourrait adopter PyPy universellement, PyPy pourrait devenir l'implémentation de référence et CPython pourrait être interrompu. Cependant, PyPy a ses propres faiblesses:

• CPython est facile à intégrer aux modules Python écrits en C, ce qui est traditionnellement la façon dont les applications Python gèrent les tâches gourmandes en ressources processeur (voir par exemple le projet SciPy).
• L'étape de compilation PyPy JIT elle-même coûte du temps CPU - ce n'est que par l'exécution répétée du code compilé qu'elle devient globalement plus rapide. Cela signifie que les temps de démarrage peuvent être plus longs et que PyPy n'est donc pas nécessairement aussi efficace pour exécuter du code glue ou des scripts triviaux.
• Le comportement de PyPy et CPython n'est pas identique à tous égards, notamment en ce qui concerne les "détails d'implémentation" (comportement qui n'est pas spécifié par le langage mais qui est toujours important au niveau pratique).
• CPython fonctionne sur plus d'architectures que PyPy et a été adapté avec succès pour s'exécuter dans des architectures embarquées d'une manière qui peut être peu pratique pour PyPy.
• Le schéma de comptage de références de CPython pour la gestion de la mémoire a sans doute des impacts sur les performances plus prévisibles que les différents systèmes GC de PyPy, bien que ce ne soit pas nécessairement vrai pour toutes les stratégies «GC pur».
• PyPy ne prend pas encore totalement en charge Python 3.x, bien que ce soit un élément de travail actif.

PyPy est un excellent projet, mais la vitesse d'exécution des tâches gourmandes en ressources processeur n'est pas tout, et dans de nombreuses applications, c'est la moindre des nombreuses préoccupations. Par exemple, Django peut fonctionner sur PyPy et cela accélère la création de modèles, mais les pilotes de base de données de CPython sont plus rapides que ceux de PyPy; en fin de compte, quelle implémentation est la plus efficace dépend de l'emplacement du goulot d'étranglement dans une application donnée.

Un autre exemple: vous penseriez que PyPy serait idéal pour les jeux, mais la plupart des stratégies GC comme celles utilisées dans PyPy provoquent une gigue notable. Pour CPython, la plupart des éléments de jeu gourmands en ressources processeur sont déchargés vers la bibliothèque PyGame, dont PyPy ne peut pas profiter puisque PyGame est principalement implémenté en tant qu'extension C (voir cependant: pygame-cffi). Je pense toujours que PyPy peut être une excellente plate-forme pour les jeux, mais je ne l'ai jamais vue réellement utilisée.

PyPy et CPython ont des approches radicalement différentes des questions de conception fondamentales et font des compromis différents, de sorte qu'aucun n'est «meilleur» que l'autre dans tous les cas.

D'une part, il n'est pas compatible à 100% avec Python 2.x et n'a qu'un support préliminaire pour 3.x.

Ce n'est pas non plus quelque chose qui pourrait être fusionné - L'implémentation Python fournie par PyPy est générée à l'aide d'un framework qu'ils ont créé, ce qui est extrêmement cool, mais aussi complètement disparate avec l'implémentation CPython existante. Il faudrait que ce soit un remplacement complet.

Il existe des différences très concrètes entre PyPy et CPython, une grande étant la manière dont les modules d'extension sont pris en charge - ce qui, si vous voulez aller au-delà de la bibliothèque standard, est un gros problème.

Il convient également de noter que PyPy n'est pas universellement plus rapide.

Voir cette vidéo de Guido van Rossum . Il parle de la même question que vous avez posée à 12 min 33 s.

Points forts:

• manque de compatibilité Python 3
• manque de support d'extension
• pas approprié comme code de colle
• la vitesse n'est pas tout

Après tout, c'est lui qui décide ...

L'une des raisons pourrait être que, selon le site PyPy , il ne fonctionne actuellement que sur l'architecture Intel x86 32 et 64 bits, tandis que CPython fonctionne également sur d'autres plates-formes. Cela est probablement dû aux améliorations de vitesse spécifiques à la plate-forme dans PyPy. Bien que la vitesse soit une bonne chose, les gens veulent souvent que les implémentations de langage soient aussi «indépendantes de la plate-forme» que possible.

Je recommande de regarder ce discours de David Beazley pour plus d'informations. Il répond à votre question en clarifiant la nature et les subtilités de PyPy.

En plus de tout ce qui a été dit ici, PyPy n'est pas aussi solide que CPython en termes de bogues. Avec SymPy, nous avons trouvé une douzaine de bugs dans PyPy au cours des deux dernières années, à la fois dans les versions publiées et dans les nightlies.

D'un autre côté, nous n'avons jamais trouvé qu'un seul bogue dans CPython, et c'était dans une pré-version.

De plus, ne négligez pas le manque de prise en charge de Python 3. Personne dans la communauté Python principale ne se soucie même plus de Python 2. Ils travaillent sur les prochaines grandes choses de Python 3.4, qui sera la cinquième version majeure de Python 3. Les gars de PyPy n'en ont toujours pas. Ils ont donc du rattrapage à faire avant de pouvoir commencer à être des prétendants.

Ne vous méprenez pas. PyPy est génial. Mais c'est encore loin d'être meilleur que CPython à bien des égards.

Et au fait, si vous utilisez SymPy dans PyPy, vous ne verrez pas une empreinte mémoire plus petite (ni une accélération non plus). Voir https://bitbucket.org/pypy/pypy/issues/1447/ .