Le véritable superpouvoir de Python

Voici un résumé de la keynote de Hynek Schlawack, « Le véritable superpouvoir de Python », présentée à PYCON UK 2025.

Avant de commencer sa présentation, l’intervenant a brièvement présenté son parcours, en évoquant notamment les 14 années passées dans la communauté PyCon et cette « amitié haineuse » qu’il y a vécue.

---

La transition de Python 2 vers 3 (The Python 2 to 3 Migration)

• Contexte : Python 3.0 est sorti pour la première fois en 2008. Il n’était pas destiné à un usage grand public, mais à montrer les objectifs de Python et à recueillir des retours. Son usage a été recommandé à partir de Python 3.2.
• Principaux changements :
  • Traitement des chaînes : Python 3 a fait passer le type de chaîne par défaut des bytes, adaptés aux machines, à l’Unicode, adapté aux humains.
  • Suppression des comportements implicites : de nombreux comportements implicites sur lesquels les développeurs s’appuyaient par erreur, comme la comparaison entre chaînes et nombres possible en Python 2, ont été supprimés. Ils provoquaient des bugs difficiles à déboguer.
  • Amélioration de l’internationalisation : les bases de code Python 2 étaient remplies d’erreurs de décodage Unicode, et Python 3 a amélioré cet aspect pour devenir un langage davantage tourné vers l’international.
• Difficultés de la transition :
  • Coût pour la communauté : porter tout l’écosystème vers Python 3 a représenté un coût énorme. Il a fallu porter une grande quantité de logiciels, à une époque où la couverture de tests n’était pas encore généralisée.
  • Développement de bases de code mixtes : un consensus sur la manière d’écrire des bases de code hybrides fonctionnant à la fois sur Python 2 et Python 3 n’a émergé qu’en 2012, avec la sortie de Python 3.3.
  • Moratoire sur le langage : entre Python 3.0 et 3.3, très peu de nouvelles fonctionnalités ont été ajoutées, ce qui donnait peu de raisons aux développeurs de migrer vers Python 3.
  • Incertitude : rien ne garantissait que Python 3 deviendrait la version dominante, et un échec à la Perl 6 restait possible.
• Pourquoi Python a survécu :
  • Arrivée de nouveaux utilisateurs : Python attirait plus de nouveaux utilisateurs qu’il n’en perdait, alors même que d’autres langages comme Go et Rust étaient en pleine croissance.
  • Communautés scientifique et d’ingénierie : les scientifiques et les ingénieurs utilisent Python depuis longtemps, et à partir du milieu des années 2010, sa popularité a explosé dans la data science. Aujourd’hui, plus de la moitié des utilisateurs de Python s’en servent pour l’exploration et le traitement des données.
  • Écosystème existant : un puissant écosystème de bibliothèques de calcul scientifique, comme NumPy, existait déjà.
  • Facilité d’interaction avec d’autres langages compilés : Python interagit facilement avec d’autres langages compilés, ce qui lui permet de jouer un rôle de « colle » entre des composants haute performance écrits en C, C++, Fortran ou Rust.
  • Programmation exploratoire : Python se prête très bien à la programmation exploratoire grâce au shell interactif (REPL) et à des outils comme Jupyter Notebook.
  • Gradualité : Python offre plusieurs niveaux d’exigence. Les développeurs peuvent travailler de manière souple pendant la phase d’expérimentation, puis renforcer la rigueur en production à l’aide d’outils comme les annotations de type, les linters et les tests. Il est aussi possible de partir d’un Jupyter Notebook pour aller jusqu’à un service web, ce qui illustre la variété des cas d’usage couverts par Python.

---

Le véritable superpouvoir de Python : la gradualité (Graduality)

• Python n’a pas seulement une faible barrière à l’entrée : il offre aussi plusieurs plafonds élevés, ce qui permet aux utilisateurs de l’exploiter avec souplesse selon leurs besoins.
• Les deux faces de la gradualité :
  • Aspect positif : les utilisateurs peuvent choisir le niveau de rigueur et de complexité qui leur convient. Par exemple, on peut écrire librement un script sans annotations de type, puis appliquer des vérifications de type strictes dans une application de grande taille.
  • Aspect négatif : ajouter des cas particuliers ou des exceptions à un système apporte une commodité immédiate à certains utilisateurs, mais augmente à long terme la complexité globale du système. L’intervenant souligne que « facile » ne veut pas toujours dire « simple », ce que l’on voit bien dans le système de packaging de Python.

---

Exemple de problème de packaging (Packaging Problem Example)

• Il existe deux façons de structurer une application Python : l’approche « ad hoc » et l’approche « package ». L’approche package est mieux définie et dispose d’outils intégrés, mais pour des raisons historiques, l’approche ad hoc continue elle aussi à être prise en charge.
• Cela rend des problèmes comme sys.path difficiles à comprendre, et des fonctionnalités comme pip install --user créent des problèmes dans l’espace de noms global, ce qui complique le débogage.
• De nouveaux outils comme UV ne prenaient initialement en charge que l’approche package, mais ont fini par ajouter le support des projets ad hoc, ce qui a encore accru la complexité.
• Ces « attractive nuisances » apportent une commodité à court terme, mais finissent par coûter cher à la communauté sur le long terme.

---

Architecture logicielle (Software Architecture)

• L’intervenant souligne le manque de discussions sur l’architecture logicielle dans la communauté Python, qu’il attribue à la fois à une aversion pour les « enterprise patterns » et à la « peur de devenir Java ».
• Nécessité : pour construire et maintenir des systèmes logiciels complexes, il est essentiel de discuter d’architecture logicielle afin d’organiser et de gérer les modules, les couches et leurs interactions.
• Solutions :
  • La communauté Python doit éviter de clore les discussions avec des termes comme « pythonic » ou « unpythonic ».
  • Elle doit apprendre des bonnes pratiques d’autres communautés de langages et les appliquer, comme le domain-driven design.
  • Davantage de personnes devraient partager leurs connaissances sur l’architecture logicielle, produire du contenu sur le sujet et se concentrer sur les solutions.

---

Conclusion (Conclusion)

• Il ne faut pas être anxieux à propos de Python, mais embrasser les différentes façons d’écrire du Python.
• Il faut essayer de nouveaux styles et de nouveaux outils afin d’élargir sa manière de penser.
• Les options ont un coût ; il faut donc réfléchir attentivement à l’impact d’une fonctionnalité donnée sur l’ensemble de la communauté.
• Aux côtés du travail consistant à rendre les choses simples faciles à faire, il faut aussi investir davantage d’efforts pour rendre les choses complexes possibles.
• Il faut multiplier les discussions sur l’architecture logicielle et remettre en question les réflexes dogmatiques pour conduire Python vers un avenir meilleur.

Cette présentation embrasse le passé, le présent et l’avenir de la communauté Python. Elle met en avant la « gradualité » comme véritable force du langage, tout en offrant un regard approfondi sur les défis auxquels la communauté fait face et sur les barrières culturelles qu’elle doit surmonter.

Pour voir la vidéo, consultez le lien suivant : https://youtu.be/gDvwRpl9erE

[3ae3ae]

Ce serait tellement plus pratique si un gestionnaire de paquets moderne dans le style de uv devenait la norme, mais j’imagine que ça sera difficile...

[click]

Au début de mes études, Python 2 restait encore de justesse la version la plus répandue, puis au moment où j’ai obtenu mon diplôme, tout le monde était passé à Python 3, de ce dont je me souviens.

[meteorizer]

Si l’on travaille dans le code, même si l’on utilise surtout Python, la plupart des gens maîtrisent au moins un autre langage.
Je ne comprends pas cette volonté d’introduire sans cesse dans Python des fonctionnalités ou des caractéristiques venues d’autres langages au nom de son amélioration.
On a l’impression qu’on oublie que ce qui manque à Python fait aussi partie des raisons de son succès.
Python devient peu à peu bizarrement complexe et exigeant.
J’ai l’impression que les avantages de Python sont en train de disparaître.
Au lieu d’essayer de transformer Python en Java, autant utiliser Java quand c’est nécessaire.
Et si ce n’est pas Java, il y a aussi Kotlin et Scala.
Cela dit, je ne pense pas que Python va disparaître.
Parce qu’en réalité, il n’existe pratiquement pas d’autre langage qui permette de coder avec autant de simplicité.