CPython - CPython
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 |
Version stable | 3.10.0 / 4 octobre 2021
|
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 |
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
- AROS
- OS/390
- Windows Vista et versions ultérieures
- z/OS
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 :
- Amiga : AmigaPython
- IBM i : iSeriesPython
- DOS utilisant DJGPP : PythonD
- MorphOS : Python 2 et 3
- PlayStation Portable : Python sans pile pour PSP
- OS Symbian : Python pour S60
- Windows CE / Pocket PC : Port Python Windows CE
- OpenVMS : Les ports de Python 3.x sont maintenus par VSI
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.
Version de diffusion | Distribution en fin de vie | Version Python | |
---|---|---|---|
Ubuntu 20.04 LTS (Fosse focale) | 2030-04 | 3.8 | |
Ubuntu 18.04 LTS (Castor bionique) | 2028-04 | 2.7 | 3.6 |
Ubuntu 16.04 LTS (Xenial Xerus) | 2021-04-30 | 2.7 | 3.5 |
Debian 10 | 2024-06 | 2.7 | 3.7 |
Debian 9 | 2022-06-30 | 2.7 | 3.5 |
Red Hat Enterprise Linux 8 | 2029 | 2.7 | 3.6 |
Red Hat Enterprise Linux 7 | 2024-11-30 | 2.7 | |
CentOS 8 | 2029-05-31 | 2.7 | 3.6 |
CentOS 7 | 2024-06-30 | 2.7 | |
Serveur d'entreprise SUSE Linux 15 | 2031-07-31 | 2.7 | 3.6 |
Serveur d'entreprise SUSE Linux 12 | 2027-10-31 | 2.7 | |
Serveur d'entreprise SUSE Linux 11 | 2022-03-31 | 2.7 | |
Ancienne version
Ancienne version, toujours maintenue
Dernière version
|
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.