4 fonctionnalités utiles que vous ne verrez pas en Python

Python possède de nombreuses fonctionnalités intéressantes – commodité, un large éventail de bibliothèques puissantes, une communauté d’utilisateurs utile – mais quelques éléments manquent encore. Certaines fonctionnalités trouvées dans d’autres langages faciliteraient certaines tâches, mais elles n’arriveront pas de sitôt sur Python.

Voici quatre fonctionnalités de langage couramment demandées qui ne sont actuellement pas dans les cartes pour Python. Au moins deux d’entre eux ne se produiront jamais, tandis que les autres sont, au mieux, des années plus tard. Nous verrons ce qui bloque ces fonctionnalités ou ce qu’il faudrait pour les inclure dans une future version de Python.

Non : une version compilée et typée statiquement de Python

Certains développeurs rêvent d’un Python qui utilise le typage statique pour compiler en code machine natif. Le typage flexible est la source d’une grande partie de la lenteur de Python, après tout, et le typage statique mettrait fin à cela. Le typage statique donne également aux programmeurs de solides garanties sur ce à quoi s’attendre de leur code. Alors, quel est le problème ?

Bien que Python ait des indications de type, elles sont destinées à rendre le langage plus propice à l’analyse statique au moment de l’édition, au moyen d’outils de linting. Seuls les projets tiers (tels que pydantic) utilisent des indications de type lors de l’exécution. Le runtime Python en lui-même n’utilise pas d’indications de type.

L’un des objectifs explicites de la PEP 484, la proposition d’amélioration de Python pour l’indication de type, était que les indications de type soient toujours facultatives. “Python restera un langage typé dynamiquement, et les auteurs n’ont aucune envie de rendre les indications de type obligatoires, même par convention.”

Les développeurs qui veulent vraiment une version statiquement typée de Python peuvent se tourner vers Cython ou mypyc, mais même ces projets s’accompagnent de compromis. Dans le cas de Cython, la plus grande amélioration des performances provient de l’utilisation de types et de structures C purs et de la réduction de l’utilisation de l’environnement d’exécution Python. En termes simples, il est difficile d’accélérer la compilation de Python sans sacrifier son dynamisme. Il est beaucoup plus facile de prendre les parties qui n’ont pas besoin de dynamisme, de les séparer et de les accélérer.

Non : les lambdas multilignes

Les expressions lambda de Python, ou fonctions anonymes, sont délibérément limitées. Ils n’autorisent qu’une seule expression (essentiellement, tout ce qui se trouve à droite de la = sign dans une opération d’affectation) comme corps de la fonction. Les développeurs venant à Python à partir de langages comme JavaScript, où les fonctions anonymes multilignes sont la norme, demandent souvent cette fonctionnalité en Python.

Le créateur de Python, Guido van Rossum, a depuis longtemps rejeté l’idée qu’un lambda soit tout sauf du sucre syntaxique pour une seule expression. Sa position est mieux résumée dans un e-mail de 2006, où il explique pourquoi les lambdas multilignes ne sont pas et ne seront pas une chose en Python :

  • Les lambdas multilignes ajouteraient peu ou pas de puissance ou d’expressivité réelle à Python, et se feraient au prix d’en faire un langage moins lisible. (La lisibilité est une préoccupation majeure pour Python.)
  • Aucune syntaxe utilisable n’a été proposée qui s’intégrerait élégamment avec le reste de la conception sensible aux espaces blancs de Python.
  • Il faut peu d’efforts pour convertir un lambda multiligne en une fonction complète, ce que van Rossum recommande comme cas d’utilisation pour un scénario “lambda multiligne”, de toute façon.

Inutile de dire que l’avenir ne s’annonce pas brillant pour les lambdas multilignes en Python.

Peu probable : un Python sans GIL

Le Global Interpreter Lock, ou GIL, a longtemps été une épine dans le pied pour les amateurs de Python. GIL synchronise l’activité au sein de l’environnement d’exécution Python pour sérialiser l’accès aux objets et gérer l’état global. L’inconvénient de GIL est qu’il rend le runtime Python monothread dans la pratique. Si vous voulez un véritable parallélisme avec les threads, vous devez lancer des copies discrètes de l’interpréteur Python et exécuter des threads séparés sur chacun d’eux. Python sans GIL pourrait, en théorie, permettre un parallélisme beaucoup plus important, et donc une amélioration des performances. Alors, pourquoi est-ce peu probable ?

Il y a eu diverses propositions pour supprimer GIL de Python. La plupart briseraient la rétrocompatibilité, ou rendraient Python plus lent pour les opérations à un seul thread, ou feraient les deux. Un effort, le projet “GILectomy” s’est accompagné d’une sérieuse pénalité de performance. Python 3.x a retravaillé GIL pour améliorer ses performances de base, mais ne l’a pas supprimé afin de préserver la rétrocompatibilité.

En raison de ces préoccupations, GIL peut simplement être une réalité pour les utilisateurs de Python. Mais il existe des possibilités d’améliorer ses performances. Une façon de permettre un meilleur parallélisme dans le runtime Python serait d’exécuter plusieurs interpréteurs dans un seul processus. Faire de cette proposition une réalité nécessiterait des modifications importantes des composants internes de Python, notamment la refonte de certaines parties de l’API C de Python. De nombreux modules tiers dépendent de l’API C et doivent également être mis à jour.

Une proposition plus récente, PEP 684, développe l’idée de plusieurs interprètes pour que chaque sous-interprète utilise son propre GIL. Dans ce cas, la modification proposée permettrait également de partager stratégiquement des objets qui devaient être partagés entre les sous-interprètes.

Peut-être : un compilateur JIT natif Python

Un moyen éprouvé de rendre Python plus rapide tout en conservant la flexibilité bien-aimée du langage consiste à utiliser un compilateur juste-à-temps, ou JAT. La compilation JIT consiste à analyser le code au moment de l’exécution, plutôt qu’à l’avance, et à le compiler de manière sélective ou entièrement en code machine en fonction des comportements qu’il présente pendant son exécution.

Les JIT existent déjà pour Python. PyPy, l’exemple le plus couramment utilisé et le mieux développé, excelle à faire en sorte que les applications de type serveur de longue durée offrent des performances améliorées sans modifier le code source du programme. Mais la version de référence de Python, CPython, bénéficierait-elle d’un JIT quelconque ?

Les récentes initiatives visant à rendre Python plus rapide, discutées lors du Python Language Summit 2021, ont généré quelques propositions dans ce sens. Plutôt que d’implémenter un JIT complet en Python, les propositions actuelles impliquent l’ajout de comportements adaptatifs à l’interpréteur pour une exécution plus rapide dans des cas spécialisés courants. Il pourrait y avoir de la place pour d’autres types de spécialisation de type JIT à l’avenir, comme la génération de code machine pour des chemins de code vraiment à grande vitesse. Mais le plan à court terme est d’apporter des améliorations qui étendent l’interpréteur existant plutôt que de le remplacer.

Copyright © 2022 IDG Communications, Inc.

Leave a Comment