C’est le bon moment pour contribuer à Free-Threading Python
À PyCon US 2025, je vais résumer brièvement ce que j’ai compris jusqu’à présent de Free-Threading Python et faire le point sur la manière d’y contribuer.
Qu’est-ce que Free-Threading Python ?
Free-Threading Python est un projet qui vise à supprimer le GIL (Global Interpreter Lock) de Python afin d’améliorer les performances dans les environnements multithread. Le projet a été lancé pour améliorer les performances du multithreading en Python et offrir de meilleures performances pour les tâches CPU-bound.
Il en est encore au stade expérimental, et il faut soit le recompiler pour l’installer, soit passer par uv.
Situation actuelle
Je n’ai fait que quelques tests moi-même, mais il paraît que la plupart des bibliothèques Python pures fonctionnent sans problème. En revanche, comme la plupart des bibliothèques couramment utilisées s’appuient sur des bibliothèques C/C++ pour des raisons de performances ou d’implémentation, ou sont directement développées sous forme d’extensions, ces bibliothèques doivent recourir à différentes approches pour fonctionner avec Free-Threading Python.
En cas d’utilisation de modules d’extension
La plupart utilisent les méthodes suivantes, et il existe un guide de portage.
- C API
- Cython
- PyBind11
- nanonbind
- PyO3
- f2py
CFFI n’est pas encore pris en charge, mais il est possible d’obtenir ce support via le fork de Quansight.
Il existe une issue indiquant qu’ils ne comptent pas le prendre en charge, mais c’est une décision compréhensible puisque CFFI est principalement utilisé pour l’interfaçage. En utilisant ce fork de CFFI, il est possible d’utiliser Free-Threading Python, mais comme l’implémentation n’est pas très fine, les performances risquent d’être en retrait.
Comment contribuer
À partir d’ici, on a un peu l’impression de se jeter dans un puits sans fond, mais quand j’ai participé au sprint, tout le monde était très positif, donc cela semble encore être un bon moment pour contribuer. Voici différentes façons de le faire.
Vérifier la compatibilité avec free-threading-python à l’aide des références suivantes
- Free-threaded Python Library Compatibility Checker
- 🧵 Free-Threaded Wheels
- Compatibility Status Tracking#
Ouvrir une issue après les tests
Installez d’abord Python 3.13 en version free-threading, puis installez la bibliothèque et lancez les tests.
Si possible, il serait bien d’essayer aussi la version 3.14t, mais comme elle est encore en bêta, mieux vaut commencer par la 3.13.
Faire le portage et envoyer une PR
À partir de là, cela devient un peu plus difficile. Il faut une certaine compréhension du multithreading, de divers appels système, ainsi que de C/C++ et des internals de Python.
La difficulté principale est que les bibliothèques ont souvent des dépendances entre elles : si vous utilisez d’autres bibliothèques et que celles-ci ne sont pas encore prises en charge, il faut commencer par là.
J’ai moi aussi surtout pris la mesure du sujet en participant au sprint, mais cela donne quelque chose comme ceci.
- fastapi -> uvicorn -> uvloop, cryptography, pycares
Écrire un article expliquant comment contribuer
C’est ce que je suis en train de faire, même si cela reste sans doute insuffisant. Écrivons-en et publions-le à plusieurs endroits.
Écrire un guide d’utilisation de free-threading-python
Comme il manque d’articles en coréen, il serait utile de faire des tests de performance, d’expliquer l’utilisation, de structurer tout cela et de le publier sous forme d’article.
Pourquoi faut-il contribuer maintenant ?
Je pense que cela fait un peu plus de 25 ans que je suis dans l’écosystème open source. Je ne suis pas un grand contributeur open source, mais beaucoup de mes proches contribuent activement, et il y a même deux CPython Core Developers parmi eux, sans parler des autres. En échangeant avec eux, j’ai développé une certaine intuition.
C’est une bonne chose de contribuer lorsqu’il n’y a encore rien, ou pendant une période de grand bouleversement. Par exemple, au début de Python, Jang Hye a contribué à beaucoup de choses, mais notamment à Unicode et aux codecs coréens. À l’époque, il n’y avait encore rien, et comme les principaux contributeurs ne connaissaient pas les codecs coréens, j’imagine que l’entrée était relativement accessible. Le changement majeur suivant a été la transition vers Python 3. Ensuite, il y a eu tout ce qui touche à asyncio ; de ce côté, Kim Jun-gi m’a marqué, mais il y en a bien d’autres. Et maintenant, une nouvelle fonctionnalité est arrivée : free-threading. Je pense que c’est le meilleur moment pour contribuer.
Dans d’autres langages, les changements sont souvent décidés en entreprise ou au sein de frameworks déjà gérés par de grandes sociétés, ce qui rend les contributions moins faciles. Bien sûr, Python n’est pas non plus extrêmement facile d’accès, mais il existe une multitude de bibliothèques et de frameworks, et comme ils peuvent désormais être portés un par un et qu’il faut beaucoup de main-d’œuvre, c’est précisément le moment de s’y mettre.
12 commentaires
L’une des grandes raisons de la popularité de Python, c’est justement qu’il n’était pas nécessaire de prendre en compte ce genre de considérations liées au multithreading. S’il faut aller jusque-là, cela risque de devenir un langage que le grand public ne pourra plus utiliser facilement.
C’est encore une fonctionnalité optionnelle, et il est très probable que le multithreading reste une option. ( l’activer, faire une installation séparée, etc. )
Moi non plus je n’utilise pas beaucoup Type, et je pense que je n’emploierai le free-threading que de manière très limitée à cause des enjeux de performance.
Je ne considère pas cela comme optionnel. Une fois la PEP 779 approuvée, l’objectif est à terme de faire de l’implémentation par défaut une version free-threaded.
L’intention était plutôt de dire qu’on pouvait peut-être l’utiliser sans trop se prendre la tête, comme
type. Hé hé.Le free threading de Python, ça n’a vraiment pas l’air d’être une mince affaire. Ça donne l’impression d’ouvrir la boîte de Pandore. Il y a un risque que toutes sortes de bugs de synchronisation jusque-là cachés se mettent à proliférer. Et en plus, qu’ils n’explosent qu’occasionnellement à l’exécution. Les problèmes déjà pénibles en développement multithread pourraient maintenant devenir un vrai sujet aussi en Python. Rien qu’en regardant la famille du C, l’utilisation de fonctions qui ne sont pas thread-safe poserait immédiatement problème.
Ce serait bien qu’un agent apparaisse pour faire automatiquement le portage et les tests !
Comme il s’agit d’un problème de multithreading, ce ne sera pas facile.
Pas besoin de le compiler vous-même : on peut l’installer facilement via deadsnakes ou les installateurs officiels Windows et macOS !
Il y a pas mal de fautes de frappe. T_T Je n’ai pas pu faire la mise à jour ici, donc je l’ai faite sur le blog.
Bonjour, j’ai découvert ce post via les recommandations de Google et je vous contacte. J’ai 5 ans d’expérience en développement Python à l’étranger (13 ans en développement au total), mais je fais une petite pause en Corée en ce moment. J’aimerais contribuer… Pourriez-vous éventuellement me communiquer votre adresse e-mail ? Je souhaiterais vous contacter et en apprendre davantage à ce sujet.
Mon e-mail est josephroh@naver.com. Merci.
Je vous ai envoyé un e-mail. Merci.