Stand der Entwicklung von No-GIL-CPython

• Der Python-Lenkungsausschuss hat angekündigt, den Global Interpreter Lock (GIL) in künftigen Python-Releases optional zu machen
• PEP 703 ist noch ein Vorschlag in Diskussion, die Details werden noch festgelegt
• Die no-GIL-Version von Python dürfte einige der schwierigsten Probleme der Informatik lösen, insbesondere das Benennungsproblem
• Der Autor von PEP 703, Sam Gross, diskutierte die Wechselwirkung zwischen dem Vorschlag und der stabilen ABI von CPython
• Die stabile ABI wird für Erweiterungen verwendet, um binäre Wheels zu ermöglichen, die mit mehreren CPython-Versionen kompatibel sind
• Der Vorschlag geht von einer einzelnen CPython-Version ohne GIL aus, aber bis dahin wird es Interpreter-Builds geben, mit denen sich der no-GIL-Betrieb testen lässt
• Erweiterungen, die für die stabile ABI erstellt wurden, sind nicht mit no-GIL-CPython 3.13 kompatibel, aber Gross schlägt vor, sie nach dieser Version so zu ändern, dass sie mit zwei Arten von CPython-Builds funktionieren
• Die Diskussion über die Benennung der no-GIL-Version wurde in einen separaten Thread ausgelagert
• Der Lenkungsausschuss einigte sich darauf, den Namen "nogil" zur Beschreibung des Builds zu vermeiden, und schlug stattdessen "free-threading" als Alternative vor
• Die endgültige Genehmigung von PEP 703 steht noch aus, und der Lenkungsausschuss arbeitet daran, die Genehmigungskriterien zu präzisieren
• Es wird erwartet, dass die no-GIL-Version von CPython in den kommenden fünf Jahren und darüber hinaus erhebliche Auswirkungen auf die Entwicklung von CPython und sein Ökosystem haben wird

[GN⁺]

Hacker-News-Kommentare

• Diskussion über den aktuellen Stand von No-GIL CPython
• Es wird die Ansicht vertreten, dass explizite Parallelität im modernen Computing wichtiger werden sollte und dass sich Python an diesen Trend anpassen muss
• Sorge, dass nach dem Entfernen des GIL in mehrthreadigem Python-Code Data Races und fehlerhafte Operationen auftreten könnten
• Frage nach der Umsetzbarkeit eines statischen Analysators, der nach der Entfernung des GIL potenzielle Probleme in bestehenden Python-Programmen identifizieren könnte
• Einige Kommentierende vergleichen die Weiterentwicklung von Python mit OCaml und fragen sich, ob es Ähnlichkeiten zwischen den beiden Projekten gibt
• Debatte über den aktuellen Fokus auf GIL-loses Python; einige argumentieren, dass eine verbesserte Single-Thread-Performance wichtiger sei als echtes Multithreading
• Einige Kommentierende schlagen vor, den GIL beizubehalten, aber JavaScript-ähnliche Workers einzuführen, wobei jeder Worker-Thread eine isolierte VM mit eigenem GIL hat
• Ebenfalls diskutiert wird der lange und schwierige Übergang von Python 2 zu Python 3; einige meinen, die Python-Community hätte diese Gelegenheit nutzen können, um größere Änderungen im Inneren des Interpreters vorzunehmen
• Es wird Neugier darüber geäußert, welche potenziellen Anwendungen und Services von No-GIL Python profitieren könnten und was sich Entwickler von dieser Entwicklung erhoffen