Transcript: Python 3.13

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Paisen-Podcast. Heute Jubiläumsepisode 60.

Hi Jochen.

Oh, Jubiläum. Herzlichen Glückwunsch und auch herzlich willkommen Dominik.

Ja, hey. Auch unsere Gäste.

Genau, ja, beziehungsweise...

Lieber Johannes, dich kennt man von.

Ja, genau.

Hallo zusammen und herzlichen Glückwunsch zur 60. Episode.

Danke. Und lieber TF, auch dir.

Ja, vielen Dank, hallo.

Du warst ja auch schon mal da, habe ich noch in Erinnerung.

Genau, Januar 23 haben wir gerade rekonstruiert.

Ja, wir sprechen heute über Python 3.13. Und ich würde sagen, da legen wir auch direkt los.

Ja, wollen wir noch News machen oder nicht?

Ich wollte gerade sagen, mit den News.

Genau, das ist natürlich irgendwie schon ein bisschen her. Wir sind ein bisschen spät dran. Aber es ist vielleicht auch noch interessant. Es gibt ein paar schöne Sachen, die man darüber erzählen kann, oder?

Ja, also wollen wir direkt

Python-Reihe 13 kommen wir auch direkt.

War gar nicht so viel los, oder?

Nee, sonst war auch nicht so viel los, stimmt.

Dann machen wir das doch direkt, ja.

Also ja, dann erzähl uns was.

Ich hab's jetzt auch schon überall

irgendwie installiert, wo ich irgendwie

Projekte angefasst habe und es funktioniert super.

Und

genau, ja, jetzt

haben wir da so einige Dinge.

Vielleicht fangen wir einfach tatsächlich mit der

neuen REPL an.

Irgendwie die halt aus dem

Pile-Pile-Projekt

übernommen wurde.

Mit der neuen REPL.

Was ist eine REPL?

Ja, so eine Read-Eval-Print-Loop.

Irgendwie das, was man bekommt, wenn man

einfach nur Python eingibt und unterdrückt.

Also nutzt ihr schon 3.13? Alle?

Außer Jochen?

Nee, ich habe es noch nicht installiert.

Ich nutze es nicht, ich nutze aber die neue REPL.

Ah, das ist natürlich ein

Spezialeinheit. Ja gut, ich benutze IPython überall.

Warum nicht Bipython?

Das hatten wir vorhin

vorgespräch schon mal kurz besprochen.

Also ich fand die Begründung interessant, warum sie

eigentlich überhaupt die REPL verbessern, wenn sie

sowieso ja wissen, dass die meisten

Leute halt sich sowieso als erstes erstmal IPython

installieren, weil das halt

viel viel netter ist. Aber der

Grund scheint zu sein, dass die

CPython Core Devs halt

während sie quasi dann die nächste

Version entwickeln, erstmal

geht PyPI nicht und

pip nicht und

IPython geht vielleicht auch nicht auf der neuen Version und

damit sie es quasi beim Entwickeln etwas netter haben,

haben sie sich quasi den schöneren Multi-Line-Edit,

schönere History-Farben-Rapple implementiert,

der jetzt in 3.13 released wird.

Also ich finde es auch toll, weil ich bin ja zu faul für iPython

und ich mache das eigentlich sonst immer klassisch.

Und toll, endlich, bunt.

Die Welt verbessert durch Eigennutzer, also Sauerei.

Ja, also das mit den Farben finde ich relativ abgefahren tatsächlich.

Also ich habe jetzt seit, weiß ich nicht, Oktober

jetzt auch den Farbing-Rapple.

Und wenn ich dann aber eine alte Version benutze

und es ist dann plötzlich nur noch schwarz-weiß

und es ist ja gar nicht so viel Farbe,

es sind ja wirklich nur die größer als Zeichen,

aber das kommt einem dann fast schon altbacken vor.

Ja, Back to the Future, das ist schon ein bisschen wie damals.

Aber schade, dass es nicht früher noch grün war oder so,

aber ein echter Hacker und so.

Ja, die Farbauswahl, die die C-Python-Entwickler getroffen haben,

das war ein riesen Diskussionsthema.

Das ist halt so Bike-Shedding-mäßig.

Also da kann man halt gut drüber diskutieren.

Und das Problem ist, dass man halt aus der Shell raus

nicht rausfinden kann, ob die Shell auf schwarz auf weiß

oder weiß auf schwarz eingestellt ist.

Das heißt, man muss Farben wählen, die bei beiden Hintergrundfarben

quasi noch einen einigermaßen brauchbaren Kontrast dann ergeben.

Und deswegen ist dieses Pink und Rot ein bisschen so ein Kompromiss,

weil das halt sowohl auf dem schwarzen Hintergrund

als auch auf dem weißen Hintergrund noch einigermaßen gut lesbar bleibt.

Ach okay, interessant.

Ja, aber

genau,

wie kommt das denn, dass du

die REPL schon verwendet

hast, obwohl gar nicht...

Ja, also die REPL ist

das ist quasi die PyPy REPL

nicht ganz, also die haben total viele neue Features

eingebaut und Bugs gefixt und so, aber so

dieses Kernfeature, dass es eben

Multiline Edit

gibt, also

vielleicht können wir auch kurz sagen, was das ist, also

wenn man quasi auf der Python

Shell eine Funktion angibt, die halt über mehrere Zeilen

geht und man macht dann irgendwie so einen Tippfehler

in Zeile 2 von 8,

dann musste man bisher halt quasi dann

mit der History Zeile für Zeile in der richtigen

Reihenfolge dann

die Funktion wieder so neu zusammensetzen, die

entsprechende kaputte Zeile dann reparieren

und dann die anderen wieder über die History holen

und das ist halt total nervig. Und deswegen

gibt es jetzt eben

Multiline Edit und PyPi hatte das,

wie ich gerade schon gesagt habe, schon quasi schon immer,

also in Anführungszeichen, also

seit PyPi 2.4 oder

2.5 oder so hatten wir das, dass man halt

quasi, wenn man nach einer Funktion

Pfeil nach oben drückt, dann kriegt man halt die ganze Funktion über

mehrere Zeilen. Man kann dann auch wie in einem Editor

mit Pfeil nach oben dann in die früheren Zeilen

der Funktion, kann das einfach editieren, geht

dann wieder ans Ende und mit Enter

definiert man dann die Funktion neu.

Und das hat ja halt, sagen wir mal,

zwei der frühen

Piper-Entwickler einfach so als

in Anführungszeichen normalen Python-Code geschrieben. Das war

einfach, also das hat eigentlich

keine Piper-spezifischen Features irgendwie

gebraucht. Michael Hudson,

Doyle und Armin Rigo waren das.

Und

so ungefähr von einem Jahr haben halt zwei

der C-Python-Entwickler, Luca Schlanger

und Galindo Salgado

gesagt, dass sie das auch gern für C-Python hätten.

Beziehungsweise die haben halt versucht,

sich zu überlegen, wie sie den Ripple verbessern können.

Der Ripple war bisher in C-Python NC geschrieben

und das macht halt alle Verbesserungen daran

relativ nervig und aufwendig.

Und dann haben sie halt geguckt, woher man vielleicht Python-Code

nehmen könnte, der irgendwie

einen Teil des Problems schon löst, ohne dann alles nochmal

neu machen zu müssen und dann habe ich

halt gesagt, dass sie vielleicht sich mal

anschauen könnten, was PyPy da hat und dann haben sie das eben

übernommen, angepasst,

den Code auch total verbessert,

weil in PyPy ist der auch immer noch

Python 2 kompatibel,

weil wir auch immer noch Python 2 Versionen releasen

und

also das haben die quasi so ein bisschen

Grund überholt und neue Tests geschrieben und so

und eben auch einiges an neuen Featuren

hinzugefügt, also

ich habe ein paar Notizen dazu gemacht, also einmal

die Farben, die haben wir nicht gehabt,

Dann diesen Paste-Mode, den es jetzt gibt, also wenn man quasi aus der Zwischenablage irgendwie mehrere Zeilen Code einfügt, dann geht ja oft die Einrückung kaputt und das ist jetzt eben auch repariert. Auch Support für Windows hatten wir bisher auch nicht und halt die Farben.

Was ich tatsächlich auch nicht kannte,

war, dass man einfach so ein Skript reinfügen

kann. Ich habe gehört, dass das schon ein bisschen älter ist. Ich weiß aber nicht,

bei welcher Version das reingekommen ist. Man kann

eine Environment-Variable setzen und dann

wird ein Skript ausgefügt. Das heißt, du hast deine

Imports, die du immer machst, direkt

mit dabei, wenn du zum Beispiel diese

setzt. Deine Lieblingsmodule?

Ja, nur sieben.

Sieben?

Finde ich ziemlich cool. Man kann dann lustige Sachen machen.

Python Starter heißt das.

Ja. Ja, ist ja

sehr schön. Muss ich unbedingt für

mein System auch bauen.

Ja, aber genau, also

ein großer Vorteil ist glaube ich auch jetzt,

dass es war vorher irgendwie

direkt in C, glaube ich, geschrieben

und jetzt ist es halt auch

Pure Python sozusagen und ich glaube, da kann man

jetzt auch einfach eine ganze Menge mehr

an die Innereien rankommen und dann auch das Verhalten so

ändern, dass man da eine ganze Menge lustige

Dinge mit tun kann.

Lukas Schlager hatte da auf der

Pure Python auch einen Vortrag gehalten.

Das war ein Performance-Vortrag.

Oder eine Performance performt.

Live-Musik-Coding-Geschichten.

Und da ist es natürlich praktisch, wenn man halt...

Lustig war, dass der Tontechniker,

der hat einen Euroreg dabei gehabt

und hat irgendwie so einen hohen Ton auf seinem Synthesizer gespielt.

Da hat der Tontechniker kurz Angst bekommen,

dass seine Anlage Schrott geht.

Hat alles runtergedreht auf so 20% Lautstärke oder sowas.

Und auf einmal war es sehr leise.

Und dann hat er fünf Minuten so gespielt.

Und irgendwann hat jemand geklopft beim Tontechniker

und hat dann überredet und gesagt,

ja, Lukas, wird diese hohen Frequenzen

jetzt nicht mehr spielen? Und dann durfte er wieder lauter drehen.

Ja, ich glaube,

das sieht man auch jetzt schon so ein bisschen. Es gibt halt einfach

viel mehr Bug Reports und Patches, was den neuen Rappel angeht.

Es ist immer noch so, dass es schon

so ein bisschen nervig ist, daran zu arbeiten, weil

wenn der Rappel kaputt ist, dann sieht man halt auch gleich

nichts mehr. Also der Debugger geht nicht

und also es ist schon,

die haben da schon

so ein bisschen eigene debugging-Sachen eingebaut.

Aber es ist schon

noch so, es bleibt so ein bisschen frickelig.

Aber ich glaube, man kann auch die alte wieder aktivieren.

Irgendwie insofern hat man da vielleicht die Möglichkeit,

auch mit der Umgebungsvariable wieder auf die alten Dings zu kommen.

Aber ja, klar, ist natürlich, wenn man es kaputt macht,

dann ein Problem.

Ah ja, wichtiges anderes neue Feature ist natürlich,

dass man jetzt bei Exit keine Klammern mehr braucht.

Oh ja.

Ja, und ich glaube, Quid geht auch.

Ja, vielleicht ist das so.

Ich meine, ja.

Ja, und Help geht auch irgendwie jetzt anders.

Aber ehrlich gesagt, keine Ahnung genau, wie.

Ja, es gibt jetzt diesen Help-Mode, der eingebaut ist mit F1.

Und dann kann man quasi aus der

Shell in so eine spezielle Help-Shell

wechseln. Und von da dann,

wenn man quasi die Namen von irgendwelchen Sachen, die man

dokumentiert haben möchte, eingibt, dann kriegt man die

direkt angezeigt.

Aber bei Print braucht man schon noch Klammern, oder?

Nee.

Ich möchte so etwas

Python 2 wieder haben.

Soll ich das mal als Feature-Request

vorschlagen? Also das kannst du jetzt auf jeden Fall

für deine

Raffle-Katze einbauen, dass sie sich dann wieder

in Python 2... Kann ich das machen?

Das mit dem Exit ist tatsächlich was,

was halt Newbies sich relativ

oft wünschen.

Q reicht, glaube ich, auch.

Ist das so?

Q reicht? Nee.

Warum steht denn das da?

Weiß nicht. Ach, für den Head-Mode.

Also Crit geht, aber

Q nicht. Schade.

Adidas QQ, da muss man direkt wieder in das

Skript reinschreiben.

Ja, aber so ist es auf jeden Fall

toll. Also ich finde das auch super, dass man da jetzt

irgendwie echt

eine ganz brauchbare Geschichte eingebaut hat

und gut, klar, also iPython

ist natürlich auch nicht schlecht oder wie Python

oder so, aber. Ja und dann

daran angelegt, wir haben jetzt Farben ja schon angesprochen, vielleicht können wir noch

über die Tracebacks sprechen.

Also in 3.11

gab es ja jetzt schon die Verbesserung, dass wir quasi

in Tracebacks diese

genaueren Positionen innerhalb

von der Zeile kriegen. Wie sagt man, Dechle, Johannes?

Genau. Dechle, ja.

Da, wo ich herkomme, sagt man Dechle.

Sind halt auch keine Dächer, sondern nur kleine

Dächer. So groß sind die gar nicht.

Ist halt so.

Genau, also es wird

jetzt quasi nicht mehr nur gesagt, das ist halt in Zeile

5 der Fehler, sondern auch noch dieser Teil

des Ausdrucks ist

der Teil, der die Exception hervorgerufen hat.

Und das

wird jetzt halt auch noch jetzt dann

farbig irgendwie anders dargestellt als der Rest der Zeile.

Ja, auch sehr nützlich.

Tatsächlich so ein bisschen readable

und man muss sich

erstmal gucken, wo ist denn jetzt der richtige Teil

vom Traceback, sondern

mit den Positionen, da

habe ich, das Feature habe ich

quasi durch einen geschickten

Tweet provoziert.

Da habe ich nämlich einen Screenshot

gefälscht, wo wir, also den hat

es nie, das Feature hat es bei uns nicht gegeben,

aber ich habe quasi einen fiktiven Traceback

auf Twitter fingiert

und das hat dann dazu geführt, dass

C-Python das wirklich entwickelt hat.

Das fand ich

großartig.

Feature-Request durch

Boßartigkeit.

Also wir können das und ihr?

Und dann gelogen.

Also ich hatte schon so einen Plan, wie ich das irgendwann mal,

wir haben das ja dann auch irgendwann

gekriegt, aber so und T-Python hat uns dann

halt einfach ganz schnell überholt und viel mehr Leute benutzen

T-Python.

Ja.

Genau, hier kann man es auch nochmal sehen.

Jetzt natürlich nicht, wenn ihr zuhört, aber

genau. Ich kann es jetzt sehen.

Das einzige, was zählt.

Ja, ja.

Genau. Ja, auch schön, man kriegt jetzt irgendwie gesagt, wenn man halt ein Modul genauso genannt hat wie eines aus der Standardbibliothek oder von sonstigen Dingen, die man installiert hat, glaube ich, also es gibt so ein bisschen bessere.

Oder wenn man halt irgendwie bei Keyword-Argumenten

das irgendwie falsch übergeben hat,

dann kriegt man jetzt auch, da gab es vorher einfach nur

so sehr, sehr kryptische Fehlermeldungen,

die halt Anfänger auch sehr verunsichert haben.

Das ist jetzt, glaube ich, auch besser.

Er macht das Vorschlag, er versucht sich dran zu erinnern,

was denn der Fehler schon sein könnte

und versucht so einen kleinen Hinweis dazu zu geben.

Ich meine, das wird halt in jeder Version

jetzt gerade so ein bisschen verbessert.

Es ist schon so ein, jetzt über einige Versionen

eigentlich so ein festes Bestandteil

von jedem C-Python-Release,

dass sie halt sich echt Mühe geben,

noch so ein paar der schlechten Fehlermeldungen zu verbessern.

Und ich unterrichte halt Python-Anfänger jedes Semester.

Das macht schon echt einen Unterschied,

ob da dann irgendwie halt Abkürzungen vorkommen,

die wir noch nie gehört haben

oder einfach nur Syntax-Error ohne irgendwas anderes steht

und wir so ein bisschen raten müssen,

was das Problem gewesen sein könnte.

Und ja, und das mit den Vorschlägen,

also wenn man sich halt vertippt,

wenn man irgendwie einen Namen vertippt,

das ist jetzt schon seit ein, zwei Versionen,

dass sie dann da dann Vorschläge

machen könnten, was halt der existierende

Name mit der kleinsten Edit-Distance ist.

Und jetzt

haben sie es eben noch zusätzlich hinzugefügt, dass es auch bei

Keyword-Argumenten geht.

Ah, okay.

Ja.

Also das ist auf jeden Fall vielleicht die

größte User-Facing-Änderung,

die man halt bekommt, wenn man

jetzt Python 3.13 verwendet.

Ja.

Ja, ich würde auch sagen, wenn die ganzen Bibliotheken

umgezogen sind, die man sonst nur nutzt, dann direkt

kann nicht mehr so lange dauern.

Wann zieht ihr denn immer um, bei der 3.1

oder bei der Punkt 1 oder Punkt 2?

Ich stelle eigentlich immer sobald,

ich probiere es vorher schon aus,

also einfach deswegen, um zu sehen, ob ich halt irgendwie

bei den Paketen, die ich

habe

oder die ich maintaine, ob da nicht

dann Dinge kaputt gehen, weil um mir dann halt,

damit ich den Ärger nicht

nach der Release kriege, gucke ich

das halt vor. Also du bist dann einer von denen, die dann die

Bug-Reports machen, wenn was nicht geht.

Ja, aber meistens

ist das halt so abstrakt, dass

ich da gar nicht in Bugs reinlaufe.

Also bisher,

wo ich es probiert habe, hat es eigentlich immer funktioniert.

Und dann

updaten,

das mache ich dann normalerweise, wenn es tatsächlich

dann erscheint. Ja, aber der Rest der Software,

den hast du ja noch nicht

alles umgezogen. Ich habe noch nicht alles

umgezogen. Ich habe auch bei einem Ding hat es nicht

geklappt. Das war irgendwie bei meinem

Fast Deploy Ding, habe ich nicht

updaten können auf 3.13.

weil irgendwas mit PyTest und Async und irgendwelchen Geschichten

nicht mehr ging dann.

Ich weiß es gar nicht mehr so genau.

Da dachte ich, okay, da warte ich jetzt mal noch zwei Monate ab

oder so und probiere es nochmal.

Mal gucken, vielleicht ist es dann gefixt.

Aber genau.

Aber die Dinge, die ich angefasst habe,

seitdem Python 3.13 raus ist, habe ich es umgestellt

und es war bis jetzt auf das eine Ding kein Problem.

Ja, die Datastandsverkehr sind immer so ein bisschen langsam.

Dann haben die immer diese Boundaries in ihren Versionen drin

und das nervt immer so ein bisschen.

Ja, ja, gut, okay. Ich habe jetzt auch gerade nicht so viel

Data Science in der Hand, daher

ist mir das nicht so aufgefallen.

Weil ich auch da das Gefühl habe, dass eigentlich viele Bibliotheken

sich da jetzt inzwischen echt Mühe geben und halt schon

bei den Betas und Release Candidates

halt gucken, ob es geht und dann schon.

Ja. Also es ist jetzt nicht mehr so, dass es ein halbes

Jahr dauert oder so.

Ja.

Ja, ich bin gespannt, wie lange es diesmal dauert. Tatsächlich, ja.

Ja.

Ja.

Wollen wir hier mit den großen Blöcken

weitermachen oder willst du so ein paar der kleinen Sachen sammeln?

Ich weiß nicht, jetzt hatten wir schon einen großen.

Es gibt noch große Blöcke.

Es gibt noch zwei große.

Das war auch schon ein großer, ja.

Ich habe eben noch

die Dokumentation

durchgeschaut und den History-Modus,

den fand ich auch ziemlich gut.

Mit F2 kann man seine History ansehen.

Ist das auch persistent?

Ja, also ich habe eben in meinen

History reingeguckt in meiner Session,

die ich gerade gemacht habe. Das geht sehr weit zurück.

Ich war sehr überrascht, wie viel History da drin ist.

Oh, da muss man jetzt ja auch passen, was man

da noch brennt ohne Klammern.

Ja, das will ich jetzt nicht.

Ohne Anwalt möchte ich diese Frage

nicht beantworten.

Ne,

sehr viele schöne Sachen, aber

ich finde es sehr interessant, dass

3.13 so ein Release ist

mit einer riesigen Änderung

im Frontend, also jetzt diese Rapid-Sachen,

aber ja auch sehr

große Änderungen im Backend,

zu denen wir jetzt kommen.

Du meinst jetzt Nogel?

Ja, es sind tatsächlich

zwei.

Dann machen wir Ditt.

Da habe ich mir Notizen.

Ja, super, okay. Alles klar.

Also beides sind ja eigentlich Sachen,

die eher so im...

Vielleicht nochmal für alle Leute, die einsteigen, die noch gar

keine Ahnung von Weißwein haben, Ditt just in time.

Was ist denn das

und warum ist das interessant und warum ist das wichtig?

Vielleicht nochmal so einen kurzen Aufzug

lang und dann...

Ja.

Also C-Python ist ein Interpreter, also der Python-Code, der ausgeführt wird, der wird erst nach Bytecode übersetzt und der Bytecode wird aber dann von einem in C geschriebenen Interpreter ausgeführt und das gilt als nicht so schnell.

Das ist einer der Gründe, warum Python den Ruf hat, nicht so super schnell zu sein. Und seit ein paar Versionen gibt es da einiges an Arbeiten vom Faster Python Team, was zum guten Teil von Microsoft bezahlt wird, das zu verbessern.

Und was die machen ist, immer noch auf dem Interpreter, aber sie verändern quasi die Bytecodes zur Laufzeit in Abhängigkeit von den Typen, die in den Funktionen verwendet werden, was dazu führt, dass wenn ich halt an irgendeiner Stelle vor allem Integers benutze, dass dann für Integers angepasster Bytecode verwendet wird, was die Ausführung schneller macht.

Und das, also dieser Prozess, der hat in 3.11 angefangen und in jeder Version gibt es da eben so ein paar Verbesserungen. Und wenn man dann aber darüber noch hinaus will, dann muss man eben, oder was man dann eben machen kann, ist nochmal zu einer anderen Technik greifen, das ist der sogenannte Just-in-Time-Compiler und das ist eine Technik, die von allen schnellen JavaScript-Implementierungen oder auch von Java verwendet wird.

Und da ist die Idee, dass man zur Laufzeit eben Maschinencode erzeugt für die Funktionen, die man gerade ausführen möchte und das hat den Vorteil, dass man, also der Grund, warum man das zur Laufzeit macht, ist, weil man erst zur Laufzeit die Typen weiß, die in der Python-Funktion gerade verwendet werden und dann kann man eben Code erzeugen, der dann speziell angepasst ist auf die Arten und Weisen, wie die Funktionen, die man gerade ausführt, eben verwendet werden.

Aber das kann ja auch sehr dynamisch sein,

aber man muss dann wahrscheinlich ein paar Mal die so ausführen

und dann gucken, was passiert und dann...

Genau, also das ist der grundsätzliche Ansatz.

Man fängt eben an, das erstmal so mit dem Interpreter auszuführen

und dabei macht man so ein bisschen Beobachtung,

was für Typen eben konkret verwendet werden,

führt so ein paar Statistiken mit

und nur wenn die Funktion besonders oft ausgeführt wird

und man dann eben mit der Zeit eben so ein paar Informationen zusammen hat,

wie die Typen so sind,

dann fängt es sich an, quasi das so ein bisschen zu stabilisieren

und das ist auch dann der Zeitpunkt,

eben dann die Bytecodes umgeschrieben werden, quasi

jetzt seit Version 3.11

und jetzt, was

jetzt neu ist in 3.13

ist, dass dann eben dieser zweite Schritt hinzukommt,

wo man dann eben nicht nur

Bytecodes umschreibt und

für die Situation effizientere

Bytecodes, sondern eben auch noch

und das ist komplett optional, also bisher

in den Standard-Builds ist das Feature nicht drin,

das ist eher so ein

Feature-Outlook

für zukünftige Versionen,

dass man eben CPython auch neu bauen kann

mit so einem speziellen, experimentellen Build-Time-Flag,

was eben sagt, ich möchte jetzt gerne einen JIT-Compiler einbauen.

Und dann wird eben zur Laufzeit

dieser spezialisierte Bytecode genommen

und daraus Maschinencode erzeugt.

Und die Hoffnung ist, dass es dann eben noch schneller wird.

In 3.13 ist es aber leider noch nicht der Fall.

Also sie erzeugen quasi Maschinencode.

Aber der, ja, also der macht es halt nicht,

das macht es doch ziemlich schneller.

das ist so ein bisschen die schlechte Nachricht, aber

das ist trotzdem okay,

weil das Ziel ist quasi so,

das Fundament zu legen

für Verbesserungen, die dann in der nächsten Version

hoffentlich auch wirklich dazu führen, dass halt

dann C-Python das Sachen schneller ausführen kann.

Ja.

Und

das ist, glaube ich, eine spezielle Art

von

Just-in-Time-Compiler oder so, die es auch noch

gar nicht so lange gibt. Das geht irgendwie zurück auf

so ein Paper für

Lua irgendwie, für so Copy-on-Patch

Ich weiß nicht.

Also so ganz kann man das nicht sagen.

Die Idee gibt es schon sehr lang.

Das ist ein sogenannter Template JIT.

Und da ist die Idee, dass man,

also man hat ja dann diese spezialisierten Bytecodes,

also sowas wie Add to Integers oder sowas.

Und die Idee ist, dass man quasi für alle diese Bytecodes

so ein bisschen Maschinencode vorbereitet,

also zu dem Zeitpunkt, wo man CPython baut.

Und das dann, den vorbereiteten Maschinencode, also diese Templates, die werden dann so zusammen kopiert. Und die Idee von einem Template-Jit, die ist relativ alt. Aber was jetzt neu ist, und das ist eben dieser Copy-and-Patch-Ansatz, ist die Art und Weise, wie diese Templates hergestellt werden.

Und das ist eben die Einsicht von dem Copy-and-Patch-Ansatz. Das ist ein Doktorand in Kalifornien, glaube ich, Haorang Su. Und die Idee davon ist, dass man eben den C-Compiler benutzen kann, um diese Templates vorzubereiten. Das hat viele Vorteile.

Also man benutzt den C-Compiler, man hat so kleine Funktionen in C geschrieben, benutzt den C-Compiler, um die dann nach Maschinencode zu übersetzen und das bedeutet insbesondere, dass normalerweise, wenn man JIT schreibt, dann muss man halt anfangen für verschiedene Maschinenarchitekturen so ein Backend quasi von Null auf erstmal zu bauen und das ist halt super aufwendig, gerade wenn man viele Architekturen unterstützen will, wie das ja bei C-Python der Fall ist.

Und die Idee von dem Copy-and-Patch-Ansatz ist, man benutzt den C-Compiler, um sich den Maschinencode erzeugen zu lassen und kopiert den dann so mit Memcpy quasi an die richtige Stelle und patcht dann eben noch so ein paar Stellen, wo man dann irgendwelche Konstanten noch so in den erzeugten Maschinencode so reinpatchen kann.

Und dazu benutzt man linke Informationen. Das ist wirklich so ein relativ kreativer Ansatz, um halt mit vergleichsweise wenig Aufwand, also ohne so ein komplettes Backend schreiben zu müssen, trotzdem relativ schnell einen relativ guten Maschinencode erzeugen zu können.

Ja, ich glaube, das ist irgendwie LLVM oder so wird da benutzt.

Genau, das ist auch so ein bisschen das Problem. Also man braucht dann genau die richtige LVM-Version. Und wenn man die nicht installiert hat, dann bringt einem auch die Flag nicht. Man kann es dann trotzdem nicht bauen. Ich habe es tatsächlich noch nicht geschafft, das zu bauen, weil ich irgendwie das richtige LVM noch nicht hatte oder was. Aber ich glaube, die arbeiten da jetzt, also ich glaube, auf dem CPython-Main-Branch ist das jetzt auch irgendwie gelöst. Da werden halt dann Sachen schon eingecheckt oder, also man muss dann nicht mehr genau die richtige Point-Version von LVM installieren. Aber habe ich jetzt noch nicht ausprobiert.

Hat LLVM nicht auch so eine IR, eine Intermediate Representation, die auch irgendwie so abstrahiert ist?

Ja, also im Prinzip haben das die meisten optimierenden Compiler, die haben halt irgendwie so eine Zwischendarstellung, wo sie halt quasi diese benutzen, um Code zu optimieren.

Und bei LLVM ist die deswegen relativ sichtbar, weil sie halt gute Tools haben, um die dann in so eine ASCII-Syntax zu printen und auch wieder zu parsen und weiter zu verarbeiten.

Aber, ja.

Auch viele technische Bauteile

immer noch, ja klar.

Ja, es ist schon, also es ist jetzt schon

so ein bisschen, der JIT in 3.13,

das ist schon wirklich eher so,

das sind so vorbereitende

Arbeiten. Also die Hoffnung ist eben, dass das

dann so in den nächsten

Versionen,

also ich meine, bisher ist das relativ unbefriedigend.

Wir haben einen JIT, der erzeugt ganz tollen Maschinencode,

aber es wird halt nicht schneller.

Also,

Und es ist, ja, cool, aber halt irgendwie auch nutzlos.

Also warum sollte man es machen,

wenn sich die Performance halt dadurch gar nicht ändert?

Aber die Hoffnung ist eben,

dass sie dann, wenn sie jetzt weitere Optimierungen einbauen

und bei diesem Patching,

da kann man noch so ein paar extra Instruktionen dann wegoptimieren.

Das haben sie, glaube ich, jetzt oft im Main Repository auch schon gemacht.

Und die Hoffnung ist, dass dann eben, wenn 3.14 dann da ist,

erstens eben dann, dass sie so ein paar Bugs

gefixt haben, weil hoffentlich eben ein paar Leute

trotzdem den

experimentellen JIT halt mal ausprobieren

und dann vielleicht Bug-Reports schicken

und dass sie dann halt

in der nächsten Version dann auch die Performance

noch ein bisschen verbessern können.

Und insgesamt finde ich den Ansatz halt

cool, weil er in Anbetracht der Tatsache,

dass das C-Python-Team halt jetzt nicht so groß

ist, was bezahlte Entwickler angeht,

ich finde es halt einen relativ pragmatischen

Ansatz, wo sie ohne jetzt irgendwie

also was ich

Google vor acht hat, hat irgendwie

weiß nicht, 80 Leute oder so.

Das fand ich auch überraschend, ja.

Und

also das hier hat quasi mit der kleinen

Anzahl an Festangestellten halt

trotzdem

mit diesem Ansatz vielleicht irgendwie recht

pragmatisch irgendwo hinkommen können.

Ja, ich meine. Ja, ich finde das auch cool. Ich finde das

auch generell cool, ohne dass es jetzt

direkt eine Geschwindigkeitsverbesserung

bringt, einfach weil, wie du

gesagt hast, das ist eine wichtige

Grundlage, um dann irgendwann die Verbesserungen

rausholen zu können. Deshalb.

Richtige Richtung, meiner Meinung nach.

Ja, ich meine, wenn man jetzt nicht so viel Ressourcen hat,

muss man sich halt überlegen, wie man die ökonomisch einsetzt.

Und wenn man jetzt sieht, was

vielleicht V8 irgendwie macht

oder so und das dann halt einfach später,

wenn sich herausgestellt hat, was da gut funktioniert, halt

dann die wesentlichen Teile nimmt

oder so, das wäre schon... Wobei, ich weiß nicht

genau, gibt es irgendwo

quasi den gleichen Ansatz, der dann schon gut funktioniert?

Weil V8 ist ja dann wahrscheinlich doch

eher noch deutlich komplizierter oder so.

Sehr viel komplizierter. Also V8 hat halt nicht nur

einen JIT, sondern irgendwie drei oder so.

Oder vier.

Also halt dann erstmal einen, der quasi

schlechten Code sehr schnell erzeugt und dann

etwas besser optimiert, sehr gut optimiert.

Dann haben sie noch einen komplett getrennten JIT für

WebAssembly.

Also das ist schon

und dann natürlich auch wirklich dann

quasi richtige Backends für ganz viele verschiedene

Hardware-Architekturen.

Also das ist schon ein Aufwand, den

meiner Ansicht nach mit dem jetzigen

Funding das C-Python-Thema erstmal so nicht

hinkriegen kann.

Transpilen nach,

einfach Python transpilen nach

JavaScript.

Ja, oder nach

WebAssembly.

Das stimmt, das ist ja tatsächlich eine unterstützte

Plattform, ja.

Genau, das ist jetzt eine Tier-2-Plattform.

Ja, genau, das stimmt.

Also das ist

so ein kleines Ding, es gibt drei neue Plattformen

in 3.30. Ja, super spannend.

Soll ich mal,

ich lese mal hier vor, also

die erste, die

Tier 2 Plattform heißt

WASM32 WASI, also eine

WebAssembly Plattform.

CF, weißt du, was

Tier 2, weißt du, was die Tiere bedeuten?

Ich glaube irgendwie,

die machen Aussagen darüber, wie viel

Bildbots sie haben und was sie so versprechen

an

Support über die, genau, über die

Version. Da gibt es irgendwie ein Papp dazu.

Ja, okay, gut. Also das kann man

nachlesen. Aber ist jetzt eine höhere

Zahl besser oder eine kleinere?

Also eins ist am besten.

Die niedrigeren Zahlen sind besser, oder? Je näher du

am Ziel bist, an der

Spitze, umso besser ist es. Also

WebAssembly ist jetzt Tier 2

Supported Plattform mit vielen Buildbots und viel

Stabilität in der Version. Und es gibt zwei

neue Plattformen,

die, da war ich sehr überrascht,

die es gibt, nämlich Android und iOS

sind Tier 3

Officially Supported Plattform.

War ja früher ein riesen

Thema, wenn man Android, wenn man

Python auf Android ausführen wollte oder noch schlimmer

Python auf iOS.

Das ging auch schon sehr lange.

Das ging auch schon sehr lange. Ich meine, es ist ja

auch kein Problem, du kannst ja einfach

den Interpreter auch total kopilieren

und so. Und da ging auch

NumPy und so, das ging alles. Und es gab

da so eine schöne App namens

Pythonista.

Aber die hat

natürlich eigentlich schon gegen die App-Store-Regeln

verstoßen.

Also ich meine,

mein

Beowulf-Cluster aus iOS,

aus iPhones.

Was ist genau die Regel?

Also die App-Store-Regel ist,

du darfst da nur

Dinge installieren. Also

kompilierter Code, ja, aber auch irgendwie

C++, C, irgendwie

Objective-C,

und

was war es noch?

Ich weiß nicht, vielleicht

ist gerade eine Handvoll Sprachen.

Aber viel wichtiger ist doch die Regel, dass du keinen

dynamisch erzeugten Code nachladen musst.

Ja, das genau, ja.

Weil dann kann Apple ja nicht mehr prüfen,

ob du nicht irgendwelche schlimmen

Programme nachlädst.

Ihre Sandbox-Tests oder was auch immer die da noch mal machen.

Ja, ist auch ein

Und du konntest halt mit Python,

da kannst du halt auch einfach quasi Python-Code

auf deinem Telefon ausführen und

das geht natürlich eigentlich nicht.

Ja, ist klar.

Aber es ging dann doch. Ja, aber bei Android

wäre das ja prinzipiell gegangen.

Nur war halt das Tooling bisher immer

sehr umständlich. Also ich weiß,

dass es Beware gibt und es gab auch

Kiwi und viele andere

Ansätze schon, aber die waren schon

immer sehr umständlich.

Und wenn es jetzt...

Genau, das ist schon noch wichtig, dass es

dass es jetzt halt quasi von den

C-Python-Entwicklern halt mit

versorgt wird. Ich habe jetzt nochmal nachgeschaut, was genau

die Tires bedeuten. Also Tire 1

ist halt das richtig gute Zeug, also so

macOS, Windows,

Linux.

Tire 2 braucht man halt irgendwie

Buildbots und mindestens zwei

C-Python-Core-Developer, die

eben die Plattform unterstützen

und wenn es da

Buildbot-Failures gibt, dann

werden C-Python-Releases dadurch

blockiert. Und Tire 3

heißt eben

BuildBot einen Core-Entwickler,

aber wenn es da

Bugs gibt, dann kann man trotzdem,

also dann kann C-Python trotzdem released werden.

Also es ist quasi so,

wir geben uns Mühe, aber

wenn jetzt irgendwie

es nur noch irgendwie einen bekannten Bug auf Android

gibt, dann releasen wir halt möglicherweise trotzdem.

Und der

Core-Developer, der für Android und

iOS zuständig ist, ist übrigens Russell

Keith-McNeil, der der

auch Beware schon gemacht hat, der das schon lange

gemacht,

hat es jetzt offenbar eben reingekriegt.

Der diesen tollen Vortrag

gehalten hat, irgendwie

Black Swan Events für

ich weiß gar nicht, wie der Titel von dem Vortrag hat,

da ging es halt genau darum, was es könnte,

was eigentlich sind die bedrohlichsten Geschichten, die

jetzt Python noch zustoßen können

und ein Szenario war halt

so, ja, was ist, wenn

irgendwie künftige Generationen gar nicht

mehr vor so riesigen Desktop-Dingern

sitzen oder so, ich kann das

gar nicht verstehen, ich finde das total toll, aber

eher vielleicht auf Tablets oder Telefone gucken

und dann einfach ein Vergessenheit gerät, dass

es Python überhaupt noch gibt, weil Python gibt es halt

nicht auf iOS oder so.

Und dagegen sollte man vielleicht

was tun. Und dann, ja, jetzt ist halt was

passiert und das sieht ja schon ganz gut aus.

Ja, ich habe das bei meinen Studenten. Man muss nach Studenten echt.

Also ich habe halt, also ich mache

eine Python-Einführung für alle, also

da dürfen Informatiker nicht hin.

Und das heißt, ich habe auch Studierende

aus allen Fächern und

jetzt nicht viele,

aber da gibt es halt dann immer wieder Teilnehmende,

die dann halt einfach auch nur ein Tablet

haben. Tier 1?

Ja, also da sind wir noch nicht.

Wir haben kein Tier 1 Gerät, genau.

Und Jupiter Notebook

haben wir. Wir haben dann halt entweder die Möglichkeit,

das irgendwie über Google Call-Up zu machen,

also ich mache alles mit Jupiter Notebooks, aber das ist halt dann immer

so ein bisschen nervig mit die Input-Dateien

hochladen und so Zeug.

Und dann können die sich ins Rechenzentrum setzen,

da hast du es auch installiert, aber das ist natürlich auch total nervig,

du musst immer deine Übungsaufgaben da machen.

Und so einen richtig,

also richtig guten Jupiter Support

auf so einem

iPad gibt es halt einfach auch noch nicht.

Das ist schon einfach

im Vergleich zu installiert

an der Conda, dann ist alles in Ordnung, ist es halt schon einfach

sehr frickelig.

Ich muss

noch dazu sagen, nicht, dass wir jetzt hier Personen

übergehen, es gibt noch zweite

Maintainer für diese Plattform, neben Russell

Keith-McGee. Für Android

gibt es noch den Peter Victorin

oder Peter Victorin

oder wie auch immer man das aussprechen mag.

Einer von den drei,

mir verzeihen, die Wille auf Besuch.

Es gibt es noch den

NetDaily. Also wieder so eine tolle Name-Calling

gemacht, da muss ich ja nochmal kurz zum Sammelkartenspiel

zurückkommen, was er sich kurz angekündigt hat.

Weil ich ja auf

dem Talk von

Lukas Langa, der ja

in diesem tollen Rappel irgendwie dann ein

kurzes Befehlchen eingeben konnte,

um das Bild von, ich dachte,

es wäre John Romero gewesen, was

eigentlich Pablo Cardenas Agato war.

Und dann hatten wir kurz dieses Thema

und ich finde das eigentlich eine coole Idee, dass man demnächst

auf den Pycons so

Sammelkartenspiele. Wir bringen die erste

Edition mit, dann machen wir den Python-Podcast

das dann Team an.

Ich finde, die

sollten das selbst verteilen und

nur die Leute, die bei den Vorträgen waren,

kriegen auch so eine Karte. Also ich glaube,

man kann die verkaufen. Also ich vermute,

dass das wirklich die Art und Weise ist, wie man

endlich mal gutes Funding für 10 Seiten findet.

Ja, dann liebe

Zuhörer, schreibt uns, ob das die Wahrheit ist

und dann müssen wir das wohl machen. Damals als

NFTs. Irgendwann gab es ja auch so Sachen, die dann diese

Bilder dann gemacht haben und das dann als NFT.

Ja, aber das mit den NFTs

ist immer noch die Zukunft.

Ich weiß nicht.

Der einzige Vorteil von AI ist, dass die die NFTs

verdrängt haben.

Für einen ganz

kurzen Moment waren Grafikkarten wieder billig

und dann hat die AI

zugeschlagen.

Tja.

Okay, also es gibt zwei neue

Plattformen, Android und iOS und

das ist eine großartige Sache, finde ich.

Und WebAssembly.

Und WebAssembly, ja genau, WebAssembly ist quasi

aufgestiegen von M-Skripten

zu WASI.

Wir müssen noch

über den anderen JIT reden.

Es gibt nämlich

zwei JITs in 3.13 und der eine ist

der coole, der quasi das irgendwann mal schneller machen soll,

der aber quasi standardmäßig gar nicht

eingebaut ist und dann gibt es aber den

anderen, der quasi standardmäßig eingebaut ist,

aber für einen ganz anderen Zweck und

ich glaube in einer der

Core.py folgen, ist Pablo Galeno

Sagado, über den wir gerade auch schon geredet haben, sehr stolz

drauf, dass er quasi den ersten

C-Python-Jit gemerged hat und geschrieben hat.

Und das ist nämlich der Jit, der benutzt wird, um

besseres

Profiling machen zu können.

Und

das funktioniert mit dem Linux Perf

Profiler. Und das Problem,

wenn man jetzt so ein, also der Perf Profiler

ist eigentlich so ein Profiler für

C. Also man kann halt sehen, was macht

der Kernel, was macht der Linux Kernel oder was machen eben auch

die C-Programme, die im User-Space laufen

und man kann eben sehen, die und die

C-Funktionen werden jetzt gerade so und so oft

ausgeführt. Das ist so ein Sampling-Profiler, also

der Profiling-Aufhalt ist sehr gering.

Das Problem ist jetzt aber, dass wenn man

quasi Python-Programme profilt,

dann sieht man natürlich jetzt gar nicht, welche

Python-Funktionen wie viel Zeit verbrauchen, sondern

man sieht dann die ganze Zeit

nur, dass halt irgendwelche Interpreter-Funktionen

ausgeführt werden. Und da

gibt es jetzt eben dieses neue Feature, den

PerfJit. Und da ist die Idee,

dass man so eine ganz, ganz kleine, irgendwie ein paar

wenige Maschinencode-Instruktionen

lange Funktionen generiert

zur Laufzeit

und für jede Python-Funktion eben genau

eine so eine Funktion. Und das hat

den Vorteil, dass Perf eben die ganzen Python-Funktionen

voneinander unterscheiden kann. Wenn man eben

nicht nur eine interpretierige

Python-Code-Funktion

dann sieht in Perf,

sondern man sieht dann eben diese neu generierten

Mini-Funktionen. Und dann

gibt es irgendwie so einen Rückübersetzungsschritt,

wo man dann eben sagen kann, okay,

diese neue, neu generierte Assembly-Funktion

an Adresse sowieso, die entspricht

eben der Python-Funktion

f, wie auch immer.

Und so kann man dann eben mit

Perf sehen, in welcher Python-Funktion man

lange Zeit verbraucht hat.

Das hört sich nach einem

sehr umständlichen Weg an.

Es ist erstaunlich umständlich, aber Profiling

ist auch echt einfach ultra kompliziert.

Ja, gut, klar.

Also es gibt

ja irgendwie so

irgendwie eine große Sammlung

an Profilern für Python und für andere Sprachen, aber

C-Profile hat halt einfach

einen riesen Overhead. Dann gibt es verschiedene

Sampling-Profiler für Python. Wie heißt dieser?

PySpy oder so? Der funktioniert, glaube ich,

ziemlich gut. Habt ihr den mal benutzt?

Nee, ich weiß

gar nicht. Ich hab wieder vergessen, was ich

hab mal irgendwas benutzt.

Gibt es einen, der Hotspot heißt?

Aber Hotspot ist, glaube ich, eine UI nur, oder?

Wo da die Samples herkommen, weiß ich nicht so genau.

Ja, und dann gibt es also

unseren quasi, WMProf, der ist aber nicht mehr so richtig

maintained. Also auf Piper schon, aber

C-Python nicht so richtig. Ist auch Sampling.

Also Sampling heißt halt, dass man quasi

nicht jeden Funktionsaufruf mitschreibt, was halt

sehr, sehr hohen Overhead hat, sondern

einfach nur so tausendmal pro Sekunde halt guckt,

welche Funktionen gerade auf dem Stack sind.

Und dann sagt, so statistisch gesehen,

sind das die Funktionen halt, die dann viel Zeit brauchen.

Und

Perf ist halt auch so einer. Und der Vorteil von diesem

Sampling-Ansatz ist, dass man den Profiling-Overhead

eben beliebig klein machen kann.

Man kann halt die Anzahl der Samples immer kleiner machen.

Und wenn es dann nur noch 10 Samples sind, dann ist es halt quasi genauso schnell, wie es vorher auch war. Man hat aber auch schlechtere Informationen dann sozusagen. Also man kann dann quasi die Abwägung zwischen Genauigkeit der Informationen, die man hat und Overhead beliebig ausbalancieren.

Und Perf funktioniert halt sehr gut, wenn man da gute Informationen darüber kriegt, was auf dem C-Level funktioniert. Aber die Informationen, welche Python-Funktion da jetzt gerade involviert ist, die geht halt verloren. Und die kann man dann eben wieder zurückkriegen mit diesem neuen Perf-Integration-Feature, das jetzt in 3.13 released wurde. Aber ist auf jeden Fall frickelig.

Also ich glaube auf Mac ist es ja auch total schwierig, weil man braucht halt so ausführbare Blöcke von Maschinencode und Apple hat da halt auch einiges an Security Features. Man muss dann quasi sicherstellen, dass man so einen Codeblock eben so hin und her wechselt zwischen ich kann den Codeblock schreiben und ich kann ihn ausführen.

Also man kann nie gleichzeitig schreibbar und ausführbar haben, um eben so Security-Exploits unwahrscheinlicher zu machen. Und bis man das ganz genau richtig hingekriegt hat, das ist tricky. Wobei Perf ist eigentlich nur ein Linux-Projekt. Insofern habe ich, glaube ich, gerade Quatsch gesagt.

Ach so, das gehört. Ja, ich will

mit MacOS, ich glaube, im letzten

Copy-by-Episode war auch irgendwie

drin, dass der

Memory-Profiler, Memory, den Pablo

gerade geschrieben hat, der

hat auf MacOS nicht funktioniert,

weil

irgendwie sie

die malloc-Funktion irgendwie, also

nicht die...

Von einer

Mac-Version zur nächsten.

Kann man auch schon mal machen.

Warum nicht?

Ja, ich finde es cool, dass es Leute gibt, die sich dann

wirklich mit den Linkern auf allen Plattformen rumschlagen,

um dieses Problem zu lösen.

Ja.

Ja, ja, Profiling, tja.

Das ist... Wenn das so low-level ist,

sinkt dann eigentlich der Tier, ist dann Tier 0, oder?

Sorry.

Couldn't resist.

Es ist interessant.

Aber was ist denn das nächste

Thema auf unserer Liste?

Ja, na gut.

Dann, was jetzt auch drin ist,

das wurde auch viel diskutiert,

ist halt, ja, es nennt sich jetzt

Free Threading früher, No-Gill irgendwie,

dass man halt

optional den Gill

ausschalten kann, ist auch eine,

muss man Compiler-Flex setzen und dann

neu kompilieren oder halt sich ein entsprechendes

Binary halt via was auch immer, wie man

halt so Python installiert, halt

das damit installieren und dann

kann man das benutzen.

Tja, also... Was macht das denn überhaupt,

der Gill?

Oh!

Ja, es sorgt eigentlich im Grunde dafür, dass halt der, dass immer nur, dass Python immer nur auf einer CPU läuft, wenn ich das jetzt mal ganz.

Aber das ist ja noch eine Auswirkung, das ist ja nicht das, was dem macht.

Ne, ich glaube, das ist tatsächlich das, was.

Und es stimmt auch nicht, er kann auf vielen CPUs laufen, nur halt immer nur auf einer gleichzeitig.

Ja, immer nur auf einer gleichzeitig, genau, das meinte ich.

Aber das ist ja nur eine Auswirkung, das ist ja nicht der Grund,

warum man das macht. Der Grund, warum man das macht, ist, dass

viele Operationen,

gerade was Memory Management angeht,

man dadurch

halt nicht, da muss man halt nicht locken,

was man ansonsten halt müsste, weil

wenn man den Reference Counter von irgendeiner

Datenstruktur erhöht, oder

Also ganz allgemein, die ganzen

Datenstrukturen sind halt erstmal nicht

Threadsafe.

Und das bedeutet, dass wenn man

die von mehreren Threads aus benutzt,

wird alles kaputt, dass die dann kaputt gehen können.

Um das zu verhindern, müsste man halt locken

und wenn man lockt, dann wird alles so langsam,

dass man keinen Vorteil

mehr davon hat, dass man mehr

CPUs hat. Also ich glaube,

die ersten Versuche, das war

das Projekt hieß irgendwie

Gilectomy oder so.

Es gibt noch ein älteres.

Also so alle paar Jahre kommt mal jemand

und schaut ein Versuch aus.

Doch, bei 1.1 wieder nicht genau aufgepasst.

Ja, genau. Also es war wirklich so

1.6 oder irgendwie so was ganz frühes, wo das dann

kann gut sein, aber da war das

auch, also an den Versuch erinnere ich mich noch

und da war es halt so, dass wenn man das einfach nur

versucht hat zu locken und auch nicht

irgendwie was kompliziertes gemacht hat, sondern

einfach mal probiert hat, es nicht ganz so langsam hinzukriegen,

dann war irgendwie

Performance war so Faktor 40

weniger und

ja, dann hat man es auch

Single Performance, genau.

Und dann hat man es runtergekriegt mit Tricks auf

20, Faktor 20

irgendwie schlechter, aber das ist halt immer weit

entfernt von. Irgendwie

man will das verwenden, weil wenn das

so eine Auswirkung hat, dann lohnt sich

das eher nicht. Aber was macht man denn dann mit den ganzen

Objekten, die da irgendwo rumliegen? Wie holt man die denn dann weg?

Wie meinst du?

Wenn man nicht mehr braucht.

Du meinst Garbage Collector?

Ja. Gut, das ist nochmal ein anderes...

Der weiß ich gar nicht, ob der irgendwie...

Aber der Reference Count ist ja dafür da, oder?

Dass man das wieder wegräumen kann, wenn es auf null fällt.

Also an dem Garbage Collector hatten die quasi bei diesen

Gilectomy und so Versuchen auch nichts geändert.

was sie gemacht haben, ist jedem Objekt einen Log zu geben

und immer wenn ein Threat mit dem

Objekt eben interagieren will, insbesondere

wenn eben der Reference Count

verändert wird, musst du halt dir erstmal

das Log holen für das Objekt.

Und weil halt

ständig, um irgendeine Operation mit

dem Objekt machen zu können, du halt ständig an dem Reference Count

rumoperierst,

ja, musst du halt ständig auf das Log

warten und das hat halt

die bisherigen Versuche, den

Guild zu entfernen, einfach sehr, sehr teuer gemacht.

Also die Single-Thread-Performance eben komplett ruiniert.

Und jetzt kann es doch dann eigentlich sein,

dass so ein Objekt dann einfach weggeräumt wird,

obwohl es noch gebraucht wird?

Jetzt wird es super kompliziert.

Also wir haben jetzt, genau, es gibt ein Guild,

der verhindert, dass mehr als ein Thread Python-Core ausführen kann.

Also gleichzeitig auf einem Core.

Jetzt kommt eben der nächste Versuch

Und das ist von Sam Gross bei Meta über viele Jahre lang eben probiert worden und der hat einige sehr clevere neue Ideen da reingebracht, um zu versuchen eben die Verlangsamung für Single-Thread-Performance, soweit es geht, zu minimieren.

Und da gibt es eben so eine ganze Bandbreite an Optimierungen, womit er dann eben versucht, genau diese Probleme in den Griff zu kriegen. Und eine davon ist eben die Beobachtung, dass die allermeisten Objekte, die werden halt trotzdem nur von einem Thread benutzt.

Also wenn ich halt eine Funktion habe, die

irgendwie eine Liste erstellt und da was rein

appendet und so weiter, selbst wenn

auf ganz vielen anderen Threads halt noch Sachen laufen,

kommt halt kein anderer Thread

erstmal standardmäßig an diese Liste ran.

Das heißt, die erste Optimierung ist zu sagen,

für die ganzen lokalen

Objekte, die ich also nur von einem Thread

überhaupt jemals anfasse,

muss ich für das

Updaten der Reference Counts eben nicht locken.

Also das ist quasi

so die wichtigste Optimierung.

Genau, das heißt

Biased Reference Counting, weil quasi

dafür gesorgt wird, dass man eben

nicht gesharete Objekte,

die nur von einem Thread

eben erreichbar sind,

dass man da eben das Locking quasi

sein lassen kann.

Jetzt gibt es aber natürlich

eine ganze andere Klasse an Objekten,

die werden halt von ganz vielen

verschiedenen Threads angefasst, also halt

alles, was die ganzen Build-ins, also

None,

die ganzen Typen und dafür gibt es

dann also wieder einen ganz anderen Ansatz. Und da ist nämlich

die Idee, dass man da halt sagt,

diese Objekte, die können eh nicht sterben.

Also sowas wie NAN.

Warum nicht wegräumen? NAN gibt es halt einfach

immer und das gilt

halt für ganz, ganz viele andere Arten von

Objekten auch. Die meisten Typen gibt es halt immer

und die werden dann so

unsterblich gemacht.

Ist das dann ein Singleton?

Also NAN ist auch ein Singleton,

ja, aber das ist nicht das einzige

Kriterium. Man kann sich schon noch vorstellen, dass es Singletons gibt,

die halt vielleicht auch sterben könnten.

aber, also die man vielleicht wegräumen will, aber

es gibt

also die ganzen eingebauten Sachen, die

werden einfach nie, also die

werden halt nie garbage collected und deswegen kann man

da eben auch sagen, da kriegt jetzt der Reference Count

irgendwie so einen speziellen Flag und

dann erhöht und senkt

man den Reference Count eben auch nicht.

Und das, dann muss man die auch wieder nicht

locken, also.

Und dann gibt es noch den dritten Ansatz

und das ist das sogenannte Deferred Reference Counting

und da verstehe ich die ganzen Details auch nicht komplett,

aber da ist eben die Idee, dass man

eben das Erhöhen und

Senken des Reference-Counts nicht mehr

die ganze Zeit up-to-date macht,

um

eben zu, also da geht es um

Objekte, die so dazwischen sind, also die von einem

mehr als einem Thread erreicht werden können.

Also man erhöht, aber man

reduziert das nicht oder beides nicht?

Ich glaube beides

nicht, also und dann

das sorgt aber dafür, dass wenn der Reference-Count null wird,

dann kann man die auch nicht sofort einsammeln, sondern

da muss man eben warten und dann

warten, bis alle Threads zu irgendeinem

wohldefinierten Punkt kommen und dann kann man schauen,

ob es nicht noch irgendwelche References

in den Stackframes gibt oder so,

die dann noch dazugezählt werden müssen.

Deswegen eben Deferred. Und nur

wenn man da dann eben überall nachgeschaut hat und

feststellt, oh okay, das Objekt, das ist

jetzt wirklich auch von keinem Frame-Objekt mehr

erreichbar, dann kann ich das wirklich wegräumen.

Und das hat auch komplizierte

Interaktionen mit dem

Memory Allocator,

Da wechselt nämlich die Free-Threading-Version

auch zu Mimalog.

Das ist so ein von Microsoft geschriebener C-Memory-Allocator,

der eben auch besonders gut mit Multi-Threading interagiert.

Und da wird auf eine für mich noch nicht ganz verständliche Art und Weise

eben mit besonderen Mimalog-Features dann erreicht,

dass genau das Richtige passiert.

Dass genau das Richtige passiert, das ist immer toll.

Ja, das ist auch ...

Ja, aber das hört sich jetzt so ein bisschen an wie so Eventual Consistency für den Reference-Counter.

Ja, ich glaube, das ist genau.

Weil im Endeffekt ist die Zahl, die in dem Reference-Counter drinsteht, ja auch nur dann wichtig, wenn es eine Null ist.

Also Vorbemerkung ist, das gilt alles nur für Objekte, die eben von mehr als einem Thread erreicht werden können.

Ja, okay, klar.

Genau, aber für die hast du absolut recht, da ist eben da eine Zahl drin, die nicht unbedingt wirklich alle References von allen Threads dann widerspiegelt.

Und um das Objekt dann wirklich wegräumen zu können, muss man halt nochmal nachschauen, ob das wirklich alles so gestimmt hat.

Genau, aber für mich der Knackpunkt an dem, dass das überhaupt funktionieren kann, ist, dass die Zahl, die tatsächlich in dem Reference Count drinsteht, die meiste Zeit ja uninteressant ist.

Solange die Zahl größer als 0 ist, ist der exakte Wert nicht wichtig, sondern es wird erst dann wichtig, wenn der exakte Wert 0 erreicht.

Also so ein bisschen so, als wenn du die Box aufmachst und guckst, ob die Katze noch lebt.

Ja, aber du musst sie ja nur aufmachen, wenn du es wirklich wissen willst.

Solange es dich nicht interessiert, ob die Katze noch lebt, kannst du außen den Schalter drücken oder nicht drücken, so viel du willst.

Und ich glaube, das ist für mich in meinem Kopf so ein bisschen der Kern an der Sache, warum das überhaupt funktionieren kann.

Weil wir nur zu sehr wenigen Zeitpunkten wirklich den exakten Wert wissen müssen, weil wir nur zu wenigen Zeitpunkten wirklich draufschauen müssen und sagen müssen, okay, jetzt muss ich wissen, ob die Zahl wirklich null ist oder nicht.

Ich glaube, Eventual Consistency ist auf jeden Fall ein super Gedankenmodell, weil, also Eventual Consistency wird ja auch quasi aus den gleichen Gründen eingeführt. Also natürlich kann ich, will ich, eigentlich ist es besser, wenn meine Information halt die ganze Zeit konsistent ist.

Aber das hat halt im Datenbankbereich

dann auch entsprechende Nachteile, Performance-Nachteile.

Ja, und gerade in verteilten

Datenbanken. Genau.

Und quasi aus den gleichen

Gründen führe ich halt quasi

im Field, also auf einem ganz anderen

Maßstab natürlich, aber werden die

Deferred Reference Counts verwendet.

Ja, cool. Super coole Sache.

Ja, genau.

Aber es ist halt, wie gesagt, auch bisher noch

experimentell

und standardmäßig nicht eingebaut. Da gibt es auch noch

so ein paar Nachteile. Die Single Thread Performance ist

auch quasi in der

Free-Threading-Version schlechter im Moment.

Ich glaube vor allem, weil sie im Moment eben noch

dieses Bytecode-Rewriting,

wo wir vorhin in der JIT-Sektion drüber gesprochen haben,

noch abschalten müssen.

Eben aus dem Grund, dass wenn ich quasi mehr

als einen Thread habe,

der die gleiche Python-Version ausführt

und alle wollen jetzt den Bytecode umschreiben,

dann habe ich da eben auch wieder

quasi

Mutationen derselben Datenstruktur

von einem Thread und das will ich nicht immer locken

und deswegen haben sie das bisher einfach

abgeschaltet in der Free-Threading-Version

und das sorgt dann eben für

weiß ich nicht, 10%, 20%

Verschlechterung der

Single-Threading-Performance.

Oder

es gibt eben, ein anderes Problem ist, dass es

gibt eben einfach ganz, ganz viel Python-Code, der

so in der Welt ist, in irgendwelchen Bibliotheken,

der einfach nicht Thread-Safe ist.

Bisher konnte man sich halt so ein bisschen immer

so durchmogeln

mit der Tatsache, dass meistens ist man

halt vom Gill geschützt und

so viel Multithreaded-Python-Code

gibt es halt auch oft nicht und

deswegen finden wir jetzt

wahrscheinlich die nächsten zehn Jahre

Locking-Bugs in allen

PyPI-Bibliotheken.

Und für die C-Extensions

gilt das natürlich erst recht.

Ja, aber die C-Extensions hatten ja vorher schon

die Möglichkeit, den GIL

freizugeben, also NumPy zum Beispiel.

Ja, sobald ich quasi was

mache, was dann wirklich

weit weg von jedem

Python-Objekt.

Genau, was aus dem

Python-Memory-Management rausgeht.

Da kannst du schon mit deinem Fuß

deinen Sprecher kaputt hauen.

Ja gut, okay, Footguns.

Also genau, die große

Mathematik-Multiplikation, die NumPy macht,

die hat halt mit Python nichts mehr zu tun.

Und die konnte halt dann auch schon

auf dem extra Core dann

den Lüfter heiß laufen lassen.

Aber genau.

Ja, das sind die

wenigsten Operationen, das ist mir schon klar.

Die prinzipielle Möglichkeit gab es vorher schon.

Wenn ich mein eigenes Memory Management

mache, brauche ich auch, bin ich nicht auf den Gelenk.

Ja, aber da hat man sich dann ja auch wahrscheinlich

dann schon Gedanken drüber gemacht, wie man das dann tut,

ohne dass es kaputt geht. Oder wenn man

es falsch gemacht hätte, wäre es schon aufgefallen.

Aber ganz viel von dem, wo man sich keine Gedanken

gemacht hat, das wird dann jetzt wahrscheinlich irgendwann

auffallen, dass das nicht ganz richtig war.

Das ist auch in der Standardbibliothek.

Da gibt es einfach ganz viele solche Stellen.

Wir hatten heute so ein Bug-Report.

Es gibt das Line-Cache-Modul.

Das kennt keiner, weil man das quasi selber nie benutzt.

ist quasi dafür da, dass wenn ich Tracebacks

kriege, dass die Source-Code-Zeilen

halt quasi aus den Python-Dateien

geladen werden zum Anzeigen. Und das wird

gecached, damit ich nicht jedes Mal die Dateien eröffnen muss.

Und wenn ich jetzt aber

quasi Python-Code zu Laufzeigen erzeuge, mit

exec oder so, dann kann ich quasi auch

da dann in den Line-Cache

so Sachen reinschreiben. Und die

will ich aber vielleicht auch wieder löschen, damit

eben der Cache nicht mehr und mehr Speicher

verwendet. Und dann hatten wir einen Bug von

SymPy oder so, die schreiben da eben so

Sachen in den Line-Cache rein und löschen die dann auch wieder.

und dann stellt sich halt raus, dass der Line-Cache

nicht Thread-Safe ist. Also wenn ich

das quasi von mehreren Threads mache,

dann kriege ich halt irgendwelche komischen Exceptions

von irgendwelchen internen Line-Cache

Funktionen, von denen ich noch nie gehört habe

und ja,

also wenn, klar

das ist jetzt alles schon extra ultra

speziell, aber so Stellen wird es

halt in der Standardbibliothek auch noch an

anderen Plätzen geben, dass man halt dann

feststellt, oh okay, es gibt hier Python-Code,

da hat halt noch nie jemand drüber nachgedacht,

was passiert eigentlich, wenn ich das auf

vier Threads gleichzeitig ausführen.

Ja, und eigentlich sollte man sich ja auch keine Gedanken,

beziehungsweise es ist ja der

Ansatz, dass man sich keine Gedanken drüber machen soll.

Viele andere Sprachen lösen das Problem halt

auf eine andere Art und Weise, indem sie sagen,

da musst du jetzt halt selber explizit drüber nachdenken.

Also

man wird da... Das ist ja der Ansatz, dass man es in Python

nicht machen muss. Man wird da in Python schon drüber nachdenken

müssen. Also wenn du halt sowas hast, wie du hast

irgendein globales Dictionary und das wird

jetzt von zwei Threads mutiert und ich habe aber in beiden

eine Iteration darüber,

dann sind halt wahrscheinlich die Invarianten

der Schleife kaputt, egal ob die Datenstruktur

jetzt, also klar, die Datenstruktur

soll nicht kaputt gehen, aber ich kann

ja trotzdem dann plötzlich den Key

verlieren, den ich erwarte, dass da noch

eine Dictionary drin ist.

Ja, auch diese ganzen

Probleme, die bei Multithreaded Programming

auftreten, also allein,

wenn ich irgendeine Variable habe, die ich inkrementieren

möchte, dann, da muss

ich ja schon irgendwie einen

Mechanismus haben, der

Multithreading ermöglicht, aber

das ist ja nochmal eine ganz andere Ebene.

Ja, ja klar und das ist auch, also solche

Bugs haben wir definitiv auch schon gesehen, also

sowas wie, ja die sind ja auch leicht,

also ich meine, die hat man ja sofort,

ja, also sowas wie self.counter

plus gleich 1, das ist halt nicht

Atomic in

der Free-Threading-Version, ja, also wenn ich

da mehrere Threads habe, die das machen,

dann, ja,

dann könnten halt komische Sachen passieren.

Aber da gab es auch früher schon so,

Gab es auch früher schon so Stolperfallen, wo manche Sachen in Python Atomic aussahen und es dann aber irgendwie auch nicht.

Genau, also viele von diesen Bugs, die sind quasi bisher auch schon, das sind jetzt quasi keine Bugs, die nur in Free Threading wirklich vorhanden sind. Das sind quasi latente Bugs, die es schon immer gibt, die auch quasi in der ganz normalen GIL-Version von Python Bugs sind und Crashes verursachen können.

Nur bisher waren die quasi einfach viel unwahrscheinlicher, dass man die wirklich dann auch trifft, diese Bugs. Aber dadurch, dass jetzt eben mehr Leute versuchen werden, mit Multithreading in der Free-Threading-Version Programme dann schneller laufen zu lassen, wird die Wahrscheinlichkeit, dass man diese Bugs halt dann auch quasi in echt sieht, die geht halt hoch.

Das heißt, also ja, ich meine das ernst. Wir werden jetzt wahrscheinlich zehn Jahre lang Bugs in allen Bibliotheken finden, die irgendwas mit Threading zu tun haben.

Ja und es gibt ja auch keine so richtigen atomaren Operationen in Python oder keine, denen das ansieht, dass sie atomar sind. Das macht das Reasoning so ein bisschen schwierig.

Absolut. Und das ist ja auch eine der großen Schwierigkeiten des Free-Threading-Projekts, dass sie sich quasi bei allen eingebauten Containern, also wie Listen und Dictionaries und so weiter, jetzt überlegen müssen, welche der Methoden wollen wir eigentlich als atomar verstanden haben und welche halt dann auch nicht.

Das erkennt man nicht.

Ich glaube, das wird dann dokumentiert.

Ja gut, klar, das muss man nachlesen, aber ja.

Aber die Entwickler, die quasi Free Threading implementieren,

die müssen sich eben bei jeder Methode Gedanken darüber machen.

Also List Dependent ist halt Atomic,

aber List Extent bin ich mir schon mal nicht mehr so sicher.

Wenn das, was ich dann als Argument von Extent reinreiche,

wenn das selber ein Iterator ist

und da halt dann irgendwie mit einem Generator

Python-Code ausgeführt wird,

dann kann das halt auch eine Weile dauern, bis ich da durch.

bin. Und in der Zwischenzeit können

natürlich andere Threads dann laufen und

irgendwelchen Quatsch produzieren.

Ja, und jetzt machen wir uns

auf einmal Gedanken über Transaktionen und über

Transaktionsmanagement und das ist dann schon auf

Sprachebene was sehr Spezifisches.

Um die Frage zu beantworten, was für

einen atomaren Counter ich benutzen kann, da gibt's

irgendwie

itertools.counter oder so, heißt es glaube ich.

Und das gilt wirklich als,

also das ist die

Thread-Safe-Variante, um einen

atomaren Counter entfalten zu haben.

Also hätte ich jetzt nicht

gewusst. Ich auch nicht, aber

wir hatten halt Bug-Reports, die gesagt haben,

self.x gleich 1 geht halt nicht.

Ja, genau.

Ich erinnere mich noch, das habe ich vor Jahren

mal diese Meinung

vertreten, dass das Global Interpreter

Log mich davor schützt, dass ich

x plus gleich 1 machen kann, so viel ich will.

Und dann haben wir

im Chaosdorf

an einem Abend das einfach mal ausprobiert

und es stellte sich als falsch

raus, die Annahme, weil man eben sehr schnell

falsche Zahlen rauskriegen kannst.

Darf ich kurz fragen?

Ja.

Das ist selbstverständlich.

Was wissen wir hier?

Also das komplette, wie heißt das, Insider Baseball,

also das hat sich geändert in den letzten Python-Versionen,

also in den letzten C-Python-Versionen.

Du hast absolut recht, dass quasi, also ursprünglich war die Regel,

ein Bytecode ist atomar und aber theoretisch kann ich

nach jedem Bytecode eben einen Thread-Switch haben

und sowas wie

das erwähnte Beispiel

X plus gleich 1, das sind eben mehrere

Bytecodes, das heißt, da kann ich dazwischen

ein Threadswitch haben und entsprechend

ist das nicht atomar. In einer

der letzten Versionen,

ich weiß nicht, 3.12 vielleicht oder so,

haben sie quasi

in CPython die Bytecodes,

wo man Threadswitches

machen kann, also in der

regulären GIL-Version,

stark reduziert.

Und es gibt jetzt eben nur noch ganz, ganz wenige

Bytecodes, wo wirklich dann

Switches stattfinden können.

Das sorgt dafür, dass die

quasi beobachtbare...

Atomarität

zunimmt. Das heißt, plötzlich

in 3.12 war dieses Counter-Beispiel

atomar. Und das ist natürlich

total schlecht, weil

wenn man die Community darauf vorbereiten

will, dass jetzt irgendwann mal der Guild entfernt wird

und man quasi mit

Thread-Switches an viel mehr

Stellen rechnen muss,

ist es halt schlecht, wenn man in der Version davor

dafür sorgt,

dass viel weniger Thread-Switches

an viel vorhersagbareren Stellen, nämlich nur

am Ende von der Schleife oder sowas, stattfinden

kann. Also

das finde ich, also ich meine

klar, dieses Reduzieren der

Thread-Switches, das erhöht halt wieder die

Single-Threading-Performance, das war der Grund, warum sie das

gemacht haben, aber ich finde es

halt unstrategisch.

Also ich glaube, wenn du in 3.12 das mit

dem Counter nochmal ausprobieren würdest, dann würdest du,

das wäre es quasi nicht mehr beobachtbar.

Dann mache ich das jetzt mal nicht, zur Sicherheit.

Mach lieber gleich in der

No-Gill-Version.

Ja gut, aber

damit muss es ja gehen.

damit müsstest du es kaputt kriegen, würde ich

hoffen. Ja, gut, kaputt kriegen.

Ja, also.

Ich habe jetzt leider keine Node-Gate-Version hier

kompiliert, deshalb muss ich leider.

Aber ich glaube, da gibt es auch zum Beispiel so, also es gibt

Packages davon. Ja, ja, also bei

UV habe ich jetzt gesehen, gibt es das auf jeden Fall.

Ja, bei UV, bei Python

inside. Genau. Und in

bei Panf.

In Panf weiß ich nicht, aber in Ubuntu,

in dem Dead Snake

PPA gibt es auch.

Ja, aber ich meine, also

ehrlich gesagt, ich weiß nicht, habt ihr

jetzt alle schon einen Anwendungsfall,

wo ihr unbedingt das mal ausprobieren

wollt, ob dann nicht alles viel schneller wird?

Weil ehrlich gesagt, ich habe das

dann nicht so

wahnsinnig viele Dinge.

Es liegt aber halt vor allem auch daran, dass wir

daran gewöhnt sind, es nicht zu brauchen.

Gut, das kann natürlich sein.

Ich glaube schon, dass es dann

einiges gibt, wo das halt schon

irgendwie auch, klar, man muss dann

sich irgendwie umgewöhnen und vielleicht

gibt es auch ein paar schöne Bibliotheken, die das halt alles

ein bisschen weniger gefährlich machen,

dass man so ein paar schöne Abstraktionen auf jeden Fall

jetzt hat.

Aber ich denke schon, dass wir

an einen Punkt kommen können, wo man dann eben sagen kann,

ja,

also früher hätten wir vielleicht Multiprocessing

genommen und es wäre nervig und

also frickelig gewesen,

das dann gut hinzukriegen und jetzt nehmen wir halt

und es funktioniert gut.

Ja, das

ist halt auch, mit Threads

programmieren ist halt

auch was Gefährliches. Da gibt es ja, also ich

meine, selbst wenn diese Operationen alle

atomar sind und selbst wenn das so ist, dann gibt es ja

immer noch diese ganzen Probleme

und Deadlocks und

Race Conditions und lauter anderes. Und das

ist einfach eine schwierige

Sache. Ich habe kurz, ich habe eben nachgeguckt,

es gibt in PyEnv gibt es eine

3.13.0 Version und es gibt eine

3.13.0T Version.

Und das werden die beiden

und der Schädlichen sein.

Gut, dann muss ich jetzt Boomer installieren.

Genau, und dann muss man ein altes Skript

vom Chaosdorf finden.

Es war

nicht so ein beeindruckendes

Testhahn. Es war einfach nur

zwei Threads, die eine Variable gleichzeitig

erhöht haben. Also das kann man relativ

leicht wieder rekonstruieren.

Ja, ich sehe das auch so.

Ich bin,

ich habe so sehr gemischte Gefühle,

was das Free-Threading angeht. Einerseits ist es halt

cool, weil endlich diese endlose Diskussion

aufhören auf der einen Seite und weil halt auch

wirklich jemand mal Geld in die Hand genommen hat und das

richtig gut macht. Also

richtig gut, klar, da kann man dann auch Details

kritisieren, aber die Tatsache, dass jetzt eben

irgendwie einige Leute

von Meta dafür bezahlt werden, das

halt wirklich zu machen und auch

quasi den Aufwand

betreiben, das in C-Python reinzukriegen, was ja

auch wirklich immer viele Diskussionen

und viel Überzeugungsarbeit und viel

Debugging und sehr, sehr viel Aufwand

sind

dafür nötig und ich finde es erstmal gut,

dass das halt jetzt passiert und

dass quasi auch die

Community mitgenommen wird und irgendwie

verschiedene, also es gibt ja

jetzt wirklich auch schon einige an Bibliotheken,

die jetzt mitziehen und gucken, dass sie halt auch

FreeThreading-Versionen dann

Binary auf PyPI releasen

und so weiter. Und das

ist schon wirklich

gut. Klar, auf der anderen Seite sehe ich

das, ich denke

wirklich, das wird

eine Riesenumstellung und das wird schon auch

was die Bugs angeht und was die

Eingewöhnungszeit angeht und

sowohl in den Bibliotheken als auch in der

Sprache selbst.

Ich habe mal so einen, das ist schon ewig her,

aber ich habe mal einen Vortrag gehört von einem

der

Sun JVM JIT-Entwickler,

der auch in einem ganzen Laufzeitsystem

und dem

Multithreaded Garbage Collector

und so gearbeitet hat und der meinte so,

im Garbage Collector findet man halt

zehn Jahre lang Multithreading-Bugs

und die werden halt immer schwieriger

zu finden und

ich weiß halt nicht so genau, ob

wir darauf so richtig gefasst sind.

Also anders.

Ja.

Naja gut, hat halt ein bisschen

Zeit noch populärer zu werden, dann steigt

die Wahrscheinlichkeit, dass man die Bugs findet, das ist doch gut.

Dann kann man auch schwierige Bugs finden.

Ist jetzt schon auf dem Tyobi-Index

ganz oben.

Also ich sehe es so ein bisschen,

hat ein bisschen eine andere Perspektive. Ich glaube,

die Möglichkeit, Multithreading

zu machen, eröffnet eine ganz