Python n’en finit pas d’évoluer. A chaque itération, le langage lui-même et sa distribution de référence CPython (fournie par python.org) proposent de nouvelles simplifications. A mesure que le nombre de ses utilisateurs et de ses cas d’usage augmente, certaines de ses limites deviennent néanmoins de plus en plus évidentes. Les prochaines améliorations à réaliser sont dictées par les exigences qui s’imposent dans plusieurs domaines, en particulier l’automatisation, l’apprentissage machine et les micro-services.

1 - Accélérer le démarrage

L’équipe de développement du langage a axé ses efforts dans 4 directions principales et, en premier lieu, sur la rapidité de démarrage de l’interpréteur CPython. A l'évidence, celle-ci pose un problème. Victor Stinner, développeur du noyau CPython a démontré que la version 3.7 démarre de 2,3 à 2,8 plus lentement que Python 2.7. A titre de comparaison, Perl 5 et PHP 7 se lancent 5 à 10 fois plus vite que Python 3. Cela n’incite guère les utilisateurs des v.2.x à migrer, d’autant plus que la fin de cycle de Python 2 n’est pas prévue avec 2020. Pas plus que cela n’incite à utiliser Python, et plus spécifiquement CPython, dans des environnements où la rapidité de démarrage fait partie des pré-requis, par exemple s’il doit être utilisé comme runtime dans un container. Plus le démarrage est rapide, plus vite le container sera prêt pour accepter des commandes et plus le langage sera efficace dans n’importe quel environnement conteneurisé (AWS Lambda par exemple).

2 - Optimiser l'utilisation des « named tupples »

Les named tuples sont l’une des voies explorées par les développeurs du noyau CPython pour accélérer le runtime et son démarrage. En Python, les tuples sont des listes d’objets qui ne peuvent pas être modifiées, comme des entiers ou des chaînes de caractères, objets auxquels on accède par l’intermédiaire d’un index qui indique leur position – élément 0, élément 1, etc. Les tuples nommés (named tuples), que l’on trouve dans la bibliothèque Python standard, permettent d’accéder à ces éléments par le biais d’un attribut .dot, par exemple address.zip_code au lieu de address[3]. Cela peut simplifier considérablement la lecture du code. Toutefois, l’actuelle mise en œuvre des tuples nommés pourrait être l’une des causes de la lenteur de Python au démarrage. Le créateur du langage, Guido van Rossum a donc considéré qu'ils devraient être très sérieusement optimisés dans CPython, à la fois pour améliorer ce point, mais aussi pour les bénéfices qui devraient en découler en cascade pour toutes les applications tierces utilisant CPython. L’un des aspects mis en avant par Guido van Rossum est que les éléments du langage qui sont le plus couramment utilisés par les développeurs devraient être disponibles sous une forme native dans CPython – c’est-à-dire en C plutôt qu’en Python – afin de pouvoir les accélérer. « Cette approche consistant à générer du code source et à l’exécuter [à travers exec()] est une belle démonstration de puissance de Python, mais j’ai toujours eu le sentiment qu’à chaque fois que nous nous trouvons en face d’un idiome populaire qui utilise exec() et eval(), nous devrions l’ajouter au langage, ou dans les fonctions pré-définies [built-in] pour éviter ces appels », écrit Guido van Rossum le 17 juillet dernier.

3 - Réécrire l'API C de CPython

Un certain nombre de limitations de CPython ont une cause commune : la nécessité de maintenir une compatibilité ascendante sur son API C. En théorie, CPython pourrait être réécrit pour apporter d’énormes améliorations de performances, mais au risque de casser la compatibilité avec de très nombreux logiciels. La communauté Python s’est longtemps enorgueilli de ne pas procéder à ce genre de ruptures, sauf entre deux versions majeures (Python 2 vs Python 3). L’une des possibilités, comme le propose Victor Stinner, développeur core Python, serait de retravailler l’API C pour cacher les détails de son exécution. De cette façon, les développeurs pourraient plus facilement aborder de nouvelles optimisations potentiellement susceptibles de causer des problèmes – par exemple abandonner le Global Interpreter Lock, GIL. Les tests pour ce réusinage de code pourraient être menés non seulement avec la propre suite de test de CPython, mais aussi avec les packages tiers les plus couramment utilisés qui se connectent à l’API, tels que NumPy et SciPy. Revisiter l’API pourrait apporter d’autres bénéfices. On pourrait naviguer plus facilement dans le code de CPython et le comprendre plus aisément. Cela permettrait d’abaisser la barre pour les contributeurs potentiels. Et cela viendrait compléter les mesures déjà prises par l’équipe de CPython - comme le transfert du code vers le référentiel GitHub - afin de maintenir l’intérêt des développeurs et des contributeurs. 

4 - Se débarrasser (peut-être) du Global Interpreter Lock

S’il y a bien une limitation qui est couramment désignée comme devant être résolue, c’est celle que pose le Global Interpreter Lock. Le GIL assure, entre autres choses, que l’accès mémoire à chaque objet utilisé par CPython soit « thread-safe », c’est-à-dire qu’un objet Python ne puisse être utilisé que par un seul fil à la fois. Cela signifie que CPython est single-threaded. Les opérations multithreadées liées au CPU doivent ou bien être traitées par le biais d’extensions C ou bien par de multiples instances de CPython. Jusqu’à présent, ces inconvénients étaient acceptés. Mais avec la progression limitée de la cadence des CPU et la prolifération des coeurs, Python pourrait perdre du terrain au profit de langages qui prennent nativement en charge le multithreading. Bien sûr, beaucoup d’applications importantes de Python, comme l’apprentissage machine et l’analyse statistique, sont accélérées par l’intermédiaire de code C qui n’est pas lié au GIL. Mais le problème devient de plus en plus difficile à ignorer.

Une solution qui soit native à Python serait plus portable à travers les plateformes et plus flexible à travers les applications. Ce serait aussi plus simple à exploiter pour les développeurs. La plus récente tentative de suppression du GIL - la Gilectomy, comme l’appelle le développeur CPython Larry Hastings - montre que supprimer seulement le GIL n’apporte pas une réponse complète. Il est possible de s'en passer, mais seulement au prix de la compatibilité ascendante avec les applications Python existantes, principalement des extensions en C. Toute tentative de le supprimer doit donc être compatible avec l'API C. Jusqu’à présent, les essais ont montré que cela pénalisait énormément les performances, ainsi que Larry Hastings l’a démontré lors d’une intervention sur la conférence PyCon 2017. Pour l’instant, tous ces essais restent provisoires et expérimentaux et ils doivent tenir compte de la façon dont Python est concrètement utilisé sur le terrain. Mais une fois que le réusinage de l’API CPython sera achevé, il sera sans doute plus facile d’abandonner le GIL. 

En septembre 2017, à l’indice Tiobe des langages les plus populaires, Python se maintient en 5ème place, comme en septembre 2016, derrière Java (1er), C, C++ et C#. Tandis que le site Stack Overflow a mis en évidence au début du mois la forte progression du langage sur les 5 dernières années.