CPython - CPython

CPython
Logo Python et wordmark.svg
Auteur(s) original(aux) Guido van Rossum
Développeur(s) Les développeurs principaux de Python et la communauté Python, soutenus par la Python Software Foundation
Première version 26 janvier 1994 ; il y a 27 ans ( 1994-01-26 )
Version stable
3.10.0 / 4 octobre 2021 ; il y a 6 jours ( 2021-10-04 )
Dépôt https://github.com/python/cpython
Écrit en C , Python
Plate-forme 42 plateformes ; voir § Répartition
Disponible en Anglais
Taper Interprète du langage de programmation Python
Licence Licence Python Software Foundation
Site Internet www .python .org

CPython est l' implémentation de référence du langage de programmation Python . Écrit en C et Python, CPython est l'implémentation par défaut et la plus largement utilisée du langage Python.

CPython peut être défini à la fois comme un interpréteur et un compilateur car il compile le code Python en bytecode avant de l'interpréter. Il possède une interface de fonction étrangère avec plusieurs langages, dont le C, dans lequel il faut explicitement écrire des liaisons dans un langage autre que Python.

Concevoir

Une caractéristique particulière de CPython est qu'il utilise un verrou d'interpréteur global (GIL) sur chaque processus interpréteur CPython , ce qui signifie qu'au sein d'un seul processus, un seul thread peut traiter le bytecode Python à la fois. Cela ne veut pas dire qu'il n'y a aucun intérêt à faire du multithreading ; le scénario de multithreading le plus courant est celui où les threads attendent principalement que des processus externes se terminent.

Cela peut se produire lorsque plusieurs threads desservent des clients distincts. Un thread peut attendre la réponse d'un client et un autre peut attendre l' exécution d'une requête de base de données , tandis que le troisième thread traite en fait du code Python.

Cependant, le GIL signifie que CPython n'est pas adapté aux processus qui implémentent des algorithmes gourmands en CPU dans du code Python qui pourraient potentiellement être distribués sur plusieurs cœurs.

Dans les applications du monde réel, les situations où le GIL est un goulot d'étranglement important sont assez rares. En effet, Python est un langage intrinsèquement lent et n'est généralement pas utilisé pour les opérations gourmandes en ressources CPU ou sensibles au temps. Python est généralement utilisé au niveau supérieur et appelle des fonctions dans les bibliothèques pour effectuer des tâches spécialisées. Ces bibliothèques ne sont généralement pas écrites en Python, et le code Python dans un autre thread peut être exécuté pendant qu'un appel à l'un de ces processus sous-jacents a lieu. La bibliothèque non Python appelée pour effectuer la tâche gourmande en CPU n'est pas soumise au GIL et peut exécuter simultanément de nombreux threads sur plusieurs processeurs sans restriction.

La simultanéité du code Python ne peut être obtenue qu'avec des processus d'interpréteur CPython distincts gérés par un système d'exploitation multitâche . Cela complique la communication entre les processus Python simultanés , bien que le module de multitraitement atténue quelque peu cela ; cela signifie que les applications qui peuvent réellement bénéficier de l'exécution simultanée de code Python peuvent être implémentées avec une quantité limitée de surcharge .

La présence du GIL simplifie la mise en œuvre de CPython et facilite la mise en œuvre d'applications multithread qui ne bénéficient pas de l'exécution simultanée de code Python. Cependant, sans GIL, les applications de multitraitement doivent s'assurer que tout le code commun est thread-safe.

Bien que de nombreuses propositions aient été faites pour éliminer le GIL, le consensus général a été que dans la plupart des cas, les avantages du GIL l'emportent sur les inconvénients ; dans les quelques cas où le GIL est un goulot d'étranglement, l'application doit être construite autour de la structure multitraitement.

Histoire

Hirondelle égarée

Unladen Swallow était une branche d'optimisation de CPython, destinée à être entièrement compatible et nettement plus rapide. Il visait à atteindre ses objectifs en complétant la machine virtuelle personnalisée de CPython avec un compilateur juste-à-temps construit à l'aide de LLVM .

Le projet avait pour objectif d'améliorer la vitesse d'un facteur cinq par rapport à CPython ; cet objectif n'a pas été atteint.

Le projet a été parrainé par Google et les propriétaires du projet, Thomas Wouters, Jeffrey Yasskin et Collin Winter, sont des employés à temps plein de Google. cependant, la plupart des contributeurs au projet n'étaient pas des employés de Google. Unladen Swallow était hébergé sur Google Code .

Comme beaucoup de choses concernant le langage Python, le nom Unladen Swallow est une référence aux Monty Python , en particulier à la blague sur la vitesse des hirondelles à vide dans Monty Python et le Saint Graal .

Bien qu'il n'ait pas atteint tous les objectifs publiés, Unladen Swallow a produit du code qui a été ajouté à l'implémentation principale de Python, comme des améliorations du module cPickle.

En juillet 2010, certains observateurs ont spéculé sur le fait que le projet était mort ou mourant puisque le jalon du quatrième trimestre 2009 n'avait pas encore été publié. Le trafic sur la liste de diffusion d'Unladen est passé de 500 messages en janvier 2010 à moins de 10 en septembre 2010. Il a également été signalé que Unladen a perdu le financement de Google. En novembre 2010, l'un des principaux développeurs a annoncé que « Jeffrey et moi avons été entraînés vers d'autres projets de plus grande importance pour Google ».

La branche développement T4 2009 a été créée le 26 janvier 2010, mais aucune publicité n'a été faite sur le site. De plus, en ce qui concerne les plans à long terme, et comme le projet a raté la version Python 2.7, une proposition d'amélioration de Python (PEP) a été acceptée, qui proposait une fusion de Unladen Swallow dans une branche spéciale py3k-jit du référentiel officiel de Python . En juillet 2010, ces travaux étaient en cours. Cette fusion aurait pris un certain temps, car Unladen Swallow était à l'origine basé sur Python 2.6 avec lequel Python 3 a rompu la compatibilité (voir Python 3000 pour plus de détails). Cependant, le PEP a été retiré par la suite.

Début 2011, il est devenu clair que le projet était arrêté.

Historique de sortie de Swallow à vide

  • 2009 T1
  • 2009 T2
  • 2009 Q3 : réduire l'utilisation de la mémoire, améliorer la vitesse

Distribution

Les plates-formes prises en charge incluent :

Unix-like
Spécial et intégré
Autre

PEP 11 répertorie les plates-formes qui ne sont pas prises en charge dans CPython par la Python Software Foundation . Ces plates-formes peuvent toujours être prises en charge par des ports externes. Ces ports comprennent :

  • AtheOS (non pris en charge depuis 2.6)
  • BeOS (non pris en charge depuis 2.6)
  • DOS (non pris en charge depuis 2.0)
  • IRIX 4 (non pris en charge depuis 2.3)
  • IRIX 5 et versions ultérieures (non pris en charge depuis 3.2, 3.7)
  • Mac OS 9 (non pris en charge depuis 2.4)
  • MINIX (non pris en charge depuis 2.3)
  • OpenVMS (non pris en charge depuis 3.3)
  • OS/2 (non pris en charge depuis 3.3)
  • RISC OS (non pris en charge depuis 3.0)
  • Windows XP (non pris en charge depuis 3.5)
  • Windows 2000 (non pris en charge depuis 3.3)
  • Windows 3.x (non pris en charge depuis 2.0)
  • Windows 9x (non pris en charge depuis 2.6)
  • Windows NT4 (non supporté depuis 2.6)

Les ports externes non intégrés à la version officielle de CPython de Python Software Foundation, avec des liens vers son site de développement principal, incluent souvent des modules supplémentaires pour des fonctionnalités spécifiques à la plate-forme, comme l'API graphique et sonore pour PSP et SMS et l'API de caméra pour S60. Ces ports comprennent :

Linux d'entreprise

Ces versions Python sont distribuées avec les distributions Linux d'entreprise actuellement prises en charge. Le statut de support de Python dans le tableau fait référence au support de l'équipe principale Python, et non du mainteneur de la distribution.

Linux d'entreprise
Version de diffusion Distribution en fin de vie Version Python
Ubuntu 20.04 LTS (Fosse focale) 2030-04 Ancienne version, mais toujours maintenue : 3.8
Ubuntu 18.04 LTS (Castor bionique) 2028-04 Ancienne version, plus maintenue : 2.7 Ancienne version, mais toujours maintenue : 3.6
Ubuntu 16.04 LTS (Xenial Xerus) 2021-04-30 Ancienne version, plus maintenue : 2.7 Ancienne version, plus maintenue : 3.5
Debian 10 2024-06 Ancienne version, plus maintenue : 2.7 Ancienne version, mais toujours maintenue : 3.7
Debian 9 2022-06-30 Ancienne version, plus maintenue : 2.7 Ancienne version, plus maintenue : 3.5
Red Hat Enterprise Linux 8 2029 Ancienne version, plus maintenue : 2.7 Ancienne version, mais toujours maintenue : 3.6
Red Hat Enterprise Linux 7 2024-11-30 Ancienne version, plus maintenue : 2.7
CentOS 8 2029-05-31 Ancienne version, plus maintenue : 2.7 Ancienne version, mais toujours maintenue : 3.6
CentOS 7 2024-06-30 Ancienne version, plus maintenue : 2.7
Serveur d'entreprise SUSE Linux 15 2031-07-31 Ancienne version, plus maintenue : 2.7 Ancienne version, mais toujours maintenue : 3.6
Serveur d'entreprise SUSE Linux 12 2027-10-31 Ancienne version, plus maintenue : 2.7
Serveur d'entreprise SUSE Linux 11 2022-03-31 Ancienne version, plus maintenue : 2.7
Légende:
Ancienne version
Ancienne version, toujours maintenue
Dernière version
Dernière version d'aperçu
Version future

Alternatives

CPython est l'une des nombreuses implémentations Python de « qualité production », notamment : Jython , écrit en Java pour la machine virtuelle Java (JVM), PyPy , écrit en RPython et traduit en C, et IronPython , écrit en C# pour le langage commun Infrastructures . Il existe également plusieurs implémentations expérimentales.

Les références

Lectures complémentaires

  • Shaw, Antoine (2021). CPython Internals: Votre guide de l'interprète Python 3 . Vrai Python. ISBN 9781775093343.

Liens externes