Was ändert der Free-Threaded Build aus PEP 703 an dem Code, den du schreibst?

Der Free-Threaded Build, seit CPython 3.13 als optionaler Interpreter ausgeliefert, entfernt das GIL, sodass mehrere Threads Python-Bytecode parallel ausführen können. Dein Code wird echt nebenläufig, und damit werden Races, die das GIL früher versteckt hat, real. Du brauchst explizite Locks um geteilten veränderlichen Zustand, und du musst prüfen, ob jede C-Extension, von der du abhängst, das unterstützt.

Free Threading kam in 3.13 als experimenteller Build und ist seitdem gereift, und der entscheidende Punkt ist, dass es ein separater Interpreter ist, für den du dich aktiv entscheidest, und nicht etwas, das sich klammheimlich unter allen geändert hätte. Ohne Lock können zwei Threads gleichzeitig Bytecode auf zwei Kernen ausführen, sodass ein CPU-lastiger Worker-Pool endlich skaliert, ohne Prozessstart und Pickling zu bezahlen. Der Preis ist Korrektheit. Unter dem alten Build ist eine Menge schlampiger Code mit unsynchronisierten dict-Updates davongekommen, weil eine Bytecode-Grenze selten an der falschen Stelle lag. Jetzt sind das ehrliche Data Races und du brauchst ein Lock oder eine Queue. Ich habe es an einem Scoring-Job probiert, der Arbeit auf vier Prozesse verteilt hat, und Threads haben ähnlichen Durchsatz bei deutlich kleinerem Speicherbedarf gebracht, weil das Modell einmal geladen blieb statt viermal. Der Blocker für Produktion waren die Extensions. Alles mit einer C-Schicht muss gegen das Free-Threaded ABI neu gebaut werden, also würde ich vor dem Ausrollen den Dependency-Baum durchgehen und prüfen, was die Maintainer veröffentlicht haben.