Jetzt ist ein guter Zeitpunkt, zu Free-Threading Python beizutragen
Ich möchte kurz zusammenfassen, was ich bisher auf der PyCon US 2025 über Free-Threading Python erfahren habe, und erläutern, wie man dazu beitragen kann.
Was ist Free-Threading Python?
Free-Threading Python ist ein Projekt mit dem Ziel, den GIL (Global Interpreter Lock) aus Python zu entfernen, um die Leistung in Multithreading-Umgebungen zu verbessern. Das Projekt wurde gestartet, um die Multithreading-Performance von Python zu verbessern und bei CPU-gebundenen Aufgaben eine bessere Leistung zu bieten.
Es befindet sich noch in einer experimentellen Phase, und man muss es entweder neu kompilieren und installieren oder über uv installieren.
Aktuelle Situation
Ich selbst habe es bisher nur getestet, aber es heißt, dass die meisten reinen Python-Bibliotheken ohne Probleme verwendbar sind. Allerdings laden viele allgemein verbreitete Bibliotheken aus Performance- oder Implementierungsgründen in C/C++ geschriebene Bibliotheken oder implementieren Erweiterungen direkt selbst. Um solche Bibliotheken mit Free-Threading Python zu verwenden, muss man daher verschiedene Ansätze nutzen.
Wenn Erweiterungsmodule verwendet werden
Meistens kommen die folgenden Methoden zum Einsatz, und es gibt einen Porting Guide.
- C API
- Cython
- PyBind11
- nanonbind
- PyO3
- f2py
CFFI wird noch nicht unterstützt, aber mit dem Fork von Quansight ist Unterstützung möglich.
Es gibt ein Issue, in dem erklärt wird, dass es nicht unterstützt werden soll, aber da CFFI meist für Interfacing verwendet wird, ist diese Entscheidung nachvollziehbar. Mit dem geforkten CFFI kann man Free-Threading Python verwenden, aber da die Implementierung nicht besonders fein abgestimmt ist, dürfte die Performance leiden.
Wie man beitragen kann
Ab hier fühlt es sich an, als würde man sich in einen tiefen Schacht stürzen, aber als ich am Sprint teilgenommen habe, waren alle sehr positiv eingestellt, daher scheint es weiterhin ein guter Zeitpunkt zu sein, um beizutragen. Möglichkeiten zur Mitarbeit sind die folgenden.
Anhand der folgenden Ressourcen prüfen, wie gut die Kompatibilität mit free-threading-python ist
- Free-threaded Python Library Compatibility Checker
- 🧵 Free-Threaded Wheels
- Compatibility Status Tracking#
Nach dem Testen ein Issue erstellen
Installieren Sie zuerst Python 3.13 mit Free-Threading, installieren Sie dann die Bibliothek und führen Sie die Tests aus.
Wenn möglich, wäre es auch gut, Version 3.14t auszuprobieren, aber da sie noch Beta ist, empfiehlt es sich zunächst mit Version 3.13 zu beginnen.
Portieren und einen PR einreichen
Ab hier wird es etwas schwieriger. Man braucht ein gewisses Verständnis von Multithreading, verschiedenen System Calls sowie von C/C++ und dem Inneren von Python.
Die größte Schwierigkeit besteht darin, dass Bibliotheken häufig voneinander abhängen. Wenn man also andere Bibliotheken verwendet und eine davon noch keinen Support bietet, muss man dort zuerst ansetzen.
Ich habe bei der Teilnahme am Sprint selbst auch nur einen Überblick gewonnen, aber in etwa sieht es so aus.
- fastapi -> uvicorn -> uvloop, cryptography, pycares
Einen Artikel darüber schreiben, wie man beitragen kann
Genau das mache ich gerade, auch wenn es sicher nicht perfekt ist. Schreiben wir Artikel dazu und veröffentlichen wir sie an verschiedenen Orten.
Eine Anleitung zur Nutzung von free-threading-python schreiben
Da es nur wenige Texte dazu auf Koreanisch gibt, ist es sinnvoll, Performance-Tests durchzuführen, die Nutzung zu beschreiben, alles zu ordnen und als Artikel zu veröffentlichen.
Warum man gerade jetzt beitragen sollte
Ich bin seit etwas mehr als 25 Jahren Teil des Open-Source-Ökosystems. Ich selbst bin kein bedeutender Open-Source-Contributor, aber viele Menschen in meinem Umfeld leisten zahlreiche Beiträge, darunter sogar zwei CPython Core Developer und viele weitere. Durch Gespräche mit ihnen habe ich ein bestimmtes Gespür entwickelt.
Es ist gut, in einer Phase beizutragen, in der noch nichts da ist oder große Umbrüche stattfinden. Ein Beispiel: Jang Hye, die in den Anfangszeiten von Python beigetragen hat, hat vieles gemacht, unter anderem Unicode und koreanische Codecs. Damals gab es noch kaum etwas, und da die Haupt-Contributors sich mit koreanischen Codecs nicht auskannten, war der Einstieg vermutlich vergleichsweise leicht. Der nächste große Umbruch kam dann mit dem Übergang zu Python 3. Danach war es vor allem der Bereich asyncio; dort ist mir Kim Jun-gi in Erinnerung geblieben, neben vielen anderen. Und jetzt gibt es wieder eine neue Funktion: Free-Threading. Ich denke, genau jetzt ist der beste Zeitpunkt, um beizutragen.
In anderen Sprachen werden Änderungen oft von Unternehmen entschieden oder in Frameworks umgesetzt, die bereits von großen Konzernen verwaltet werden, was Beiträge nicht gerade einfach macht. Natürlich ist auch Python nicht extrem leicht zugänglich, aber es gibt unzählige Bibliotheken und Frameworks, und im Moment können sie alle nach und nach portiert werden. Dafür werden viele Mitwirkende gebraucht, und genau deshalb ist jetzt der richtige Zeitpunkt.
12 Kommentare
Ein wesentlicher Grund für die Beliebtheit von Python war wohl auch, dass man sich um solche Überlegungen zum Multithreading nicht kümmern musste. Wenn man sogar so etwas berücksichtigen muss, wird es für normale Nutzer wohl zu einer Sprache, die sich nicht mehr leicht verwenden lässt.
Es ist noch eine optionale Funktion, und Multithreading wird mit hoher Wahrscheinlichkeit weiterhin optional bleiben. (zum Beispiel, indem man die Option aktiviert oder eine separate Installation verwendet usw.)
Ich selbst nutze Type auch kaum, und free-threading würde ich wegen Leistungsproblemen wohl nur in sehr begrenzten Fällen einsetzen.
Ich betrachte das nicht als optional. Sobald PEP 779 angenommen ist, besteht das Ziel darin, die Standardimplementierung künftig auf Free-Threaded umzustellen.
Es war ungefähr mit der Absicht gemeint, ob man es nicht einfach verwenden kann, ohne groß darüber nachzudenken, so wie
type. Hehe.Free-Threading Python – das ist wirklich alles andere als einfach. Es fühlt sich an, als würde man die Büchse der Pandora öffnen. Da besteht die Möglichkeit, dass alle möglichen Synchronisations-Bugs, die bisher verborgen waren, massenhaft auftauchen. Und zwar nur ganz gelegentlich und dann zur Laufzeit. Die Probleme, die bei der Multithreading-Entwicklung ohnehin schon lästig waren, könnten nun auch in Python richtig ernst werden. Wenn man sich nur schon die C-Familie ansieht, dann führen Stellen, an denen nicht thread-safe Funktionen verwendet werden, sofort zu Problemen.
Es wäre schön, wenn ein Agent erscheinen würde, der das automatisch portiert und testet!
Da es um Multi-Threading-Probleme geht, wird es nicht einfach sein.
Man muss es nicht selbst bauen; über deadsnakes oder die offiziellen Installer für Windows und macOS lässt es sich ebenfalls ganz einfach installieren!
Es gibt ziemlich viele Tippfehler. seufz Ich konnte es hier nicht aktualisieren, deshalb habe ich den Blog aktualisiert.
Hallo, ich melde mich, weil mir dieser Beitrag über eine Google-Empfehlung angezeigt wurde. Ich habe 5 Jahre als Python-Entwickler im Ausland gearbeitet (insgesamt 13 Jahre in der allgemeinen Softwareentwicklung) und mache gerade eine kurze Pause in Korea. Ich würde gern beitragen … Könnten Sie mir vielleicht eine E-Mail-Adresse geben? Ich würde Sie kontaktieren und mehr darüber lernen wollen.
Meine E-Mail-Adresse ist josephroh@naver.com. Vielen Dank.
Ich habe Ihnen eine E-Mail geschickt. Danke.