--- service: "Publicasta" schema_version: "1.0" article_id: 658 title: "PyPy 8.0 apporte Python 3.12, mais le vrai test concerne l’écosystème des extensions" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=fr" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-21T07:00:22+00:00" updated_at: "2026-09-21T07:00:22+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=de" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=de" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=en" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=en" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=es" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=es" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/pypy_8_0_python_3_12_beta_abi3_compatibility.json?lang=zh" --- # PyPy 8.0 apporte Python 3.12, mais le vrai test concerne l’écosystème des extensions > PyPy 8.0 franchit une étape importante : Python 3.12 arrive en bêta, les binaires Linux passent à glibc 2.28 et le projet prépare la compatibilité avec les roues cp312-abi3 de CPython. Cela ne rend toutefois pas tous les paquets Python interchangeables. PyPy 8.0 mérite l’attention pour une raison que son numéro de version peut dissimuler. Le projet ne livre pas simplement un nouvel interpréteur Python plus rapide. Il tente de réduire l’un des coûts persistants du choix de PyPy : l’écart entre un moteur compatible avec le langage Python et l’univers beaucoup plus vaste des paquets qui dépendent de l’API C de CPython. ![Illustration éditoriale d’un environnement d’exécution inspiré de PyPy, relié par un pont de compatibilité à des paquets d’extensions Python standardisés.](https://publicasta.com/storage/projects/10/pages/658/2026/09/cfa20102-4c12-403b-9c6f-3964594b9ac2.webp) La version publiée le 19 septembre 2026 ajoute un interpréteur Python 3.12 de qualité bêta, continue de fournir des variantes Python 3.11 et Python 2.7, et fait passer la base de compilation Linux à glibc 2.28. Surtout, l’équipe PyPy indique que le nouveau modèle d’objets Python 3.12 contient les éléments nécessaires à l’utilisation de roues `cp312-abi3` conçues pour l’API limitée de CPython. Le travail restant ne concerne pas uniquement PyPy : le mécanisme d’importation, les installateurs et les systèmes de compilation des paquets doivent tous considérer ces roues comme des candidates valides. PyPy 8.0 constitue donc une version intéressante pour l’expérimentation et pour des essais de production ciblés. Elle ne donne pas pour autant une consigne générale de remplacement de CPython. La question pratique est plus précise : l’ensemble des dépendances de votre application peut-il fonctionner avec PyPy 8.0 sans revenir à des compilations depuis les sources, à des extensions natives non prises en charge ou à des hypothèses d’exécution propres à CPython ? ## Les changements de PyPy 8.0 PyPy présente la version 8.0.0 comme une version majeure organisée autour de trois branches d’interpréteur : PyPy2.7, PyPy3.11 et PyPy3.12. L’implémentation de Python 3.12 est explicitement marquée comme bêta. Les utilisateurs doivent donc la considérer comme une plateforme de test de compatibilité plutôt que comme un remplacement immédiat d’un déploiement CPython mature. La branche Python 3.11 reste disponible, mais le projet indique que, sauf problème de sécurité, il s’agit probablement de sa dernière version prenant cette branche en charge. La note de version officielle donne deux raisons liées à l’infrastructure pour expliquer le changement de version majeure. Premièrement, les machines de compilation Linux utilisent désormais des images manylinux 2.28 fondées sur AlmaLinux 8 et glibc 2.28, avec GCC 14 à la place de l’ancienne chaîne GCC 5. Les archives compilées qui en résultent exigent glibc 2.28 ou une version ultérieure. Cette base est raisonnable pour de nombreuses distributions actuelles, mais elle reste une contrainte de déploiement : les anciennes images d’entreprise, les appliances historiques et les bases de conteneurs figées doivent être vérifiées, pas simplement présumées compatibles. Deuxièmement, PyPy a modifié la manière dont sa représentation interne des objets est exposée aux extensions C. Les versions précédentes présentaient une extension propre à PyPy dans la structure `PyObject`, ce qui la différenciait de la disposition de CPython. Dans la version 8.0, le champ spécifique à PyPy est masqué dans un préfixe situé avant le pointeur remis aux modules d’extension C. L’objectif annoncé est de permettre à PyPy d’utiliser des roues `cp312-abi3` produites pour CPython 3.12 et les versions suivantes, à condition que ces roues restent réellement dans les limites de l’API restreinte. La version met aussi à jour la génération de code RPython. PyPy utilise désormais des sauts calculés et une mise en ligne plus agressive dans le code d’interpréteur généré. L’équipe reconnaît que le gain de performances n’a pas été aussi important qu’espéré. Ce détail compte : la valeur de cette version ne se résume pas à un titre de benchmark. Son travail le plus conséquent concerne l’empaquetage, la compatibilité et le coût de maintenance lié au support d’un autre interpréteur. PyPy a par ailleurs retiré son backend HPy interne. La note de version explique que l’approche de HPy, fondée sur des handles, a constitué un prototype utile, mais n’a pas obtenu assez de soutien pour devenir un nouveau standard. Le code HPy reste présent dans l’arbre PyPy et peut être activé avec une option de compilation, mais il ne fait plus partie de l’orientation par défaut. Pour les auteurs d’extensions, la voie immédiate reste donc la frontière de l’API C existante, CFFI ou une logique de compilation propre à l’interpréteur, et non une transition générale vers HPy qui supprimerait les compromis actuels. ## Pourquoi `cp312-abi3` est important Les paquets Python ne sont pas tous distribués de la même manière. Un paquet entièrement écrit en Python peut souvent utiliser une roue `py3-none-any` et fonctionner avec CPython, PyPy ou une autre implémentation de Python 3. Un paquet qui contient du code compilé en C, C++ ou Rust est différent. Sa roue peut être liée à un interpréteur, une ABI, un système d’exploitation et une architecture processeur particuliers. Le nom du fichier encode ces affirmations de compatibilité. Le Python Packaging User Guide décrit `abi3` comme l’étiquette utilisée pour les extensions compilées avec l’ABI stable de CPython. Cette ABI stable correspond à un sous-ensemble restreint de l’API C, conçu pour rester utilisable entre plusieurs versions 3 de Python. Dans le cas courant, un paquet peut distribuer une roue `cp39-abi3` par combinaison de système d’exploitation et d’architecture, au lieu de reconstruire une extension pour chaque version mineure de CPython. Cet avantage ne s’étend pas automatiquement à PyPy. Une roue portant l’étiquette `cp312-abi3` formule une affirmation concernant l’ABI stable de CPython. PyPy doit fournir une implémentation compatible de l’interface concernée, et les outils d’empaquetage doivent prendre la roue en compte pendant la résolution des dépendances. La version 8.0 de PyPy indique que les en-têtes C et les fonctions exportées sont désormais alignés sur l’API limitée de CPython pour Python 3.12, mais elle mentionne aussi deux éléments importants encore absents : le mécanisme d’importation doit accepter les objets partagés `abi3.so` comme valides pour PyPy, et des outils tels que `pip` et `uv` doivent reconnaître ces roues comme candidates. Cette distinction est au centre de la version. Une modification correcte au niveau du runtime peut produire peu d’effets pour les utilisateurs si l’index de paquets, l’installateur, le backend de compilation et le projet d’extension n’ont pas adopté la même interprétation. La chaîne de compatibilité ressemble à ceci : ```text En-têtes C et chargeur de PyPy ↓ le projet d’extension compile dans les limites de l’API restreinte ↓ les métadonnées de la roue annoncent une ABI compatible ↓ l’installateur considère la roue pour PyPy ↓ l’application passe les tests d’exécution et de comportement ``` Une rupture à n’importe quel endroit renvoie l’utilisateur vers une compilation depuis les sources, une roue propre à PyPy, une solution de repli en Python pur ou un binaire incompatible. PyPy 8.0 fait avancer le premier maillon de cette chaîne. Il ne dispense pas de tester les autres. ## Une réserve de compatibilité encore importante L’erreur la plus sérieuse serait de lire « prend en charge les roues abi3 de CPython 3.12 » comme « prend en charge tous les paquets Python populaires ». De nombreux paquets n’utilisent pas l’API limitée. Ils peuvent accéder à des détails internes de CPython, dépendre du comportement du comptage de références, supposer une disposition particulière des objets ou distribuer du code généré testé uniquement avec CPython. Une roue peut porter une étiquette qui semble proche de la portabilité alors que le code qu’elle contient repose toujours sur des hypothèses que PyPy ne peut pas reproduire exactement. PyPy fournit depuis longtemps une couche de compatibilité appelée `cpyext`, qui émule une grande partie de l’API C de CPython. Elle rend possible l’utilisation d’une vaste quantité de code d’extension, mais l’émulation a un coût. PyPy utilise un ramasse-miettes par traçage, et non l’implémentation fondée sur le comptage de références de CPython. Les compteurs de références observés via la couche de compatibilité ne représentent donc pas nécessairement le même état que celui qu’une extension C verrait sous CPython. Les codes qui utilisent les compteurs de références comme signal de durée de vie, effectuent une désallocation délicate ou dépendent des détails internes des objets CPython doivent être examinés avec une attention particulière. La documentation de Cython souligne un point voisin : Cython peut adapter le code généré pour PyPy, mais des différences visibles subsistent dans l’API C émulée. Elle conseille aux auteurs d’extensions de s’appuyer autant que possible sur la gestion produite par Cython plutôt que d’utiliser directement des comportements bas niveau de l’API C sans raison clairement établie. Ce n’est pas une condamnation propre à PyPy. C’est le rappel qu’une surface de langage stable et une surface d’extension native stable sont deux problèmes d’ingénierie différents. CFFI reste une solution importante pour les projets qui doivent prendre en charge plusieurs implémentations de Python. L’équipe PyPy demande précisément aux mainteneurs de bibliothèques utilisant des extensions C d’envisager une version CFFI suffisamment performante avec PyPy. CFFI ne rend pas automatiquement chaque dépendance native portable, mais peut éviter certaines hypothèses qui compliquent l’exécution d’une extension CPython sous un autre interpréteur. Les auteurs d’extensions Rust rencontrent une décision similaire. PyO3 prend en charge les compilations pour PyPy et propose une configuration permettant de détecter l’implémentation PyPy, mais sa documentation et ses commentaires de code présentent encore l’ABI stable comme une voie orientée vers CPython. Un projet Rust qui veut prendre en charge CPython et PyPy doit donc compiler et tester explicitement ces cibles. Il ne doit pas déduire la compatibilité avec PyPy du seul fait que la compilation CPython utilise `abi3`. ## Qui devrait essayer PyPy 8.0 maintenant Les meilleurs candidats sont les applications dont les charges de travail contiennent de longues boucles Python, une quantité importante de calcul en Python pur ou des services qui peuvent tirer parti du JIT de traçage de PyPy une fois le code échauffé. Le bénéfice potentiel est plus crédible lorsque l’application passe beaucoup de temps dans du code Python et moins de temps à attendre dans des bibliothèques natives qui effectuent déjà l’essentiel du travail. PyPy constitue aussi une plateforme de test raisonnable pour les mainteneurs de bibliothèques en Python pur. Lorsqu’un paquet revendique une large compatibilité entre implémentations Python, l’ajout de PyPy 8.0 à la matrice CI peut révéler des hypothèses invisibles avec des tests limités à CPython. Cela concerne notamment les bibliothèques qui manipulent indirectement la durée de vie des objets, utilisent fortement le dispatch dynamique ou promettent de fonctionner avec des interpréteurs alternatifs. La version intéresse également les mainteneurs d’extensions. Un projet qui utilise déjà Cython, CFFI ou PyO3 peut se servir de PyPy 8.0 pour vérifier si sa frontière d’abstraction est réellement portable. Le travail autour de `cp312-abi3` fournit une cible concrète à la collaboration entre PyPy, les auteurs d’extensions et les outils d’empaquetage. Une demande générale — « mieux prendre en charge PyPy » — devient une série de problèmes testables : l’extension compile-t-elle, la roue peut-elle être installée, s’importe-t-elle et se comporte-t-elle correctement avec le ramasse-miettes et l’exécution JIT ? Les équipes qui maintiennent des services Python doivent être plus sélectives. Un service possédant un arbre de dépendances modeste, de solides tests d’intégration et une charge dominée par du code Python constitue un pilote plausible. Une pile de science des données regroupant plusieurs grandes dépendances binaires, des pilotes de bases de données natifs, des modules Cython personnalisés et des roues propres à un fournisseur est une première cible beaucoup plus risquée. Cette pile pourra peut-être fonctionner, mais le bénéfice attendu doit justifier le maintien d’une voie d’interpréteur supplémentaire. La raison la moins convaincante d’essayer PyPy 8.0 serait simplement que son numéro de version est supérieur à celui de CPython. La version de PyPy suit la séquence de publication propre au projet ; elle ne signifie pas que le runtime implémente Python 8. Les versions du langage concernées par cette publication sont Python 3.12 bêta, Python 3.11 et Python 2.7. ## Un plan d’évaluation pratique Un test sérieux commence par un inventaire, pas par un benchmark. Notez l’intégralité du fichier de verrouillage et classez chaque dépendance comme paquet Python pur, extension C, extension Rust, bibliothèque partagée externe ou paquet possédant un chemin propre à un interpréteur. Le résultat indiquera où se trouve réellement le travail. Une liste des exigences directes ne suffit pas : le paquet fragile peut se trouver plusieurs niveaux plus bas dans le graphe de dépendances. Créez ensuite un environnement distinct pour PyPy 8.0 et installez les dépendances avec le résolveur habituel du projet. Ne préinstallez pas une collection de roues CPython en supposant que l’environnement sera représentatif. Notez quels paquets sont installés depuis des roues, lesquels sont compilés depuis les sources et lesquels sont refusés. Une installation réussie constitue un élément utile, mais pas un verdict de compatibilité. La suite de tests doit ensuite s’exécuter dans au moins quatre modes : démarrage propre, exécution fonctionnelle courte, charge de longue durée et scénario de redémarrage ou de mise à niveau. Le mode longue durée est important parce que le JIT de PyPy a besoin de temps pour s’échauffer et parce que le comportement du ramasse-miettes peut ne pas apparaître dans une petite suite de tests unitaires. Mesurez le temps de démarrage, le débit en régime stable, la croissance mémoire, la latence de queue et le moment où le service devient utile. Une boucle interne plus rapide ne constitue pas nécessairement un meilleur déploiement si le démarrage ou la mémoire dominent la charge. Les frontières natives méritent des tests ciblés. Exercez la sérialisation, les pilotes de bases de données, le traitement d’images ou d’audio, la cryptographie, la compression, les noyaux numériques et tout code qui transmet des objets Python à travers du C ou du Rust. Exécutez des tests qui provoquent réellement des allocations et des collectes, au lieu de ne couvrir que les appels nominaux. Si l’application utilise des callbacks, des finaliseurs, des protocoles de buffer ou la coordination entre threads, incluez explicitement ces chemins. Ce sont les zones où les différences entre interpréteurs deviennent des incidents opérationnels plutôt que de simples avertissements d’installation. Conservez CPython comme référence de comparaison. L’objectif n’est pas de prouver que PyPy gagne tous les benchmarks. Comparez le résultat d’ingénierie global : fiabilité de la compilation, comportement au démarrage à froid, mémoire, débit, observabilité, débogage, disponibilité des roues et temps nécessaire pour maintenir deux chemins d’interpréteur en bon état. Pour une charge batch exécutée pendant plusieurs heures, le coût d’échauffement peut être négligeable. Pour un utilitaire en ligne de commande lancé plusieurs centaines de fois par minute, le même coût peut annuler le bénéfice. ## Les utilisateurs Linux doivent vérifier la frontière glibc Le passage à glibc 2.28 est facile à négliger parce qu’il est présenté comme un détail d’infrastructure de compilation. Il fait aussi partie du contrat de distribution du runtime. La page de téléchargement de PyPy indique que les binaires Linux actuels sont compatibles avec manylinux 2.28 et les versions ultérieures, et précise que les compilations Linux exigent glibc 2.28 ou plus récente. Les utilisateurs de versions modernes d’Ubuntu, Debian, Fedora et de systèmes comparables ne seront probablement pas surpris. Ceux qui prennent en charge d’anciennes distributions ou des images minimales doivent le vérifier directement. Une compilation de conteneur est l’endroit le plus simple pour détecter le problème. Testez l’image de base exacte utilisée en production, et non une image de développement plus récente. Vérifiez les bibliothèques partagées requises par l’interpréteur et exécutez les tests de bon fonctionnement de l’application dans cette image. Si le déploiement vise plusieurs types de machines, testez le nœud le plus ancien pris en charge. Un binaire PyPy qui fonctionne sur la machine de compilation mais pas sur le plus ancien hôte de production ne constitue pas une mise à niveau réussie. Le projet avertit aussi que ses binaires Linux incluent OpenSSL, mais pas de magasin de certificats. La documentation de téléchargement conseille de s’appuyer sur le magasin de certificats de la plateforme ou de configurer `SSL_CERT_FILE`, par exemple au moyen du paquet `certifi`. Ce détail n’est pas propre à PyPy, mais il est précisément le genre de problème opérationnel que l’on peut oublier lorsqu’un interpréteur est téléchargé sous forme d’archive autonome. Les tests HTTPS doivent faire partie de la validation initiale, en particulier pour les outils qui contactent des index de paquets, des API ou des services internes. ## Télécharger, vérifier et isoler l’expérience PyPy fournit des archives précompilées pour plusieurs plateformes, notamment Linux x86-64, Linux ARM64, Windows 64 bits et macOS sur les processeurs Apple Silicon comme Intel. Le projet publie les sommes de contrôle des archives 8.0.0. Considérez ces sommes comme une étape de l’installation : téléchargez depuis les pages officielles du projet, vérifiez l’archive et notez précisément la compilation de l’interpréteur utilisée pour l’expérience. Évitez de remplacer la commande système `python` pendant l’évaluation de la version. Utilisez un environnement virtuel dédié ou un chemin explicite vers l’interpréteur, conservez l’environnement CPython existant et rendez la sélection visible dans la CI. Un petit wrapper ou une entrée dans une matrice est plus facile à supprimer qu’un changement d’interpréteur à l’échelle de la machine qui modifierait silencieusement des scripts, des tâches de compilation ou des unités de service. Le projet indique que compiler PyPy depuis les sources prend du temps et exige des ressources de calcul importantes. La plupart des utilisateurs devraient donc commencer par les binaires officiels. Les compilations depuis les sources ont du sens pour les empaqueteurs de distributions, les contributeurs de PyPy ou les équipes soumises à des exigences contrôlées concernant la chaîne d’outils. Elles ne constituent pas le chemin le plus court pour évaluer une application ordinaire. ## Ce que la version implique pour les outils d’empaquetage PyPy 8.0 met en évidence un problème de coordination que l’écosystème Python repousse depuis des années. La prise en charge d’un interpréteur est souvent décrite comme une propriété du runtime seul, alors que la sélection d’une roue résulte d’une négociation entre les métadonnées du paquet, les étiquettes de l’installateur, les backends de compilation, la politique de l’index et l’implémentation qui chargera finalement le binaire. Les propres termes de l’équipe PyPy montrent que le travail reste à faire dans le mécanisme d’importation et dans des outils comme `pip` et `uv`. Les mainteneurs de paquets disposent donc d’un moyen concret de contribuer. Ils peuvent tester l’extension du projet avec PyPy 3.12, vérifier qu’elle utilise effectivement uniquement l’API limitée, ajouter un travail PyPy dans la CI, publier une roue compatible lorsque c’est approprié et signaler les échecs avec un reproducer minimal. Un utilisateur qui ouvre une issue en écrivant seulement « PyPy est cassé » fournit peu d’informations. Un rapport indiquant que « la roue `cp312-abi3` s’installe, mais échoue lorsqu’un buffer est libéré après une collecte » donne à l’écosystème un problème exploitable. C’est aussi un rappel à la précision dans les métadonnées des paquets. Une distribution en Python pur devrait utiliser l’étiquette vraie la plus large. Une extension compilée devrait annoncer uniquement l’ABI et les plateformes réellement testées. Un projet qui compile avec une ABI stable mais importe encore des symboles privés de CPython n’a pas obtenu la portabilité suggérée par son nom de fichier. Le travail autour de PyPy 8.0 n’aura de valeur que si les affirmations des paquets deviennent plus exactes, et pas simplement plus optimistes. ## Alternatives et compléments CPython reste le choix par défaut pour obtenir la compatibilité la plus large avec les paquets, le comportement le plus prévisible des extensions natives et le plus grand ensemble de roues prises en charge par les fournisseurs. Pour de nombreuses applications, c’est la bonne décision. Choisir PyPy n’est pas une déclaration de principe sur la diversité des implémentations Python ; c’est une décision liée à la charge de travail et à la maintenance. Si l’objectif est de réduire les frictions liées aux dépendances tout en conservant un runtime familier, améliorer la frontière C du paquet peut être plus utile que changer d’interpréteur. CFFI, une API limitée bien définie, des bindings générés et moins d’hypothèses propres à une implémentation peuvent améliorer la portabilité entre CPython, PyPy et les futurs runtimes. Pour les extensions Rust, des compilations PyPy explicites et une compilation conditionnelle peuvent être plus fiables que l’attente qu’un artefact orienté CPython fonctionne partout. Si l’objectif est la vitesse brute, mesurez l’application réelle avec les options disponibles. Le JIT de PyPy peut aider les charges longues dominées par Python, mais les bibliothèques natives, les entrées-sorties, la sérialisation, le démarrage et la mémoire peuvent dominer le résultat. Un déploiement CPython soigneusement optimisé, un autre algorithme, une extension compilée ou une modification de l’architecture des processus peut apporter davantage. La comparaison pertinente porte sur le programme entier, pas sur une boucle synthétique. ## Le verdict PyPy 8.0 est une version open source importante parce qu’elle s’attaque à un obstacle réel à l’adoption. Le support bêta de Python 3.12 rapproche le projet de l’écosystème actuel du langage. Le passage à glibc 2.28 donne à ses binaires Linux une base de distribution moderne. Le nouveau modèle d’objets et le support prévu de `cp312-abi3` pourraient réduire le nombre de paquets exigeant des compilations PyPy distinctes. La réserve est tout aussi importante : la compatibilité n’est pas complète tant que les installateurs ne sélectionnent pas les roues, que le chargeur ne les accepte pas et que les applications n’ont pas résisté à de vraies charges. Les anciens problèmes liés aux extensions C propres à CPython, aux hypothèses sur le comptage de références, aux dépendances binaires et à une couverture de tests inégale demeurent. PyPy 8.0 améliore le point de départ ; il ne fait pas disparaître le graphe de dépendances. Pour les développeurs, la recommandation pratique consiste à tester PyPy 8.0 sur une charge de travail délimitée, avec un fichier de verrouillage fixe et une comparaison CPython. Ajoutez-le à la CI si votre bibliothèque revendique la prise en charge d’interpréteurs alternatifs. Vérifiez la base glibc, contrôlez les sommes des archives, testez les certificats HTTPS et examinez chaque dépendance native. Traitez le support de Python 3.12 comme bêta et la compatibilité `cp312-abi3` comme un projet d’écosystème encore en cours. Cela suffit pour que la version mérite un essai. Le meilleur argument en faveur de PyPy n’a jamais été que tous les programmes Python devraient changer d’interpréteur. Il est que l’écosystème Python devrait disposer de plusieurs implémentations sérieuses et que le choix de l’une d’elles devrait être possible sans transformer l’empaquetage courant en projet d’ingénierie séparé. PyPy 8.0 rapproche cet objectif, mais la prochaine étape dépend autant des mainteneurs de bibliothèques et des outils d’empaquetage que de l’équipe de l’interpréteur. ## Sources Cette adaptation s’appuie sur la note de version « PyPy v8.0.0 release », la documentation officielle de téléchargement et des sommes de contrôle de PyPy, le dépôt `pypy/pypy`, les spécifications du Python Packaging User Guide sur les étiquettes de compatibilité et les extensions binaires, ainsi que les documentations de Cython et de PyO3. La discussion de publication sur Hacker News est conservée comme source de contexte et de discussion.