Pourquoi ne devrais-je pas utiliser PyPy sur CPython si PyPy est 6,3 fois plus rapide?


686

J'ai beaucoup entendu parler du projet PyPy . Ils affirment qu'il est 6,3 fois plus rapide que l' interpréteur CPython sur leur site .

Chaque fois que nous parlons de langages dynamiques comme Python, la vitesse est l'un des principaux problèmes. Pour résoudre ce problème, ils disent que PyPy est 6,3 fois plus rapide.

Le deuxième problème est le parallélisme, le fameux Global Interpreter Lock (GIL). Pour cela, PyPy dit qu'il peut donner du Python sans GIL .

Si PyPy peut résoudre ces grands défis, quelles sont ses faiblesses qui empêchent une adoption plus large? Autrement dit, qu'est-ce qui empêche quelqu'un comme moi, un développeur typique de Python, de passer à PyPy en ce moment ?


30
Commentaires purgés parce que la plupart étaient des choses qui devraient être étoffées dans les réponses (et dans certains cas le sont), ou ne devraient pas être dites du tout. Également modifié pour répondre à quelques-unes des préoccupations soulevées concernant la subjectivité de cette question. Veuillez essayer de répondre en utilisant des faits, et sauvegardez les assertions avec des sources si possible!
Shog9

3
J'utilise beaucoup Pypy. Cela fonctionne très bien. Cependant, bien que Pypy soit un peu plus rapide pour de nombreuses charges de travail gourmandes en CPU, il est en fait plus lent pour les charges de travail lourdes d'E / S que je lui ai lancées. Par exemple, j'ai écrit un programme de sauvegarde avec déduplication appelé backshift. Pour une sauvegarde initiale, qui fait beaucoup de segmentation de fichiers, Pypy est génial. Mais pour les sauvegardes ultérieures qui consistent principalement à mettre à jour des horodatages, CPython est plus rapide.
dstromberg

Réponses:


657

REMARQUE: PyPy est plus mature et mieux pris en charge maintenant qu'il ne l'était en 2013, lorsque cette question a été posée. Évitez de tirer des conclusions à partir d'informations obsolètes.


  1. PyPy, comme d' autres ont été prompts à parler, a le soutien ténu pour les extensions C . Il a un support, mais généralement à des vitesses plus lentes que Python et il est au mieux incertain. Par conséquent, de nombreux modules nécessitent simplement CPython. PyPy ne prend pas en charge numpy PyPy prend désormais en charge numpy . Certaines extensions ne sont toujours pas prises en charge (Pandas, SciPy, etc.), consultez la liste des packages pris en charge avant d'effectuer la modification.
  2. Le support de Python 3 est expérimental pour le moment. vient d'arriver stable! Depuis le 20 juin 2014, PyPy3 2.3.1 - Fulcrum est sorti !
  3. PyPy n'est parfois pas plus rapide pour les "scripts", pour lesquels beaucoup de gens utilisent Python. Ce sont les programmes à court terme qui font quelque chose de simple et de petit. Parce que PyPy est un compilateur JIT, ses principaux avantages proviennent des temps d'exécution longs et des types simples (tels que les nombres). Franchement, les vitesses pré-JIT de PyPy sont assez mauvaises par rapport à CPython.
  4. Inertie . Passer à PyPy nécessite souvent un réoutillage, ce qui, pour certaines personnes et organisations, représente tout simplement trop de travail.

Ce sont les principales raisons qui me touchent, je dirais.


14
Ravi que vous parliez de réoutillage. Mon hébergeur, par exemple, a le choix entre Python 2.4 et 2.5; et un "grand producteur de logiciels de divertissement" près de chez moi utilise 2.6 sans projet de mise à jour prochaine. Parfois, il peut être un effort important et coûteux de découvrir même le coût d'une conversion.
Mike Housky

19
PyPy étant "aussi rapide que C", c'est plus sur le C générique que sur les bibliothèques C multithread hautement optimisées compatibles avec le cache utilisées pour les données numériques. Pour les chiffres, Python est juste utilisé pour transporter des pointeurs vers de grands tableaux. Donc PyPy étant "aussi rapide que C" signifie "vos pointeurs + métadonnées se déplacent aussi vite que C". Pas grave. Alors pourquoi s'embêter avec Python? Allez voir les signatures de fonction dans cblas et lapacke.
cjordan1

12
@ cjordan1: Je ne comprends pas ce que vous dites. Les constructions numpy de haut niveau sont extrêmement expressives ( np.sum(M[1:2*n**2:2, :2*n**2] * M[:2*n**2:2, :2*n**2].conjugate(), axis=1)?) En Python et cela rend Python très approprié pour la communauté scientifique. De plus, faire les parties non intensives en Python et décortiquer en C pour les petites boucles intensives est une stratégie courante et utilisable.
Veedrac

26
@Veedrac C'est ce que je voulais dire. Comme dans "Allez voir les signatures de fonction dans cblas et lapacke" car elles sont si longues et difficiles à utiliser que vous comprendrez instantanément pourquoi nous utilisons Python pour transporter les pointeurs et les métadonnées.
cjordan1

5
@ tommy.carstensen Ce n'est pas vraiment un bon endroit pour aller en profondeur, mais je vais essayer. 1. C'était beaucoup plus vrai quand je l'ai écrit qu'aujourd'hui. 2. Les "scripts" sont souvent lourds en entrées-sorties. Les entrées-sorties de PyPy sont encore souvent plus lentes que celles de CPython - elles étaient auparavant beaucoup plus lentes. 3. PyPy était auparavant plus lent que CPython pour gérer les chaînes - maintenant c'est souvent mieux et rarement pire. 4. De nombreux "scripts" ne sont que du code à coller - rendre l'interpréteur plus rapide n'améliorera pas les temps d'exécution globaux dans ce cas. 5. Les temps de préchauffage de PyPy étaient autrefois plus longs - les scripts à exécution courte réussissaient rarement à produire beaucoup de code chaud.
Veedrac

104

Ce site ne prétend pas que PyPy est 6,3 fois plus rapide que CPython. Citer:

La moyenne géométrique de tous les benchmarks est 0,16 ou 6,3 fois plus rapide que CPython

Il s'agit d'une déclaration très différente de la déclaration générale que vous avez faite, et lorsque vous comprendrez la différence, vous comprendrez au moins un ensemble de raisons pour lesquelles vous ne pouvez pas simplement dire «utiliser PyPy». Cela peut sembler comme si je me moquais, mais comprendre pourquoi ces deux déclarations sont totalement différentes est vital.

Pour décomposer cela:

  • La déclaration qu'ils font ne s'applique qu'aux références qu'ils ont utilisées. Il ne dit absolument rien sur votre programme (à moins que votre programme soit exactement le même que l'un de leurs points de référence).

  • La déclaration concerne une moyenne d'un groupe de repères. Il n'y a aucune prétention que l'exécution de PyPy donnera une amélioration de 6,3 fois même pour les programmes qu'ils ont testés.

  • Il ne prétend pas que PyPy va même exécuter tous les programmes qui CPython fonctionne tout , et encore moins vite.


15
Bien sûr, rien ne prétend que PyPy exécutera tout le code Python plus rapidement. Mais si vous prenez toutes les applications Python pures, je peux parier que la majorité d'entre elles fonctionneront beaucoup plus rapidement (> 3x fois) sur PyPy puis sur CPython.
Robert Zaremba

18
Aucun de vos deux premiers points n'a de sens. Comment pouvez-vous dire que les benchmarks ne disent "absolument rien sur votre programme". Il est assez évident que les repères ne sont pas un indicateur parfait de toutes les applications réelles, mais ils peuvent certainement être utiles comme indicateur. De plus, je ne comprends pas ce que vous trouvez trompeur lorsqu'ils déclarent la moyenne d'un groupe d'indices de référence. Ils affirment assez clairement que c'est une moyenne. Si un programmeur ne comprend pas ce qu'est une moyenne, il a des préoccupations bien plus sérieuses que les performances linguistiques.
Sean Geoffrey Pietz

6
@SeanGeoffreyPietz - Je ne prétendais pas que le site de PyPy était trompeur - ils ont présenté leurs résultats avec précision. Mais la question d'origine les a mal cités et démontrait que l'auteur ne comprenait pas l'importance du mot «moyenne». De nombreux benchmarks individuels ne sont pas 6,3 fois plus rapides. Et si vous utilisez un type de moyenne différent, vous obtenez une valeur différente, donc "6,3 x plus rapide" n'est pas un résumé adéquat de "la moyenne géométrique est 6,3 x plus rapide". "Le groupe A est Z fois plus rapide que le groupe B" est trop vague pour être significatif.
spookylukey

6
-1: @spookylukey Vous semblez suggérer que la suite de référence est biaisée sans fournir de preuves à l'appui de la demande. La critique doit toujours être étayée par des preuves!
Evgeni Sergeev

5
@EvgeniSergeev - non, j'implique que tous les repères sont biaisés! Pas nécessairement délibérément, bien sûr. L'espace des programmes utiles possibles est infini et incroyablement varié, et un ensemble de repères ne mesure que les performances de ces repères. Demander "combien plus rapide est PyPy que CPython?" c'est comme demander "combien plus rapide si Fred que Joe?", c'est ce que l'OP semble vouloir savoir.
spookylukey

74

Parce que pypy n'est pas compatible à 100%, prend 8 Go de RAM à compiler, est une cible mobile et très expérimentale, où cpython est stable, la cible par défaut pour les constructeurs de modules pendant 2 décennies (y compris les extensions c qui ne fonctionnent pas sur pypy ), et déjà largement déployé.

Pypy ne sera probablement jamais l'implémentation de référence, mais c'est un bon outil à avoir.


2
Selon pypy.org/download.html , PyPy a besoin de 4 Go de RAM pour compiler (sur un système 64 bits), pas 8. Et il y a une option sur cette page pour le faire sous 3 Go si nécessaire.
tricoter

4
@knite 1: c'est nouveau depuis 2015, la documentation a historiquement lu 8 Go. 2: en pratique en 2015 il vous en faut encore au moins 8, dont 6-7 gratuits.
Tritium21 du

4
La mémoire requise pour la compilation n'est pas si pertinente si vous utilisez une génération ou une distribution . En ce qui concerne les "cibles mobiles et hautement expérimentales", pouvez-vous donner quelques exemples de choses qui se cassent? Encore une fois, si les gens utilisent des versions de version plutôt que des versions nocturnes ou des sources, n'ont-ils pas une attente raisonnable de fonctionnalité?
smci

@smci Il s'agit d'une ancienne question basée sur des données anciennes, avec des réponses anciennes. Considérez que cette question et chaque réponse sont historiques pour l'état de pavot il y a 4 ans.
Tritium21

1
@ Tritium21: Je ne suis intéressé que par la réponse actuelle. Qu'Est-ce que c'est? Vous voudrez peut-être modifier votre réponse pour dire "En date de 2013, la comparaison entre Pypy et la version 2.x de Python était ..." Aussi si la revendication "6.3x géométrique-moyenne" dans la question est obsolète ( comme du 4/2017 ils réclament 7,5x, mais même alors cela dépend des benchmarks ... ), alors cela a besoin d'être édité aussi (numéros de version, dernières données, etc.) Je pense que la suite de benchmarks n'est pas très pertinente, presque personne ne courrait raytracing dans un langage de script sur un processeur ces jours-ci. J'ai trouvé pybenchmarks.org
smci

37

La deuxième question est plus facile à répondre: vous pouvez essentiellement utiliser PyPy comme remplacement de remplacement si tout votre code est purement Python. Cependant, de nombreuses bibliothèques largement utilisées (dont certaines de la bibliothèque standard) sont écrites en C et compilées en tant qu'extensions Python. Certains d'entre eux peuvent être conçus pour fonctionner avec PyPy, d'autres non. PyPy fournit le même outil "orienté vers l'avant" que Python --- c'est-à-dire que c'est Python --- mais ses entrailles sont différentes, donc les outils qui s'interfacent avec ces entrailles ne fonctionneront pas.

Quant à la première question, j'imagine que c'est une sorte de Catch-22 avec la première: PyPy a évolué rapidement dans un effort pour améliorer la vitesse et améliorer l'interopérabilité avec d'autres codes. Cela l'a rendu plus expérimental qu'officiel.

Je pense qu'il est possible que si PyPy entre dans un état stable, il puisse commencer à être plus largement utilisé. Je pense également que ce serait formidable pour Python de s'éloigner de ses fondements C. Mais cela n'arrivera pas avant un moment. PyPy n'a pas encore atteint la masse critique où il est presque assez utile pour faire tout ce que vous voulez, ce qui motiverait les gens à combler les lacunes.


17
Je ne pense pas que C soit un langage qui va n'importe où de sitôt (je serais prêt à dire qu'il ne disparaîtra pas de notre vivant). jusqu'à ce qu'il y ait un autre langage qui s'exécutera n'importe où, nous aurons C. (notez que la machine virtuelle Java est écrite en C. Même java, le langage qui "s'exécute partout" a besoin de C pour son omniprésence.) Sinon, je suis d'accord avec ce post sur la plupart de ses points.
Tritium21

7
@ Tritium21: Oui, je ne fais qu'éditorialiser là-bas. Je suis d'accord avec C existant, mais je pense que la dépendance de Python à C est extrêmement préjudiciable, et PyPy est un excellent exemple de pourquoi: maintenant nous avons la chance d'obtenir Python plus rapide, mais nous sommes trébuchés par des années de confiance en C Ce serait bien mieux pour Python de se tenir debout sur ses deux pieds. C'est même correct si Python lui-même est écrit en C, mais le problème est l'existence d'un mécanisme d'extension qui encourage les gens à étendre Python d'une manière qui dépend de C.
BrenBarn

4
épée à double tranchant - une partie de ce qui a rendu le python si populaire est sa capacité à étendre d'autres applications et à être étendu par d'autres applications. Si vous enlevez cela, je ne pense pas que nous parlerions de python.
Tritium21

10
@BrenBarn C'est une folie totale de prétendre que la dépendance de Python à C est préjudiciable. Sans l'API C-Python, la plupart des bibliothèques vraiment puissantes et de la grande interopérabilité que Python a acquises dans son adolescence formatrice (fin des années 90), y compris l'écosystème numérique / scientifique et les interfaces GUI, n'auraient pas été possibles. Regardez autour de vous pour avoir une idée de tout l'univers des utilisations de Python, avant de faire de telles déclarations générales.
Peter Wang

4
@PeterWang Toutes ces bibliothèques peuvent être écrites en Python, mais elles ne seraient pas aussi rapides qu'elles le sont. Ce que BrenBarn dit, c'est que nous avons maintenant la possibilité de rendre python assez rapide pour que ces bibliothèques puissent être écrites en python, mais nous refusons de prendre cette chance, car cela signifie perdre la possibilité d'utiliser les bibliothèques C. Je crois que c'est ce qu'il entendait par nuisible, non pas que l'existence de bibliothèques C soit une mauvaise chose mais que la seule façon de faire des bibliothèques rapides est d'utiliser C.
vikki

14

J'ai fait un petit benchmark sur ce sujet. Bien que la plupart des autres affiches aient fait de bons points sur la compatibilité, mon expérience a été que PyPy n'est pas beaucoup plus rapide pour se déplacer uniquement sur les bits. Pour de nombreuses utilisations de Python, il n'existe vraiment que pour traduire des bits entre deux ou plusieurs services. Par exemple, peu d'applications Web effectuent des analyses gourmandes en CPU des jeux de données. Au lieu de cela, ils prennent quelques octets d'un client, les stockent dans une sorte de base de données, puis les renvoient à d'autres clients. Parfois, le format des données est modifié.

Le BDFL et les développeurs CPython sont un groupe de personnes remarquablement intelligent et ont réussi à aider CPython à exceller dans un tel scénario. Voici une fiche de blog sans vergogne: http://www.hydrogen18.com/blog/unpickling-buffers.html . J'utilise Stackless, qui est dérivé de CPython et conserve l'interface complète du module C. Je n'ai trouvé aucun avantage à utiliser PyPy dans ce cas.


1
PyPy a de nombreux benchmarks soigneusement exécutés (contrairement à CPython malheureusement, qui n'a pas vraiment de suite de benchmarks pour l'utilisateur pour le moment). Bien sûr, pour le trafic réseau, PyPy ne peut magiquement rien accélérer.
Julian

1
Julian, il convient de noter que les gens de PyPy ont concentré leurs efforts sur l'amélioration des temps d'exécution de cette suite de référence particulière depuis des années. Dans une certaine mesure, il semble qu'ils "suradaptent" leurs optimisations à cet ensemble de repères et, selon mon expérience, à part les calculs purement numériques (qui sont de toute façon mieux dans Fortran ou C99), je n'ai jamais eu PyPy pour être plus que ~ 2X plus rapide que CPython.
Alex Rubinsteyn

9
@AlexRubinsteyn Mais l'opinion de ceux qui travaillent sur PyPy a toujours été généralement que si vous trouvez un cas où PyPy est plus lent que CPython, et que vous pouvez le transformer en une référence raisonnable, il a de bonnes chances d'être ajouté à la suite.
gsnedders

1
J'ai vérifié ton blog. Dans vos résultats, la paire plain-python de (pickle, StringIO) montre que pypy est environ 6,8 fois plus rapide que cpython. Je pense que c'est un résultat utile. Dans votre conclusion, vous signalez (correctement) que le code Pypy (qui est du python ordinaire!) Est plus lent que le code C (cPickle, cStringIO), pas le code Cpython.
Caleb Hattingh

1
@gsnedders J'ai proposé à plusieurs reprises une référence basée sur le rinohtype . Ils ne l'ont pas encore ajouté à la suite.
Brecht Machiels

12

Q: Si PyPy peut résoudre ces grands défis (vitesse, consommation de mémoire, parallélisme) par rapport à CPython, quelles sont ses faiblesses qui empêchent une adoption plus large?

R: Premièrement, il y a peu de preuves que l'équipe PyPy peut résoudre le problème de vitesse en général . Des preuves à long terme montrent que PyPy exécute certains codes Python plus lentement que CPython et cet inconvénient semble être profondément enraciné dans PyPy.

Deuxièmement, la version actuelle de PyPy consomme beaucoup plus de mémoire que CPython dans un ensemble assez large de cas. PyPy n'a donc pas encore résolu le problème de consommation de mémoire.

Que PyPy résout les grands défis mentionnés et sera en général plus rapide, moins gourmand en mémoire et plus convivial pour le parallélisme que CPython est une question ouverte qui ne peut pas être résolue à court terme. Certaines personnes parient que PyPy ne sera jamais en mesure de proposer une solution générale lui permettant de dominer CPython 2.7 et 3.3 dans tous les cas.

Si PyPy réussit à être meilleur que CPython en général, ce qui est discutable, la principale faiblesse affectant son adoption plus large sera sa compatibilité avec CPython. Il existe également des problèmes tels que le fait que CPython s'exécute sur une plus large gamme de processeurs et de systèmes d'exploitation, mais ces problèmes sont beaucoup moins importants par rapport aux performances de PyPy et aux objectifs de compatibilité CPython.


Q: Pourquoi ne puis-je pas supprimer le remplacement de CPython par PyPy maintenant?

R: PyPy n'est pas 100% compatible avec CPython car il ne simule pas CPython sous le capot. Certains programmes peuvent toujours dépendre des fonctionnalités uniques de CPython qui sont absentes dans PyPy telles que les liaisons C, les implémentations C de l'objet et des méthodes Python, ou la nature incrémentielle du garbage collector de CPython.


Cette réponse ne cite aucun référentiel ni ne fournit de références.
qwr

7

CPython a un comptage de référence et une récupération de place, PyPy a uniquement une récupération de place.

Les objets ont donc tendance à être supprimés plus tôt et __del__sont appelés de manière plus prévisible dans CPython. Certains logiciels dépendent de ce comportement, ils ne sont donc pas prêts à migrer vers PyPy.

Certains autres logiciels fonctionnent avec les deux, mais utilisent moins de mémoire avec CPython, car les objets inutilisés sont libérés plus tôt. (Je n'ai pas de mesures pour indiquer son importance et quels autres détails d'implémentation affectent l'utilisation de la mémoire.)


17
Il faut souligner que compter sur __del__être appelé tôt ou pas du tout est faux, même en CPython. Comme vous le dites, cela fonctionne généralement et certaines personnes pensent que c'est garanti. Si quelque chose qui fait référence à l'objet est rattrapé dans un cycle de référence (ce qui est plutôt facile - saviez-vous que l'inspection de l'exception actuelle d'une certaine manière non artificielle crée un cycle de référence?) La finalisation est retardée indéfiniment, jusqu'au cycle suivant GC (qui peut ne jamais l' être ). Si l'objet fait lui-même partie d'un cycle de référence, __del__il ne sera pas appelé du tout (avant Python 3.4).

3
La surcharge par objet est plus élevée dans CPython, ce qui compte BEAUCOUP une fois que vous commencez à créer de nombreux objets. Je crois que PyPy fait l'équivalent des slots par défaut, pour une chose.

4

Pour beaucoup de projets, il y a en fait 0% de différence entre les différents pythons en termes de vitesse. Ce sont ceux qui sont dominés par le temps d'ingénierie et où tous les pythons ont la même quantité de support de bibliothèque.


1
Si votre projet est aussi simple que cela, cela n'a évidemment pas d'importance, mais la même chose pourrait être dite de n'importe quelle implémentation de n'importe quel langage: si tout ce que vous faites est d'agréger les fonctions d'autres bibliothèques via des ABI relativement performants, alors tout n'est pas pertinent.

1
Cela n'a rien à voir avec le simple. En temps d'ingénierie, la boucle de rétroaction est importante. Parfois beaucoup plus important que le temps d'exécution.
Stephan Eggermont

1
Eh bien, vous parlez très vaguement (temps d'ingénierie sans référence à ce qui est conçu, quelles sont les contraintes, etc.; boucle de rétroaction sans référence à ce qui est renvoyé à qui, etc.), donc je vais de se retirer de cette conversation plutôt que d'échanger des références cryptiques.

Rien de vague ici. Jetez un œil à la boucle OODA, ou PDCA.
Stephan Eggermont

3
@user Eh bien, tout projet à exécution unique qui prend un mois à écrire et une minute à exécuter aura une vitesse globale de 0,0% (1 mois + 1 min vs 1 mois) par rapport à l'utilisation de PyPy, même si PyPy était mille fois plus rapide. Stephan ne prétendait pas que tous les projets auraient une accélération de 0%.
gmatht

4

Pour faire simple: PyPy fournit la vitesse qui manque à CPython mais sacrifie sa compatibilité. La plupart des gens, cependant, choisissent Python pour sa flexibilité et sa fonctionnalité "batterie incluse" (haute compatibilité), pas pour sa vitesse (il est quand même préféré).


16
"batterie incluse" signifie grande bibliothèque standard , AFAIK
tshepang

4

J'ai trouvé des exemples, où PyPy est plus lent que Python. Mais: uniquement sous Windows.

C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop

C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop

Donc, si vous pensez à PyPy, oubliez Windows. Sous Linux, vous pouvez réaliser des accélérations impressionnantes. Exemple (liste tous les nombres premiers entre 1 et 1 000 000):

from sympy import sieve
primes = list(sieve.primerange(1, 10**6))

Cela s'exécute 10 (!) Fois plus vite sur PyPy que sur Python. Mais pas sur les fenêtres. Là, il n'est que 3 fois plus rapide.


Intéressant! Des comparaisons et des chiffres supplémentaires auraient été formidables.
ben26941

1

PyPy a pris en charge Python 3 depuis un certain temps, mais selon ce post HackerNoon d'Anthony Shaw du 2 avril 2018 , PyPy3 est encore plusieurs fois plus lent que PyPy (Python 2).

Pour de nombreux calculs scientifiques, en particulier les calculs matriciels, numpy est un meilleur choix (voir FAQ: Dois-je installer numpy ou numpypy? ).

Pypy ne prend pas en charge gmpy2. Vous pouvez plutôt utiliser gmpy_cffi même si je n'ai pas testé sa vitesse et que le projet a eu une version en 2014.

Pour les problèmes de Project Euler, j'utilise fréquemment PyPy, et pour de simples calculs numériques, c'est souvent from __future__ import divisionsuffisant pour mes besoins, mais la prise en charge de Python 3 est toujours en cours de travail à partir de 2018, avec votre meilleur pari étant sur Linux 64 bits. Windows PyPy3.5 v6.0, le dernier en date de décembre 2018, est en version bêta.


0

Versions Python prises en charge

Pour citer le Zen de Python :

La lisibilité compte.

Par exemple, Python 3.7 a introduit les classes de données et Python 3.8 a introduit fstring = .

Il pourrait y avoir d'autres fonctionnalités dans Python 3.7 et Python 3.8 qui sont plus importantes pour vous. Le fait est que PyPy ne prend pas en charge Python 3.7 ou Python 3.8 pour le moment.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.