Transkript: Python 3.13

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast.

Heute Jubiläumsepisode 60.

Hi oh,

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

Ja, und auch genau, ja, beziehungsweise was.

Ja, genau.

Hallo zusammen und herzlichen Glückwunsch zur 60.

Episode.

Danke.

Und lieber TF, auch dir.

Vielen Dank, hallo.

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

Januar 23 haben wir gerade rekonstruiert.

Ja.

Wir sprechen heute über Python 3.13.

Ja.

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.

Also Python-Radresse des Jahres.

Genau, das ist natürlich irgendwie schon.

Ja, ist ja ein bisschen her.

Wir sind ein bisschen spät dran.

Aber das 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 PythonRail 13 kommen wir auch direkt.

War gar nicht so viel los, oder?

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

Na, dann machen wir es doch direkt.

Also ja, dann erzählen uns was.

Ich habe es 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 Pipe-Projekt übernommen wurde.

Mit der neuen REPL.

Was ist eine REPL?

Ja, so eine Read, Evil Print Loop, irgendwie das, was man bekommt, wenn man einfach nur Python eingibt und entrückt.

Also nutzt ihr schon Pre13 alle?

Außer Jochen?

Nee, ich habe es noch nicht installiert.

Ich nutze es nicht, also die neue RAPL.

Ah.

Das ist natürlich ein Speiser.

Ja gut, ich benutze iPython überall.

Warum nicht viel bei das?

Das hatten wir vorhin im Vorgespräch schon mal kurz besprochen.

Also ich fand die Bekundung interessant, warum sie eigentlich überhaupt die RAPL verbessern, wenn sie sowieso, ja, wissen, dass die meisten Leute halt sich sowieso als erstes erstmal iPython installieren, weil das halt einfach 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 PyPy 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 Multiline-Edit, schönere History-Farben Raple implementiert, der jetzt in Teil 13 released.

Ich fand's auch toll, weil ich meine ZV für iPython und ich mache das eigentlich sonst nochmal klassisch und toll.

Endlich, die Welt bunt.

Die Welt verbessert durch Eigennütz.

Also Sauerei.

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

Also ich habe jetzt seit, weiß ich nicht, Oktober dann jetzt auch den Farbing Raple.

Und wenn ich dann aber eine alte Version benutze, und das ist dann plötzlich nur noch schwarz-weiß und es ist ja gar nicht so viel Farbe, das sind ja wirklich nur die Größe als Zeichen.

Aber das kommt einem dann fast schon altbacken vor nach so einem Fragen.

Ja, Bang to the Future, das ist schon ein bisschen wie als damals, ja.

Aber das hat das nicht früher, dass es noch grün war oder so, aber echte Hacker und so.

Ja, die Farbauswahl, die die C-Peiten-Entwickler getroffen haben, das war ein riesen Diskussionsthema.

Das ist halt so Bike-Shading-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, was ist das, dieses Pink und Rot, das sind so 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.

Wusste auch nicht.

Ja, aber genau, wie kommt das denn, dass du die REPL schon verwendet hast, obwohl gar nicht.

Ja, also die RAPL ist, das ist quasi die PyPy-Raple, nicht ganz.

Also die haben total viele neue Features eingebaut und Bugs gefixt und so.

Aber so dieses Kern-Feature, dass es eben Multiline-Edit gibt, also vielleicht können wir auch kurz sagen, was das ist.

Also wenn man quasi auf der Python-Chell eine Funktion eingibt, 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 PyPy hatte das, wie ich gerade schon gesagt habe, quasi schon immer, also in Anführungszeichen, also seit PyPy 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 die Funktion neu.

Und das hatte halt, das haben halt zwei der frühen Piper-Entwickler einfach so als in Anführungszeichen normalen Python-Code geschrieben.

Das war einfach, also das hat eigentlich keine Pipel-spezifischen Features irgendwie gebraucht.

Michael Hudson, Doyle und Armin Rigo waren das.

Und so vor ungefähr vor einem Jahr haben halt zwei der C-Python-Entwickler, Wurka Schlanger und Pablo Galinus Salgado, gesagt, dass sie das auch gern für C-Python hätten.

Beziehungsweise die haben halt versucht, sich zu überlegen, wie sie den Rappl verbessern können.

Der RAPL war bisher in C-Python in C geschrieben und das macht halt alle Verbesserungen darin 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 haben.

Und also da haben die quasi so ein bisschen Grund überholt und neue Tests geschrieben und so.

Und eben auch einiges an neuen Feature 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 der auf die Einwirkung 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 reinfliegen kann.

Ich habe gehört, dass das schon ein bisschen älter ist, weiß aber nicht, bei welche Version das reingekommen ist.

Man kann eine Environment-Variable setzen und dann wird ein Skript ausgefüllt.

Das heißt, du hast deine Imports, die du immer machst, direkt mit dabei, wenn du zum Beispiel diese Env setzt.

Deine sieben Lieblingsmodule.

Ja, das sind nur sieben.

Sieben?

Finde ich ziemlich cool.

Man kann dann lustige Sachen machen.

Python Startup heißt das.

Ja, sehr schön.

Muss ich unbedingt für mein System auch bauen.

Ja, aber genau, also auch ein großer Vorteil ist, glaube ich, auch jetzt, dass es, also 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 Schlange hatte da auf der EuroPython auch einen Vortrag gehalten, wie man Live-Coding.

Oder wie bei einer Performance performt.

Live-Musik-Coding-Geschichten und da ist es natürlich praktisch, wenn man halt.

Lustig war, dass der Tontechniker, der hat einen Eurorick dabei gehabt und hat irgendwie so einen hohen Ton auf seinem Synthesizer gespielt, hat der Tontechniker kurz Angst bekommen, dass seine anderen Geschrott 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 ist jemand hat geklopft vom Tuchtechniker 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 Bugreports und Patches, was den neuen Rappl angeht.

Es ist immer noch so, dass es schon so ein bisschen nervig ist, anzuarbeiten, weil wenn der Rappl kaputt ist, dann sieht man halt auch gleich nichts mehr.

Also der Debugger geht nicht und es ist schon, die haben dann 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 dann wieder auf den alten Dings zu kommen.

Aber ja, klar, ist natürlich, wenn man es kaputt macht, dann ein Problem.

Wichtiges anderes neue Feature ist natürlich, dass man jetzt bei Exit keine Klammern mehr braucht.

Oh ja.

Ja, und ich glaube, Quit geht auch.

Ja, echt ist das so.

Ja, und Help geht auch irgendwie jetzt anders, aber ehrlich gesagt, keine Ahnung genau, wie.

Ja, es gibt jetzt diesen Help-Mode, der eingemaut 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?

Das möchte ich so möchten so etwas Python 2 wieder haben.

Vielleicht das mal als Feature-Request.

Also das kannst

du jetzt auf jeden Fall für deine Raffle kannst du das einbauen, dass sie sich dann wieder gegen Python 2.

Das mit dem

Exit ist tatsächlich was, was halt Newbies sich relativ oft wünschen.

Q reicht, glaube ich, auch.

Q reicht?

Nee.

Warum fehlt denn das da?

Weiß ich.

Ach, für den Head Mode.

Ja, also Kütt geht, aber Q nicht.

Schade.

Alias QQ, dann muss man ja direkt wieder in das Schrift reinschreiben.

Ja.

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

dann daran angelehnt, wir haben jetzt Farben ja schon angesprochen, vielleicht können wir noch über die Tracebacks sprechen.

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 Dächle, Johannes?

Genau.

Dechle, ja.

Das ist da, wo ich herkomme, sagt man Dechle.

Sind halt auch keine Dächer, sondern nur kleine Dechle.

Also Ghost in the Guarded.

Genau.

Also es wird jetzt quasi nicht mehr nur gesagt, es 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 so.

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 Busartigkeit, das schaue.

Also wir können es 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 C-Python hat uns dann halt einfach ganz schnell überholt und viel mehr Leute benutzen C-Python.

Ja.

Genau, hier kann man es auch nochmal sehen.

Ja, jetzt natürlich nicht, wenn ihr zuhört, aber.

Ich kann es jetzt sehen.

Einziger Zelt.

Ja, ja.

Genau.

Ja, auch schön, man kriegt jetzt irgendwie gesagt, wenn man halt ein Modul genauso genannt hat wie eins aus der Standardbibliothek oder von sonst wie 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 verursichert haben.

Das ist jetzt, glaube ich, auch besser.

Der macht das Vorschlag, er versucht sich daran zu erinnern, was denn der Fehler schon sein könnte und versucht einen kleinen Hinweis dazu zu geben.

Ich meine, das für das wird halt in jeder Version jetzt gerade so ein bisschen verbessert.

Es ist schon so ein, jetzt über einige Versionen 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, also ich unterrichte halt Python-Anfänger jedes Semester.

Das macht schon echt einen Unterschied, ob da dann irgendwie halt Abkürzungen vorkommen, die die noch nie gehört haben oder einfach nur Syntax-Error ohne irgendwas anders steht und so ein bisschen raten müssen, was das Problem gewesen sein könnte.

Und das mit den Vorschlägen, also wenn man sich halt vertippt, wenn man irgendwie 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-Distanz 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 so nutzt, dann direkt kann nicht mehr so lange dauern.

Wann zieht der 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 mir enthält, 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 so.

Du bist dann einer von denen, die dann die Bugreports machen, wenn was nicht gibt.

Ja.

Aber meistens ist das halt so abstrakt, dass ich da gar keine, gar nicht in Bugs reinlaufe.

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

Und dann wirklich 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 nicht updaten können auf 313, weil irgendwas mit Py-Test 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 da die Dinge, die ich angefasst habe, seitdem Python 313 raus ist, habe ich es umgestellt und es war bis jetzt auf das eine Ding kein Problem.

Ja, die Data Science-Vacke sind immer so ein bisschen langsam, dann haben die immer diese SAP-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.

Wobei ich auch da das Gefühl habe, dass eigentlich viele Bibliotheken sich da jetzt inzwischen echt Mühe geben und halt schon schon bei den Bitas 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, ich bin gespannt, wie lange es diesmal dauert, tatsächlich, ja.

Ja.

Ja.

Wollen wir 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 Block.

Ja, jetzt gibt es noch zwei Blöcke.

Das war auch schon ein großer, ja.

Ich habe eben noch hier die Dokumentation durchgeschaut und den History-Modus, den fand ich auch ziemlich gut.

Mit F2 kann man seine History ansehen.

Ist das noch persistent?

Ja, die, also ich habe eben in mein History reingeguckt in meine Session, die ich gerade angemacht habe.

Das geht sehr weit zurück.

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

Oh, da muss man jetzt halt aufpassen, was man

noch print ohne Klammern.

Naja, das will ich jetzt nicht.

Ohne Anwalt möchte ich diese Frage nicht beantworten.

Nee, es ist schöne, sehr viele schöne Sachen, aber ich finde es sehr interessant, dass es 313 so ein Release ist mit einer riesigen Änderung im Frontend.

Also jetzt diese Rappa-Sachen.

Aber ja auch sehr große Änderungen im Backend, zu denen wir jetzt kommen.

Du meinst ja Snoogel.

Ja, es

gibt zwei Dicke.

Da machen wir Töt.

Da habe ich mir Notizen.

Ja, super, okay.

Alles klar.

Also beides sind ja eigentlich Sachen, die sie eher so im Himmel.

Vielleicht nochmal für alle Leute, die einsteigen, die noch gar keine Ahnung von Platz haben.

Was ist denn das und warum ist das interessant und warum ist das wichtig?

Vielleicht nochmal so einen kurzen Aufzug lang und dann.

Also C Python ist ein Interpreter, also der Python-Code, den 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 dass 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.

Und 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, wo 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-Bilds ist das Feature nicht drin.

Das ist eher so ein Feature-Outlook für zukünftige Versionen, dass man eben C-Python 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 T13 ist es aber leider noch nicht der Fall.

Also sie erzeugen quasi Maschinencode, aber der macht es halt nicht, das macht es trotzdem nicht schneller.

Das ist so ein bisschen die schlechte Nachricht.

Aber das ist trotzdem okay, weil das Ziel ist quasi, so die ganzen, die ganzen, das Fundament zu legen für Verbesserungen, die dann in den nächsten Versionen 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 Justin-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 und Patch.

Ich weiß nicht.

Also so ganz kann man das nicht sagen.

Also es gibt die Idee gibt es schon sehr lange.

Also 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 einem Copy-and-Patch-Ansatz.

Das ist ein Doktorand in Kalifornien, glaube ich.

Hau Rang 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 einen 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 einen 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-Button 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 Memcopy 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 linker 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 relativ guten Maschinencode erzeugen kann.

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

Genau, das ist auch so ein bisschen das Problem.

Also man braucht dann genau die richtige LFM-Version.

Ah, okay.

Wenn man die nicht installiert hat, dann bringt einem auch die Flagg 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 C-Python 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.

Ich hätte sowas mal gelesen.

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 LVM ist die deswegen relativ sichtbar, weil sie halt gute Tools haben, um die dann in so eine ASCII-Syntax zu printen und da auch wieder zu parsen und weiter zu verarbeiten.

Aber ja.

Auch viele technische Bauteile immer noch, ja, 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.

Also 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 weg optimieren.

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

Und die Hoffnung ist, dass dann eben, wenn 3.14 dann da ist, dass das erstens eben dann, dass sie so ein paar Bugs gefixt haben, weil hoffentlich eben ein paar Leute trotzdem die den experimentellen JIT halt mal ausprobieren und dann vielleicht Bugreports schicken.

Und dass sie dann halt in der nächsten Version dann auch die Performance noch so ein bisschen verbessern können.

Und insgesamt finde ich den Ansatz halt cool, weil er in Anbetracht der Tatsache, dass das C-Preisen-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 V8 hat halt irgendwie, weiß ich nicht, 80 Leute oder so.

Das fand

ich auch überraschend, ja.

Und also, dass sie halt quasi mit der kleinen Anzahl an Festangestellten halt trotzdem mit diesem Ansatz vielleicht irgendwie recht pragmatisch irgendwo hinkommen können.

Ja, ich meine.

Nein, ich finde das auch cool.

Ich finde es 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 viele 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 rausgestellt hat, was da gut funktioniert, halt, dann die wesentlichen Teile nimmt oder so.

Das wäre schon.

Wobei, ich weiß nicht genau, ob da hat, gibt es irgendwo quasi den gleichen Ansatz, der dann schon gut funktioniert.

Weil V8 ist ja dann wahrscheinlich doch eher noch ein 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-Team halt erstmal so nicht hinkriegen kann.

Also.

Transpilen nach einfach Python transpilen nach JavaScript.

Ja, oder nach WebAssembly.

Stimmt, das ist ja tatsächlich eine unterstützte Plattform, ja, wo man.

Genau, es ist eine Tier 2-Plattform.

Ja, genau, das stimmt.

Also das ist so ein kleines Ding.

Es gibt drei neue Plattformen in 3.13.

Super spannend.

Also ich mache, ich lese mal hier vor.

Also die erste, die Tier 2-Plattform heißt WASIM32Wasi, 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 viele Bildboards sie haben und was sie so versprechen an die Versionen.

Da gibt es irgendwie ein Pep dazu.

Ja, okay, gut.

Also das kann man nachlesen.

Auf jeden Fall Tier 2.

Ist das eine höhere Zahl besser oder eine kleinere?

Nee, ich glaube, 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-Plattformen mit vielen Bildbots und viel Stabilität über die Version.

Und es gibt zwei neue Plattformen, die, da war ich sehr überrascht, dass es die gibt, nämlich Android und iOS.

Das sind Tier 3 Officially Supported Plattformen.

War ja früher ein Riesenthema, ja, 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, aber es halt einfach den Interpreter auch kopilieren und so.

Und da ging auch NumPy und so, das ging alles.

Und es gab da so ein schönes, so eine schöne App namens Pythonista.

Womit man, aber die hat natürlich eigentlich schon gegen die App Store-Regeln verstoßen und so.

Also mein Beowulf-Cluster aus iOS, aus iPhone ist, äh.

Was ist genau die Regel?

Also die App Store-Regel ist, ähm, du darfst da nur Dinge installieren.

Also kompilierter Code, ja, aber auch irgendwie C<unk>, C, irgendwie Objective-C und was war es noch?

Ich weiß nicht, vielleicht eine Handvoll Spiele.

Wichtiger ist doch die Regel, dass du keinen dynamisch erzeugten Code nachladen kannst.

Ja, das genau.

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 dann davon machen.

Ja, eigentlich geht, und du konntest halt einen Pythonester, da kannst du halt auch so 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 weil halt das Tooling bisher immer sehr umständlich.

Also ich weiß, dass es B-Ware gibt und es gab auch Kiwi und viele andere Ansätze schon, aber die waren schon immer sehr umständlich.

Ja.

Und wenn es jetzt nicht mehr so ist,

deswegen ist es schon auch schon noch wichtig, 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 Teil 1 ist halt das richtig gute Zeug, also so mac OS, Windows, Linux.

Teil 2 braucht man halt irgendwie Buildboards und mindestens zwei C-Python-Core-Developer, die eben die Plattform unterstützen.

Und wenn es da Buildboard-Failures gibt, dann werden C-Python-Releases dadurch blockiert.

Und Thail 3 heißt eben Buildboard 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 ein, wir geben uns Mühe, aber wenn jetzt irgendwie 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.

Der macht das ja auch schon lange.

Der, der auch BWare schon gemacht hat, der das schon lange macht, das jetzt offenbar eben reingekriegt.

Der diesen tollen Vortrag, die sind gehalten, hat irgendwie Black Swan-Events für, oder ich weiß gar nicht, wie der Titel von dem Vortrag hat.

Aber da ging es halt genau darum, was ist könnte, was ist eigentlich, das sind die bedrohlichsten Geschichten, die jetzt Python noch zustoßen können.

Und eines 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 in Vergessenheit gerät, dass es Python überhaupt noch gibt, weil man 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 vorbei schon Studenten echt.

Also ich habe halt, also ich mache eine Python-Einführung für alle, also da sitzen dürfen Informatiker nicht hin.

Und das heißt, ich habe auch wirklich 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.

Ja, aber Jupyter Notebook hat es.

Die haben dann halt entweder die Möglichkeit, das irgendwie über Google Collab zu machen, also ich mache alles mit Jupyter 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 Rechenzent umsetzen, da hast du es auch installiert, aber es ist natürlich auch total nervig.

Du musst immer deine Übungsaufgaben dann machen.

Und so einen richtig, also richtig guten Jupyter-Support auf so einem iPad, gibt es halt einfach auch noch nicht.

Also es ist schon einfach im Vergleich zu installiert Anaconda, dann ist alles in Ordnung, ist es halt schon einfach sehr frickelig.

Ja.

Ich muss noch dazu sagen, nicht, dass wir jetzt hier Personen übergehen.

Es gibt noch zweite Maintainer für diese Plattformen, neben Russell Keith McGee.

Für Android gibt es noch den Peter Viktorin oder Peter Victorin oder wie auch immer man das aussprechen mag.

Einer von den anderen Developers und

für iOS gibt es noch den Delhi.

Also wieder so eine tolle Name-Coding machen.

Da muss ich ja nochmal kurz zum Sammelkartenspiel zurückkommen, was euch kurz angeguckt hat.

Weil ich ja auf dem

Jahr die neuesten Einträge von ganz

Langer, der ja in diesem tollen Raple irgendwie dann ein kurzes Befehlchen eingeben konnte, um das Bild von, ich dachte, es wäre John Romero gewesen, was eigentlich Pablo Kalender Sagato 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 ruhig macht.

Wir bringen die erste Edition mit, dann machen wir den Python-Podcast das dann Thema an.

Ich finde, die sollten das selbst verteilen und nur die Leute, die bei den Vorträgen waren, kriegen ja auch so eine Karte.

Also ich glaube, man kann die verkaufen.

Also das ist, glaube ich, ich vermute, dass das wirklich die Art und Weise ist, wie man endlich mal gutes Funding für Zehnplaten findet.

Ja, dann liebe Zuhörer, schreibt uns, ob das die Wahrheit ist und dann müssen wir das

wohl machen.

Damals als NFTs neu waren gab es ja auch so Sachen, die dann diese Bilder dann gemacht haben und das dann als NFT im Bau.

Ja, aber das mit den NFTs ist immer noch die Zukunft.

Ich weiß nicht.

Der einzige Vorteil von AI ist, dass sie die NFTs verdrängt haben.

Für einen ganz kurzen Moment waren Grafikkarten wieder billig und dann hat die AI zugeschlagen.

Tja, so ist es.

Okay, also es gibt zwei neue Plattformen, Android und iOS und es ist eine großartige Sache,

finde ich.

Und WebAssembly.

Und WebAssembly, ja genau, WebAssembly ist quasi aufgestiegen da.

Da müssen wir auch um den

M-Skripten zu quasi.

Wir müssen noch über den anderen JIT reden.

Ja.

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 von ganz anderen Zweck.

Ich glaube, in einer der Core.pY-Folgen ist Pablo Galino Sagato, über den wir gerade auch schon geredet haben, sehr stolz drauf, dass er quasi den ersten C-Python-Jit gemt 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 einen, 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-Overhead ist sehr gering.

Das Problem ist jetzt aber, dass wenn man quasi Python-Programme profilet, 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 Perf-JIT.

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 dann den Vorteil, dass Perf eben die ganzen Python-Funktionen voneinander unterscheiden kann.

Wenn man eben nicht nur eine interpretierte 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 eine große Sammlung an Profilern für Python für andere Sprachen, aber C-Profile hat halt einfach ein 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 habe wieder vergessen, was.

Ich habe mal irgendwas benutzt, auch ein Sub-Bon,

der Hotspot hast.

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 VM Prof, der ist aber nicht mehr so richtig maintained.

Also auf iPhone schon, aber Ziphython nicht so richtig.

Gibt es 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 Information, 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 braucht.

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 Code-Block schreiben und ich kann ihn ausführen.

Also man kann ihn 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.

Achso, das geht.

Ja, ich will mit Mac OS, ich glaube, im letzten Copy-By-Episode war auch irgendwie drin, dass der Memory Profiler Memory, den Pablo, der hat auf macOS nicht funktioniert, weil irgendwie sie die Maloc-Funktion irgendwie, also nicht die Modern haben.

Von einer MacPhone zur nächsten.

Ja, 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.

Ja, das ist so Low-Level, das ist, sinkt dann eigentlich der Tier, das ist dann Tier 0, oder?

Sorry, couldn't resist.

Das 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 immer, ist halt, ja, es nennt sich jetzt Free Threading früher NoGill irgendwie, dass man halt optional den Gill ausschalten kann.

Ist auch eine, muss man Compiler-Flex setzen und dann neu kompilieren oder halt sich 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.

Wie macht das denn überhaupt, der Gil?

Oh.

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

Aber das ist ja nur eine Auswirkung, das ist ja nicht das Ding.

Ich glaube, das ist tatsächlich das, was

kann auf vielen CPUs laufen, nur halt immer nur auf einer gleichzeitig.

Ja, immer nur auf einer gleichzeitig.

Genau, genau, das möchte ich.

Ja, ja, genau.

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 halt viele Operationen, ja, gerade was Memory Management angeht, halt 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 Thread-Safe.

Und das bedeutet, dass wenn man die von mehreren Threads aus benutzt, wird alles kaputt, dass die dann kaputt gehen können.

Insbesondere das Reference-Cock.

Um das zu verändern, müsste man halt locken und wenn man lockt, dann wird alles so langsam, dass man keinen Vorteil mehr davon hat, dass man mehrere CPUs hat.

Also ich glaube, die ersten Versuche, das war, dass das Projekt hieß irgendwie Galactomy oder so.

Noch ein älteres.

Also so alle paar Jahre kommt mal jemand an locker.

Doch bei 1.1 wieder nicht genau aufgepasst.

Ja, genau, also es war wirklich so 1.6 oder irgendwie sowas ganz frühes, wo das dann.

Ja, 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 so Faktor 40 weniger und ja, dann hat man es auch.

Die Single Performance.

Und dann hat man es runtergekriegt mit Tricks auf 20, äh Faktor 20 irgendwie schlechter, aber das ist halt immer weit noch sehr, sehr 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 räumt man die denn dann weg?

Was ich nicht mehr brauche.

Du meinst Garbage Collector?

Ja.

Gut, das ist nochmal ein anderes, da weiß ich gar nicht, ob der.

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

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

Im Garbage Collector hatten die quasi bei diesen Galactomy und so versuchen, auch nichts geändert.

Was sie gemacht haben, ist jedem Objekt einen Log zu geben.

Und immer wenn ein Thread mit dem Objekt eben interagieren wollt, 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 rum operierst, ja, musst du halt ständig auf das Log warten und das hat halt die bisherigen Versuche, den Gill zu entfernen, einfach sehr, sehr teuer gemacht.

Also die Single Core Performance eben, äh, 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 einmal ist.

Jetzt wird es super kompliziert.

Also so, also wir haben jetzt, genau, es gibt den Gill, der Gill verhindert, dass mehr als ein Thread-Python-Code ausführen kann.

Mehr als, 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 reinappendet 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 gescherte 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 Objekten, 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 None.

Warum nicht wegräumen?

None 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 None 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 dann muss man die auch wieder nicht locken.

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 die eben die Idee, dass man eben das Erhöhen und senken das Reference Count nicht mehr die ganze Zeit up to date macht, um eben zu ver.

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 Stack-Frames gibt oder so, die dann noch dazugezählt werden müssen.

Deswegen eben deferred.

Und nur wenn man da dann eben überall nachschaut 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 Meme-Aloc, das ist so ein von Microsoft geschriebener C-Memory-Alocator, der eben auch besonders gut mit Multithreading interagiert und da wird auf eine für mich noch nicht ganz verständliche Art und Weise eben mit besonderen Meme-Maloc-Features dann erreicht, dass genau das Richtige passiert.

Aber genau das Richtige passiert, das ist mal toll.

Ja.

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

Ich glaube, das ist genau.

Im Endeffekt ist das ja, 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.

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 dann 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 es ja nur aufmachen, wenn du es wirklich wissen willst.

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

Und ich glaube, das macht, also 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 consistent ist.

Aber das hat halt im Datenbankbereich dann auch entsprechende Nachteile, Performance-Nachteile.

Und gerade in verteilten Datenbanken.

Genau.

Und quasi aus den gleichen Gründen führe ich halt quasi im Fehl, also von einem ganz anderen Maßstab natürlich, aber werden die Deferred Reference Counts verwendet.

Ja, cool.

Super coole Sache.

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-Rerriting, wo wir vorhin in der Sektion drüber gesprochen haben, noch abschalten müssen.

Eben aus dem Grund, dass, wenn ich quasi mehr ein Thread als ein 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 da will ich das wirklich 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 Signal-Treading-Performance ist.

Oder es gibt eben ein anderes Problem ist, dass es 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 man halt vom Girl geschützt ist.

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 Tintkill 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, der

kannst du schon mit den Food-Sticken gar nicht sprecher kaputt hauen.

Ja, gut, okay, Footguns, ich meine.

Also genau, die große Matrix-Multiplikation, die NumPy macht, die hat halt mit Python dann 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 klein.

Die prinzipielle Möglichkeit gab es vorher schon.

Wenn ich mein eigenes Memory Management mache, brauche ich auch, bin ich nicht auf den Gelände.

Ja, aber da hat man dann, 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 ist.

Das auch in der Standardbibliothek gibt es einfach ganz viele solche Stellen.

Also wir hatten heute so einen Bugreport.

Also es gibt das Line-Cache-Modul, das kennt keiner, weil man das quasi selber nie benutzt.

Das 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 Laufzeit erzeugt mit Exec oder so, dann kann ich quasi auch da dann in Linecache 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 Simpai oder so, die schreiben da eben so Sachen in den Linecache rein und löschen die dann auch wieder.

Und dann stellt sich halt raus, dass der Lioncache nicht Thread-Safe ist.

Also wenn ich das quasi von mehreren Threads mache, dann kriege ich halt irgendwelche komischen Exceptions von irgendwelchen internen Linecache-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 Falls gleichzeitig ausführe.

Ja, und eigentlich sollte man sich ja da 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 muss jetzt halt selber explizit drüber nachdenken.

Also man wird da der

Ansatz, dass man 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 halt trotzdem dann plötzlich den Key verlieren, den ich erwarte, dass da noch in einem 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

sind ja auch leicht.

Also ich meine, die hat man ja sofort.

Ja, also sowas wie Self-Punkt-Counter plus gleich eins, das ist halt nicht Atomic in der Free-Threading-Version.

Also wenn ich da mehrere Threads habe, die das machen, dann können halt komische Sachen passieren.

Konnte doch.

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

doch 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 Girl-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 es 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.

Genau, also das ist.

Das macht das Reasoning so ein bisschen schwierig.

Absolut.

Und das ist ja auch eine der großen Schwierigkeiten des Free-Threading-Qu-Projekts.

Dass sie sich quasi bei allen eingebauten Containern, so 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.

Wann erkennt man das?

Das erkennt man nicht.

Ich glaube, das wird dann implementiert dann.

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

Aber die Entwickler, die quasi Free Thrilling implementieren, die müssen sich eben wirklich bei jeder Methode dann Gedanken drüber machen.

Also List append ist halt Atomic, aber ListXtend bin ich mir schon mal nicht mehr so sicher.

Wenn das, was ich dann als Argument von Xtend reinreiche, wenn das selber ein Iterator ist und da halt dann irgendwie mit einem Generator irgendwie Python-Code ausgeführt wird, dann kann das halt auch eine Weile dauern, bis ich dadurch bin.

Und in der Zwischenzeit können natürlich andere Threads dann laufen und irgendwelchen Quatsch produzieren.

Und jetzt machen wir uns auf einmal Gedanken über Transaktionen oder über Transaktionsmanagement.

Und das ist natürlich auf Sprachebene was sehr Spezifisches.

Um die Frage zu beantworten, was für einen Atoman-Counter ich benutzen kann, da gibt es irgendwie Eitertools.counter oder so, heißt es, glaube ich.

Und das gilt wirklich als, also das ist die Threat-Safe-Variante, um einen Atoman-Counter in Python zu haben.

Also hätte ich jetzt nicht gewusst.

Ich auch nicht, aber wir hatten halt Bugreports, die gesagt haben, self.x geht es gleich eins, 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 Chaos of an einem Abend das einfach mal ausprobiert und es stellte sich als falsch raus, die Annahme, weil man eben sehr schnell falsche Zahlen rauskriegen kann.

Sorry, guck mal.

Ja, das ist selbstverständlich.

Okay, 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 Servung X plus gleich 1, das sind eben mehrere Bytecodes, das heißt, da kann ich dazwischen einen Thread-Switch haben und entsprechend ist das nicht atomar.

In einer der letzten Versionen, ich weiß nicht, 3.12 vielleicht oder so, haben sie quasi in C-Python die Bytecodes, wo man Thread-Switches machen kann, also in der regulären Gill-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 Counterbeispiel 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 vorhersagbaren 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.

Mach lieber gleich in der Three in der No-Gail-Version.

Ja, gut, aber damit müsste es ja gehen.

Damit müsstest du es kaputt kriegen können, ja, würde ich hoffen.

Ja, gut, ja, kaputt kriegen.

Ja, also.

Ich habe jetzt leider keine No-Gail-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.

Kannst du ein

paar UV beisen in Zeit.

Genau.

Und in PyNF.

In PyNF weiß ich nicht, aber in Ubuntu, in der, in der, in dem Dead Snake-PPA

gibt es das auch.

Ja, aber ich meine, also ehrlich gesagt, ich weiß nicht, habt ihr jetzt alles schon einen Anwendungsfall, wo ihr unbedingt das mal ausprobieren wollt, ob da nicht alles viel schneller wird?

Weil ehrlich gesagt, ich habe das dann nicht so wahnsinnig viele Dinge.

Ja, das liegt aber halt vor allem auch daran, dass wir daran gewöhnt sind, das nicht zu brauchen.

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 den Threads 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 frickelig gewesen, das dann gut hinzukriegen und jetzt nimmt man halt Threads 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 Zeugs und das ist einfach eine schwierige Sache.

Ich hab kurz, ich habe eben nachgeguckt, es gibt in PiEnv eine 3.13.0 Version und es gibt eine 3.13.0T Version.

Das ist ein Free-Threading.

Und das werden die beiden unterschiedlichen sein.

Gut, dann muss ich jetzt Boomer installieren.

Genau, und dann muss man ein altes Skript vom Chaos drauf finden.

Es war es war nicht so ein beeindruckendes Testharnes.

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.

Also jetzt, ich bin, ich habe so sehr gemischte Gefühle, was das Freethrin angeht.

Einerseits ist es halt cool, weil endlich diese endlose Diskussion aufhört auf der einen Seite.

Ja, ja, gut.

Und wenn 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 so die Tatsache, dass jetzt eben irgendwie einige Leute von Meta dafür bezahlt werden, das halt wirklich zu machen und auch quasi in C-Py 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 Free-Threading-Versionen, dann Binaries auf Pipe PI releasen und so weiter.

Und das ist schon wirklich gut.

Klar, auf der anderen Seite sehe ich, dass, 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.

Also ich habe mal so einen, ewig habe ich mal einen Vortrag gehört von einem der Sun JVM-JIT-Entwickler, der auch an dem ganzen Laufzeitsystem und dem Multithreaded Garbage Parallel 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, die zu finden.

Und ich weiß halt nicht so genau, ob wir darauf so richtig gefasst sind.

Also das

hat Python 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.

Es ist jetzt schon auf dem Tio B-Index ganz oben.

Also ich sehe es so ein bisschen, hat ein bisschen eine andere Perspektive.

Ich glaube, dass dieses die Möglichkeit, Multithading zu machen, eröffnet eine ganz neue Klasse an Programmen, die man mit Python bisher nicht schreiben konnte.

Spiele wollt man bauen.

Ja, Spiele sind eine, ja, aber da hast du dann immer noch die Performance-Differenz.

Aber gerade so verteilte Anwendungen.

Das, was Meta macht, das, was halt die großen Anbieter machen, wenn man sich mal diese Erlangen-Sachen anguckt aus den 80ern, die einfach viele Dinge gleichzeitig über einen Computer laufen lassen müssen, weil es nicht anders geht, da sieht man diese Klasse von Anwendungen.

Das ist die eine Seite.

Die andere Seite ist halt, dass die wenigsten von uns diese Klasse von Anwendungen schreiben.

So ein bisschen aus Henne- und Ei-Problemen raus.

Weil wenn wir diese Klasse von Anwendungen schreiben müssten, dann müssten wir zwangsweise bisher eine andere Sprache als Python verwendet haben, weil das in Python eben nicht ging.

Und deshalb sind wir Python-Entwickler nicht gewöhnt, diese Sorte Programme zu schreiben und auch nicht gewöhnt, diese Sorte Probleme zu lösen.

Und dass so ein bisschen diese, ja, es bedingt sich so ein bisschen selber, ja.

Das ist so ein Catch 22, der kannst du erst lösen, wenn du es gelöst hast und um es zu lösen, musst du es erst gelöst haben.

Also ich glaube wirklich, dass das nicht so super häufig ist.

Also ein Fall, den ich halt, ich habe dann irgendwann mal in den PEP auch geguckt, wo begründet wird, warum will man das eigentlich haben.

Und da war zum Beispiel ein Beispiel, was ich dann auch einleuchten fand.

Also es waren ein paar, aber eins ist mir jetzt noch in Erinnerung, die anderen nicht mehr.

Da war es halt so, dass da irgendwie auch in Data Science-Umfälterfirmen gesagt haben, wir haben ein Problem.

Und zwar haben wir hier irgendwie dicke Maschinen mit irgendwie jeder Menge GPUs drin.

Und jetzt wollen wir die GPUs mit Bildern füttern oder sonst irgendwas.

Und klar, irgendwie I.O.

ist nicht so das Problem, da haben wir kein Problem mit dem GIL, aber wir müssen die jetzt auch noch so ein bisschen transformieren.

Wir müssen irgendwie so ein bisschen das irgendwie mal irgendwie so drehen oder manchmal in Badges organisieren und keine Ahnung.

Und das machen wir halt in Python.

Und wir müssen das schnell genug machen können, um halt die ganzen GPUs ständig mit Daten versorgen zu können.

Die Dinger sind sauerteuer, wenn wir da nur die Hälfte der GPUs verwenden können, dann lohnt sich das alles nicht mehr.

Und jetzt haben wir ein Problem mit dem Gill, weil wir kriegen das nicht schnell genug, wir kriegen die GPUs nicht schnell genug mit den Daten gefüttert.

Und eigentlich haben wir fast keine Alternative, als eine andere Programmiersprache zu nehmen, weil was sollen wir machen?

Wir können es auch nicht auf Prozesse aufteilen oder das geht auch alles nicht, weil da haben wir das gleiche Problem, dass halt der Overhead uns irgendwie das zu verteilen, halt so viel Performance wegfrisst, dass wir dann die GPUs wieder nicht gefüttert kriegen.

Also, ja, was sollen wir tun?

Und da dachte ich, okay, das ist wirklich ein Anwendungsfall.

Ja, da braucht man das wahrscheinlich.

Aber ansonsten Ja,

genau, aber das ist eben diese Klasse von Problemen, die ich meinte vorhin.

Und früher waren es halt Telefonverteiler oder Netzwerkinterfaces oder.

Ja, aber da würde ich sagen, damit bist du mit ASIN geschrieben.

Ich weiß auch gar nicht, ob Erlang irgendwie das auch kann.

Ich bin mir gar nicht so sicher.

Also ich glaube, die haben dann ja, also wenn du halt irgendwie so ein Routine.

Ja, genau.

Die fahren auch eine Reihe von Prozessen hoch und haben dann halt eine schlaue Art, irgendwie, die miteinander kommunizieren kann.

Und intern machen die halt.

Und intern machen die halt, ja, aber das kannst du mit Falken ganz genauso machen.

Startst du auch mehrere Prozesse und machst in jedem einzelnen Prozess dann irgendwie Coroutinen.

Das kann man, das ist nur nicht so üblich, aber könnte man wahrscheinlich tun.

Also ich meine, ja, diese, diese, diese.

Async ist ja jetzt auch nicht gerade eine uralte Entwicklung.

Diese Probleme gibt es ja auch schon lange.

Und Async ist ja noch eine eine Version, das zu lesen.

Auch mit Vor- und Nachteilen, muss man auch sagen.

Ja.

Ja, aber das ist auch ein bisschen.

Ja, aber das ist das, was ich meine.

Es gibt eben, das ist die Sicht, die ich habe.

Vielleicht ist die auch falsch, ja, oder vielleicht ist die einfach nicht so weit verbreitet, aber meiner Meinung nach öffnet es eine Klasse von Programmen,

die vorher

nicht praktisch schreibbar waren.

Und es ist ja jetzt auch so, dass wir schon eigentlich letztlich in einer sehr pragmatischen Situation sind.

Also wir haben jetzt, das ist standardmäßig nicht an und wir gucken, wir haben jetzt Zeit als Community rauszufinden, gibt es Anwendungsfälle dafür, finden wir Anwendungsfälle dafür, wird es stabil genug?

Ist die Single-Threading-Performance akzeptabel, schlechter und ziehen die ganzen Bibliotheken mit?

Und im Moment ist das Risiko halt nicht so hoch.

Also das quasi der absolute Worst Case, der passieren könnte, ist halt, wir finden in zwei Jahren raus, niemand benutzt es, das stürzt die ganze Zeit ab und Sam Gross hat keine Lust mehr.

Und dann kann man es halt auch einfach wieder weglassen.

Also würde ich nicht von ausgehen, aber also die Möglichkeit besteht halt sozusagen.

Ja, und wahrscheinlich haben wir, also ich meine, das hat mich jetzt auch quasi, so eine andere Geschichte, diese ASIN-Geschichte hat eine gewisse Ähnlichkeit in der Hinsicht, als dass auch das halt ein tiefgreifender Eingriff war quasi und sich erst so über die Zeit entfaltet hat, was das alles für Probleme bringt und wo es überall reingreift und so.

Und das ist da, bis heute ist das noch nicht so, sagen wir so, da ist immer noch Potenzial, also es ist schon viel, viel besser geworden, aber es ist immer noch so, dass da noch, das ist noch nicht ganz komplett fertig alles.

Und das hat auch vor zehn Jahren oder so angefangen und ja, das hat ganz schön lange, ist schon ganz schön lange auf dem Weg.

Und das wird wahrscheinlich da auch so sein, ja.

Klar, auf jeden Fall.

Es ist auf jeden Fall ein langfristiges Projekt.

Das ist jetzt nichts, was wir jetzt in einer Version mal irgendwie so ein bisschen reinbasteln, dann ist das Problem gelöst.

Ja, und selbst wenn das alles auf technischer Ebene einwandfrei funktioniert, dann ist halt Multithreaded Programming immer noch einfach auch eine schwierige Sache.

Also die Dining Philosophers, die kann man sich gerne mal ansehen und versuchen, da eine Lösung zu schreiben.

Das ist nicht so einfach.

Klar.

Und also ob es dann wird.

Mal schauen, ob

Dominik fragt, was das bedeutet.

Ja, warte nur darauf, dass du es erklärt hast, ja.

Die Dining Philosophers sind ein Gedankenexperiment, wo du fünf Menschen an einem Tisch sitzen hast und die wollen Spaghetti essen und zum Spaghetti essen braucht man zwei Gabeln.

Spaghetti ist.

Very Fine Dining.

Mit zwei Gabeln.

Und auch geteilte Gabeln.

Es gibt es nur in den nobelsten Restaurants, weil jeder von denen hat nur eine Gabel.

Also bei jedem Teller liegt eine, zwischen zwei Tellern liegt immer eine Gabel.

Also ein Philosoph hat eine Gabel rechts von links und eine links von sich.

Aber auf diese Gabel haben immer zwei Menschen Zugriff.

Und jetzt wollen die alle Spaghetti essen und brauchen dafür zwei Gabeln.

Offensichtlich können die nicht alle gleichzeitig Spaghetti essen.

Weil es gibt nur fünf Gabeln, wenn jeder zwei Gabeln braucht, bräuchten sie zehn Gabeln.

Es ist also so ein Ressourcenproblem.

Das viel schlimmere Problem ist aber, dass man da ganz einfach diese ganzen Probleme visualisieren kann, die auftreten können.

Selbst wenn dieses System auf einer technischen Ebene einwandfrei funktioniert.

Also du meinst zum Beispiel, die haben alle eine große Schüsse Spaghetti und die haben gleichzeitig zwei Enden einer langen Spaghetti im Mund, weil die

das ist das Disney, die Disney-Variante, nee, die meine ich jetzt hier an der Stelle nicht, aber ja.

Zum Beispiel, wenn man ganz naiv sagt, wenn ein Philosoph Spaghetti essen möchte, dann greift er zuerst mit seiner rechten Hand nach einer Gabel und dann mit der linken Hand nach einer Gabel und wenn da eine Gabel nicht liegt, dann wartet er halt in dem Zustand, in dem er gerade ist, bis die Gabeln verfügt.

Also sitzen da irgendwelche Leute, die haben alle eine Gabel in der Hand und warten darauf, dass sie den zweiten bekommen.

Genau, also im schlimmsten Fall greift jeder nach der rechten Gabel und wartet dann auf die linke Gabel, die aber durch den Philosoph zu seiner Linken schon belegt ist.

Und die warten dann alle aufeinander und müssen für immer an diesem Tisch sitzen und verhungern, vor dem vor dem vollen Teller stellen.

Und das ist ja eine extrem simple Situation, ja.

Das ist ja eine extrem vereinfachte Situation.

Du meinst mit einer Debut, mir mal eine Gabel.

Bitte.

Ja, aber tatsächlich, Threads, die kommunizieren, sind ja auch was extrem Schwieriges, insbesondere wenn die gerade auf ein Lock warten.

Weil üblicherweise, wenn so ein Thread auf den Lock wartet, kann er ja derweil nichts anderes machen.

Das ist dann blöd.

Hat der Mund schon voll.

Genau, das ist blöd.

Und jetzt muss man eben anfangen, wie kriegt man das in den Griff?

Wie kann man das im Allgemeinen lösen, dass die keine Deadloks machen.

Mehr keine Parteien?

Ja, das wäre eine Möglichkeit, aber normalerweise ist das schwierig.

Also zum Beispiel in dem Modell von Jochen einfach mehr GPUs einbauen, ist prinzipiell eine Lösung.

Ist nicht ganz billig.

Und es sind halt goldene Gabeln, dass halt mehr Gabeln geht nicht.

Ja, es ist einfach ein Gedankenmodell, um nachzuweisen, dass auf dieser ganz simplen Ebene schon Probleme auftreten, die ungeheuer schwierig zu lösen sind und ungeheuer schwierig in ihrer Allgemeinheit zu lösen sind.

Und wenn du sagst, okay, dann habe ich eine Lösung gefunden für fünf, was ist, wenn du da sechs Philosophen sitzen hast oder tausend oder nur zwei?

Ja, geht deine Lösung dann immer noch.

Also schon allein die Tatsache, dass quasi einer der schwierigsten Probleme bei verteilten Systemen ein Counter ist, das ist ja eigentlich auch schon relativ lustig.

Eine Zahl hochzählen.

Genau, eine

Zahl hochzählen.

Aber so global, konsistent und so, das ist wirklich auch schon das ist nicht so einfach.

Kennt ihr das, wenn irgendwie an so einem Festival-Eingang irgendwer stehen muss mit so einem Klicker, man drauf drücken muss, wenn man reinrennt, oder wenn man an der anderen Hand jemand rausrennt, also ich bin mir auch so sicher, der verdrückt sich die ganze Zeit irgendwann mal an, weiß gar nicht so genau, wie viele Leute denn eigentlich auf dem Gelände sind.

Und ich weiß wahrscheinlich relativ, wenn das nicht jetzt

18 Eingänge sind und dann bieten die dann raus.

Jetzt sind gerade minus 10 Leute bei uns auf dem Festival.

Das ist doch der klassische, die klassische mathematische Mengenlehre.

Wenn drei Leute reingehen und fünf rausgehen, müssen zwei wieder reingehen, damit es leer ist.

Und der Kirchturm ist minus 30 Meter hoch.

Ja, okay, also Thading ist

eine Riesensorg.

Man kann es ja mal positiv ausrüsten.

Und die Hoffnung ist, dass es jetzt eben ganz, ganz tolle Abstraktionen geben wird, die dann auf der quasi Low-Level-Basis von Threads und Loks und was weiß ich, was es dann eben an Infrastruktur gibt oder geben wird, die das unwahrscheinlicher machen, dass wir Deadloks produzieren.

Das ist die positive Sicht.

Das wäre sehr schön.

Und das kriegen wir bestimmt hin, weil die Python-Community ist großartig und die zeigt immer wieder, was ihr für geniale Lösungen findet.

War das jetzt sarkastisch?

Nee, bleibt dran, aber das möchte ich in Folge 600 mitbrechen.

Nee, es ist schon so.

Also ich bin immer wieder überrascht.

Ich meine, wir haben ja hier in dieser Runde immer wieder den Pick, wo wir auf Sachen zeigen, die in der Python-Welt passieren oder auch außerhalb, die einfach geniale Dinge sind, die keiner wusste.

Ich mache auch gelegentlich Python-Schulungen für Anfänger.

Und eine Sache, die wir da machen, ist einfach mal durch die Standardbibliothek scrollen und gucken, was es da so alles gibt.

Und da findet man immer Sachen, die spannend sind und neu und interessant.

Und ich finde, das gehört schon auch irgendwie so ein bisschen zur Python-Welt dazu, dass es immer mehr Dinge gibt und immer viele schöne neue Sachen und neue Bibliotheken, die Dinge tun, von denen man noch nicht mal wusste, dass man sie gebraucht hat bisher.

Du wolltest gerade picken, hast du damit gesagt schon?

Noch nicht.

Vor allem, ich habe diese Woche oder dieses Mal gar keinen Python-Pick dabei, aber das macht ja nichts.

Kein Python.

Es ist einfach nur ein Hinweis darauf, dass es viele tolle Dinge gibt, die man nicht kennt.

Ja, und wenn man jetzt von der Stahlbibliothek weggeht und sich mal die Top 100 PyPI anschaut oder so, dann wird es ja nochmal irgendwie.

Also so die Bandbreite, was für verschiedene Themen es so gibt, ist schon immer wieder sehr beeindruckend.

Ja, aber das ist versehentlich total gute Überleitung, weil in der 3.13 wurden ja auch Sachen entfernt aus Python.

Und die Liste ist gar nicht so klein.

Das ist übrigens auch da wieder so ein bisschen Geschichte.

Das ist ein gefühlt jahrzehntelanges Projekt, so ein paar von diesen Sachen.

Also das wurde mal auf einem C-Python-Core-Developer-Treffen in einem Vortrag empfohlen, der damals mit sehr gemischten Reaktionen aufgenommen wurde.

Und es hat ewig gedauert, bis das jetzt wirklich passiert ist, dass da Bibliotheken jetzt entfernt wurden.

Die Motivation ist, dass es halt quasi so ein bisschen Code in der Standardbibliothek gab, der einfach sehr veraltet ist und nicht mehr so richtig für aktuelle Probleme zu benutzen ist.

Und die wurden dann eben zuerst deprecated und jetzt seit ein paar Versionen und jetzt eben wirklich wurden ein paar entfernt.

Ja, wir können

die Liste einfach mal, ich habe die Liste zufällig vor mir.

Rein zufällig.

Diese Anstrengung heißt Removing Dead Batteries.

Und die entfernt folgende Module.

AIFC, Audio Ob, Chunk, CGI, CGI TP, Crypt, Imageheader, Mailcap, MSI Lib, NIS, NETP-Lib, OSS Audio Dev, Pipes, Soundheader, SPWD, SunAU, Telnet Lib, UU, XDR Lib und Lib 223.

Understand, weil euer Paket auf einmal weg ist, dann haltet ihr auch was mit dem Update.

Genau, also wenn da jetzt was dabei war, was ihr gerne haben wollt.

Ich glaube, die landen alle auf PyPI.

Ja, ja, die gibt es noch.

Was C-Python ja nur erreichen will, ist, dass sie die nicht mehr maintainen.

Nicht, dass die jetzt verboten sind und auf gar keinen Fall mehr von irgendjemandem.

Ja, verboten.

Ja, klar, es geht nur darum, dass man die nicht die ganze Zeit mitschleifen muss, weil das ist ja auch Aufwand, die in der neuen Version mitzunehmen.

Aber bei einem Großteil dieser Bibliotheken weiß ich nicht, was die tun.

Ja, man kann so ein bisschen raten, aber bei ein paar kann man noch nicht mal raten.

Ja, bei manchen, ja, was, keine Ahnung, NNTP-Lib macht, okay, gut, das ist NNT-Lib.

CGI macht, aber was jetzt auch noch, weil wir alt sind.

Ja, da sind wir.

Aber wüsstest du jetzt den Unterschied zwischen CGI und CGI TP TP?

Ich glaube, das eine ist der Tracebank.

Ja, aber naja.

Turbo.

Turbo.

SunAU ist so ein altes Audio-Format, oder?

Ja, ich glaube auch.

Oh, MSI-Lib für Microsoft Installer-Dateien.

Ach, großartig.

Kennt ihr die meisten untergeladenen Mail auf PiPI?

Irgendwas mit Setup-Tools oder ich weiß nicht.

Okay, keine Ahnung.

Also das ist auf jeden Fall das

Richtige, diese Sachen abzusammen.

Also es gibt so eine Liste, die sagt Boto 3.

Ah, oh, das liegt, ach ja, das ist klar, warum das liegt, die updaten irgendwie alle zwei Stunden.

Und da das halt irgendwie eines der Hauptdinger ist, dass du halt brauchst, wenn du irgendwas mit AWS oder so machst.

Die drittbeste Boto Core.

Ja, ja, das ist alles so.

Und Platz 2?

Ja, besteht nicht der Grund, warum Pipei keine Statistiken mehr anzeigt.

Naja.

Und das macht natürlich.

Also da könnte man jetzt denken, das wäre irgendwie wichtig, aber das ist halt,

warum zeigen die keine Statistiken mehr an?

Weil die nicht trennen können, ob das jetzt ein Mirror ist oder ein automatisches Update oder jemand, der die Bibliothek tatsächlich in einem Projekt installieren möchte und deshalb sind diese Zahlen völlig versehen.

Ich würde sagen, weil Counter halt so schwierig sind.

Ja, genau.

Nicht nur in der

Benutzung, sondern auch in der Interpretation.

Ja, ich meine, die Zahl der Downloads ist auch irgendwie so ein bisschen weird.

1,5 Milliarden.

Die Zahl, die da rauskommt, ist halt, wie oft es geupdatet wird, ist auf jeden Fall ein Faktor, mit dem da multipliziert wird.

Und ja, ich meine, aber das ist ja jetzt nicht irgendwie eine gute Sache, wenn da irgendwie alle paar Minuten Pakete irgendwie die Version hochzählt.

Aber wenn das dann irgendwie in den CIs quasi in so Continuous Integration Pipelines verwendet wird, dann wird das halt gnadenlos noch runtergeladen, wenn sich da irgendwas ändert.

Also ja, naja.

Ja, wahrscheinlich braucht man irgendein anderes Metrik-KPI für irgendwie, ist das jetzt irgendwie interessant oder nicht?

Aber ich weiß auch nicht welche.

Mit Tabsterne.

Auch schwierig.

Metriken, KPIs.

Ja.

Es wurde schon mal in einem Podcast erwähnt.

Vielleicht sollten wir da sowas auch so eine Quartett-Serie von machen.

Ja.

Von den PyPI-Bibliotheken.

Ja, also genau, hast du ein Quartett mit vier, die die besten PyPI-Blieten oder irgendwas mit den KPIs.

Kannst du die ganzen Module da reinbauen, dann kannst du dich gegeneinander.

Kennt ihr, könnt ihr das?

Also meins hat 1,5 Milliarden Downloads in diesem Wetter.

Aha, 798 Megabyte.

Mehr Kilobyte, genau.

Und Anzahl der Releases wäre doch auch ein gutes.

Ja.

Offene Issues.

Heißt das besser, wenn es höher ist oder

wenn es.

Aber um auf die Dead Batteries zurückzukommen, also ich verstehe jetzt auch, dass es gut ist, wenn die entfernt werden.

Ja, absolut.

Aber es wird da sicherlich die Leute geben, die sagen, nein, wie soll ich sonst je meine?

Ja, aber die hätten ja jetzt auch schon.

Ja, aber die hatten ja jetzt auch schon eine ganze Zeit, lang Zeit irgendwie da was und ich glaube auch nicht mehr so über den.

Ja, genau.

Da ist auch nichts sonst passiert.

Ja, ich weiß nicht, haben wir vielleicht nur so kleinere Dinge oder ich weiß es nicht genau.

Gab es noch irgendwas Interessantes?

Typing immer, ja.

Ein Typing Simple Namespace, wolltest du sagen?

Das kannte ich noch gar nicht.

Ich weiß gar nicht, auf welcher Version das war.

Ja, du kannst es auch nicht.

Okay.

Ja, ich kann es auch nicht.

Typing, Simple Namespace ist ein Dikt, dass man wie Attribute dann die Keys benutzen kann.

So ein bisschen so ein Nametuppe.

Und da hat CF gesagt, oh, das ist aber ganz schwierig, weil da ständig irgendwas kaputt geht.

Und hat dann auch Enum in den Raum geworfen.

Das würde ich gerne nochmal kurz hören und verstehen, warum das so blöd ist.

Ich habe es auch schon gesagt, dass ich das zensieren will.

Nee, wir haben so ein bisschen darüber geredet, welche Standardbibliotheks Module uns als Piper-Entwicklern irgendwie besonders oft Probleme bereiten.

Und Inam ist da immer mal wieder so ein, wie heißt es?

Eine eierlegende Wollmilchsau.

Problembär.

Also INAM benutzt einfach ganz, ganz viele Tricks des Python-Datenmodells und Metaklassen und irgendwie schafft es immer wieder Randfälle zu erwischen, die wir dann doch nicht so ganz korrekt implementiert haben und da müssen wir erstmal, wenn wir, was weiß ich, zu einer neuen C-Python-Version die Standardbibliothek dann übernehmen, müssen wir erstmal irgendwelche Python-Datenmodell-Core-Features fixen, bevor ihr dann halt auch nur importiert oder so.

Genau.

Und Nametuple ist da auch ein Problem, nicht so richtig, weil das irgendwie einen Bugs hat, sondern weil das oft Performance-Bugs hat.

Name Tupeln langsam, das war mir auch neu.

Ja, Nametuple benutzt halt quasi, wenn man so einen neuen Nametuple-Typ anlegt, dann wird halt auch mit Exec dann irgendwie, so mit Strings, irgendwelche Python-Code generiert und das mag Dagit halt nicht.

Weil der Jit, der geht halt davon aus, dass ich die gleichen Funktionen oft aufrufe und nicht ganz, ganz viele neue Funktionen ständig mache, die dann eben neu zum Maschinencode übersetzt werden müssen.

Und das sorgt eben dafür, dass bei Nametuple die Performance oft wirklich sehr, sehr schlecht war in Pipe.

Und inzwischen ist das gefixt, aber so über so ein paar Versionen hatten wir mit Nametuple immer mal wieder Probleme.

Mit Data Classes am Anfang übrigens auch, aber es ist inzwischen auch, glaube ich, ganz gut repariert.

Aber das sind auf jeden Fall so ein paar, also es gibt Bibliotheken, die wir einfach eins zu eins übernehmen können, gerade wenn die in Python geschrieben sind, ist überhaupt kein Problem.

Und es gibt welche, wo wir halt dann eben sehr, sehr viele Piper-spezifische Patches haben.

Und Nametuple ist definitiv eins von denen, wo es eher mehr als weniger Patches gibt.

Das habe ich jetzt geschafft, ohne jemanden zu beleidigen.

Genau.

Ja, Typing waren auch noch so ein paar Dinge.

Nicht so der Typ-User, ja.

Die Features sind schon viel zu advanced für mich.

Ups.

Ja, aber ich weiß nicht.

Das ist auch read-only, ja, okay.

Hast du das gerade vor dir?

Kannst du das?

Ja, die

Beschreibung ist sehr kurz, aber es geht wohl darum, dass man Locals bearbeiten kann.

Und das war bisher nicht so genau definiert, was da passiert.

Und jetzt kann man das machen.

Also vorher.

Ist nur für Debugger wichtig.

Hier steht, ist für Debugger wichtig.

Ich glaube, der Trick ist, also das Wichtige daran ist wirklich, dass jetzt einfach mal genau aufgeschrieben wurde, was genau passiert, wenn man Locals aufruft.

Was können sie erwarten?

Was können Sie erwarten?

Und manchmal ist es eben so, dass das Dictionary, was Locals, also bei Globals ist ja so, das Dictionary, wenn ich da Keys reinschreibe, dann, das ist das wirklich das richtige Globals Dictionary.

Und dann, wenn ich danach das entsprechende Global nachschaue, dann sehe ich auch die Änderung.

Und bei Locals halt.

Und das macht sehr schöne, sehr schöne Tricks ermöglichen.

Das macht sehr schöne Tricks möglich.

Bei Locals ist es nicht so.

Bei Locals war es eben manchmal so, dass wenn ich Locals verändere, dass sich dann sich die Locals wirklich ändern und manchmal eben halt auch nicht.

Und genau in welchen Fällen welche Variante dann galt, das war so ein bisschen immer ein bisschen schwierig vorherzusehen und verschiedene Python-Versionen haben das auch irgendwie, äh, nee, verschiedene Python-Implementierungen haben das auch verschieden dann angegangen.

Also quasi zwischen Funktionen, Global Scopes, Generatoren, Coroutinen, Comprehensions, Glass Scope, also es gibt da da schon so einiges, achso, Code, der von Exec oder EWAL ausgeführt wird, da gab es eben schon so einiges an Fällen, wo es halt dann so immer so leicht unterschiedliches Verhalten gab.

Das wurde jetzt eben fest definiert und ich glaube, es ist so, dass Locals weniger oft, also dass man Mutationen bei Locals weniger oft zu Veränderungen in den echten Locals führen.

Aber auf der anderen Seite ist es eben so, dass in den Debuggern, wenn man da sich so ein Frame-Objekt geben lässt und da das Attribut f-Locals mutiert, dass das eben zu vorhersagbaren Veränderungen an den echten Werten der Locals führt.

Und das im Debugger ist eben wichtig, wenn ich im Debugger dann sagen möchte, ich führe jetzt die Funktion aus und die lokale Variable A hat den Wert 17.

Ich will jetzt aber einfach mal im Debugger, um rauszufinden, was da genau passiert, das auf 19 setzen.

Und wenn das dann nicht geht, weil eben das Verändern der Locals im Debugger nicht so richtig implementiert ist oder nicht immer geht oder nicht in Generatoren geht, ist es halt so ein bisschen frustrierend.

Und da ist es eben gut, wenn man jetzt ein klar definiertes Verhalten hat, auf das man sich verlassen kann.

Ja, und die vielen Debugger-Autoren unter unseren Zuhörern haben sich gerade eben sehr gefreut.

Naja, also die Debugger-Autoren sind ja einen, aber die Leute, die halt den Debugger dann benutzen, zu denen gehören wir ja dann doch meistens die Frage.

Leider auch doch tatsächlich.

Einfach Print-Debugging.

Wir alle, die noch nicht sofort beim ersten Mal perfekten Code schreiben können, die

Print-Debugging mehr braucht keinen Menschen.

Kennt ihr diese, diese, das kann ich auch noch nicht, aber ich fand diese Analogie sehr schön.

Das, ähm, ich glaube auch aus der letzten Copy-Episode, wo jemand meint hat, ja, so Print, da gab es wohl irgendeinen Vortrag vor langer Zeit, wo jemand gesagt hat, na, also sei kein, sei kein Bond-Vilaine beim Debuggen, zum Beispiel.

Also Bond-Wilain ist lieber alle.

Die machen, ja, die machen aber alle irgendwie blöde Fehler, dass sie zum Beispiel irgendwie verständlich erklären, was ihr Plan ist oder dass sie halt nicht irgendwie mit der großen Weltraumlaserkanone schießen, sondern mit einer kleinen Pistole irgendwie sich eine Schießerei mit Bond liefern und das ist halt eine dumme Idee, weil da ist er halt einfach besser drin und das hätte lieber den Weltraumlaser nehmen sollen.

Und die Idee ist sozusagen, wenn du lieberst, nimm den Weltraumlaser direkt.

Fang nicht irgendwie an mit Printf mit der blöden kleinen Pistole, sondern nimm das mächtigste Tool, was du irgendwie hast, weil das ist doch Zeitverschwendung.

Wenn du irgendwie zuerst mit Printf anfängst, dann nimmst das nächste, das geht auch nicht, dann nimmst du das nächste.

Wir fangen lieber gleich mit dem großen Ding an.

Dem großen Hammer nehmen und draufhauen.

Du kannst nicht dein alle Erzählungen

wegnehmen mit dem Weltraumlaser.

Ja, aber also ich, die Idee fand ich schon, ja, hatte was.

Also muss man, ja.

Aber da gibt es auch einfach sehr, das ist einfach sehr individuell.

Also ich kenne auch Leute, die leben nur im Debugger.

Also da ist halt einfach der erste Schritt, ich mache eine Funktion, die ist leer und habe die Argumente reingereicht und dann schreibe ich halt, mache ich erstmal einen Debugger an.

Gucke halt, was für Argumente finden das jetzt hier und wie müsste denn der Code aussehen, dann schreibe ich zwei Zeilen mehr und mache wieder einen Debugger rein.

Also ich ja, also in manchen Sprachen ist es ja auch noch viel mehr so, dass man das dann auch, dass du die IDI das auch unterstützt und man dann quasi die Funktion restarten kann an der Stelle, wo man halt gerade war, dann schreibt man ein bisschen mehr Code, restarte die wieder.

Also die Smarthock-Leute machen das besonders gern, die, die es noch gibt.

Aber ja, also ich kenne auf jeden Fall auch in Python-Leute, die halt sich das so angewöhnt haben, dass sie halt im Test schreiben, die Bagger anmachen und dann kann man halt erstmal so gucken, was hat man denn eigentlich für Objekte, was haben die für Methoden und wie, ja, was macht man denn da eigentlich?

NBDF so ein bisschen so.

Ich habe auch versucht mal einen zu überzeugen von Jupyter-Notebooks und so, habe ich begeistert davon erzählt.

Nee, benutze ich nie, finde ich blöd.

Und dann so, ja, und dann habe ich gesehen, wie der entwickelt.

Und der tatsächlich hat quasi das, was ich in Jupyter-Notebooks mache, macht der im Debugger.

Ja, das kann man tun, das geht schon.

Aber es ist halt okay.

Wenn man jetzt noch einen Debugger hätte, der vorwärts und rückwärts steppen kann und wo man zwischendurch den Code verarbeiten

würde, dann schon.

Aber ich glaube, PDB ist eine der Sachen, wo ich das Gefühl habe, dass das auch so ein bisschen revitalisiert ist.

Also dass es da jetzt Core Lefts gibt, die sich dafür interessieren und eben hoffen, da in den nächsten Versionen auch ein paar neue Features reinzukriegen.

Ich glaube auch in 3.13 ist schon die ersten Version.

Zum Beispiel, dass wenn man so ein Breakpoint macht, dass dann dass man dann nicht erst in der nächsten Zeile dann wirklich anhält im Debugger, sondern schon in der Zeile selber, wo der Breakpoint ist.

Ah ja, genau, genau.

Ja, da war auch irgendwie so eine Seltsamkeit, dass wenn man das vor einem Return gemacht hat, dass man dann halt irgendwie

im Caller erst den Breakpoint geblieben hat.

Ja, also da sind schon einige Dinge hier, ja.

Um jetzt meinen Einwurf noch kurz zu retten, das war eine Präsentation von einem Spieleentwickler, die sich selber so ein System gebaut haben.

Jochen, du hattest die, glaube ich,

Tomorrow Corporation.

Das war eine super, dass wir das gemacht haben.

Die haben sich genau so eine Debugger gebaut, der vorwärts und rückwärts steppen kann und wo ich zwischendurch Code verändern kann und dann trotzdem die Auswirkungen alle sehe.

Und das war schon sehr beeindruckend, weil das halt tatsächlich so ein Debugging ermöglicht, am offenen Herzen, ohne Angst haben zu müssen, dass der Patient jetzt abstürzt.

Das ist schon sehr beeindruckend.

Ja, und es war auch noch irgendwie da, dass es ein Spiel ist.

Man hat halt unten quasi beim Debugger so ein Schieber und das Spiel geht halt mit.

Und man schiebt ihn so da und das Spiel läuft rückwärts.

Und man sagt er so ganz trocken so zu, ja, das sind jetzt nicht irgendwie Screenshots oder so.

Nee, das ist das echtes Spiel, was wirklich irgendwie neu gerendert, wenn man dann diesen Titel ist.

Ich bleibe hier mal die Funktion ein kleines bisschen um und lasse

das mal wieder laufen von hier aus.

Und jetzt ist auch dieser Fitness.

Ja, kann ich auch in den Shownotes mal verlängen.

Aber das, also ich hatte, ich glaube, die Free-Threading-Leute, die müssen solche Tools auch benutzen, weil es ansonsten einfach echt so schwierig ist.

Und da gibt es halt auch für C so Back-in-Time-Debugger, der, wie heißt er nochmal?

Anfang des Jahres war ich zum ersten Mal in der Situation, dass ich mich genötigt gesehen habe, auch so einen zu benutzen, weil wir so einen nur sehr selten stattfindenden Garbage Collector Bug hatten.

Und mit so einem Back-in-Time-Debugger kann man halt dann solche Probleme auch richtig gut lösen.

Also weil da kann man dann, also das ist quasi so ein Tracing-Debugger, der macht so eine Aufzeichnung der gesamten Prozesausführung.

Das kann man einfach hundertmal machen, bis der Crash stattfindet.

Und dann kann man sich die Ausführung beliebig oft wieder anschauen.

Und das Interface ist quasi so wie so ein normaler Debugger.

Ich kann halt Next machen und Sachen printen.

Aber der Prozess wird nicht wirklich neu ausgeführt, sondern das ist quasi in nur ein Replay von dem, was eben bei der crashenden Ausführung wirklich passiert ist.

Und da kann ich, also da kann ich dann wirklich auch einen Backword-Next machen und dann bin ich wieder eine Zeile davor.

Oder ein Backwards Finish und dann bin ich eben am Anfang der Funktion nicht gerade ausführend.

Oder halt auch so Sachen wie, ich mache einen Hardware Watchpoint, also das war wirklich Memory Corruption, die ich da debuggt habe.

Und wenn du halt einen kaputten Speicher hast, dann kannst du dir so einen Watchpoint setzen, wo du sagst, wer hat als wer hat diesen Speicher, also wenn dieser Speicher verändert wird, dann halt an.

Und dann kann man quasi vom Crash sagen, man macht so einen Watchpoint für den kaputten Speicher und dann lässt man rückwärts laufen.

Weil dann findet man quasi, wenn man rückwärts läuft, findet man den Code, der den Speicher wirklich kaputt geschrieben hat.

Und das war wirklich richtig gut.

Aber das war wirklich auch.

Es funktioniert übrigens auch nicht, also technisch ist das nicht so implementiert, dass es wirklich rückwärts läuft.

Weil es ist ja Maschinencode, es geht für beliebigen Code.

Stattdessen macht er nur Snapshots.

Der geht dann zum letzten Snapshot und läuft von da vorwärts.

Aber es fühlt sich halt trotzdem so an.

Gut genug.

Okay, okay, ich habe hier noch den wichtigsten.

Ich habe ja noch den wichtigsten, die wichtigste Änderung in Python 3.13.

Bei Doc Strings werden jetzt die führenden Leerzeichen entfernt.

Oh ja, es hat mir auch krass davon.

Das hatten wir uns schon angeguckt im REPL tatsächlich.

Wie viel Prozent bei Kurz ist weniger?

Oder der Byte?

5%.

8% weniger.

Bei SQL.

Aber also einfach weil es korrekt ist, oder?

Wir brauchen

niemals den Doc-String mit der Einrückung.

Naja, 5% finde ich ganz schön krass.

Also 5% sind Leerzeichen von eingerückten Docstrings in unseren PYC-Dateien.

Das ist irgendwie würde man jetzt erstmal so nicht erwarten.

Green Development danach.

Green Development.

Das liegt halt daran, dass wir alle so viele gute und ausführliche Dog-Strings schreiben und ganz viel.

Nee, vor allen Dingen aus Leerzeichen bestehen.

Ja, ich weiß nicht.

Jochen schreibt keine Docstrings.

Naja gut, wenn ich halt Klassen habe, bei mir ist Methoden-Doc-Strings, dann sind die ja schon immer acht Bytes eingerückt für Teile Doc-Strings.

Ja, richtig.

Und das müssten ja eigentlich 10% sein, weil wir gehen ja nur bis 80 Zeichen pro Teil.

Das ist nicht 79?

Ja, streng genommen müssen es 79 ist.

Ja, oder okay.

Ja, 79, 79.

Was habt ihr denn für moderne Displays?

80 mal 25, so?

Wenn du Pipe-Modus auf deinem Papierrecht schreibst.

Es gibt Leute, die müssen auf eurem Handy entwickeln.

Ich habe PyPy auf meinem Handy.

Okay, wie geht das

denn hin?

Ja, in PyPy ist tatsächlich ein Paket auf Thermux.

Also Thermux.

PyPy hat eine ARM-Version und dann kann man das einfach laufen lassen.

Manchmal ist es auch nett, dann kann ich in der Bahn irgendwie.

Das ist halt so ein bisschen nervig zu tippen, aber man kann auch den JIT laufen lassen, man kann sich dann auch auf dem Handy anzeigen lassen, welchen Maschinencode der PyPy-JIT jetzt gerade auf den Python-Code, den man auf dem Handy laufen ließ, erzeugt wurde.

Also, wenn man die richtigen Umgebungsvariablen weiß.

Aber Thermox kann das leider noch nicht, dass man mit dem Daumen hoch und runter machen kann mit dem interaktiven Neuen.

Nein, nein, aber das ist das Scrolling und ich mal jetzt durch die einzelnen Zeilen durch vom Editor, vom History Edit.

Ich glaube, achso, du meinst so in der Konsole?

Nee, habe ich nicht.

Schade.

Da habe ich also jedenfalls zu dem Thermox, habe ich auch eine, weiß ich, wie lustig die für andere ist.

Ich fand die lustig.

Ist mir was auf einer Konferenz im Sommer passiert?

Ich war auf so einer akademischen Programmiersprachenkonferenz mit Forschern und Forscherinnen, die sich mit Compilern und Optimierungen und Programmiersprachen und so auseinandersetzten.

Und da war ich dann mit einem relativ bekannten C-Compiler, Prof, John Reggae heißt der, auf so einem Boot in Kopenhagen Bier trinken.

Also das Burg lag am Hafen, man konnte auf Deck Bier trinken und habe ihm dann auf dem Handy so eine Optimierung gezeigt, die wir in PyPy machen.

Und er hat also mit PyPy noch nie irgendwas zu tun gehabt und schaut sich das an, so in ganz, ganz kleinem Font und meinte so, warum ist denn da diese extra Operation?

Die brauchst du doch gar nicht.

Und das war absolut richtig.

Und der Grund war, dass die Division in C und in Python halt sich unterschiedlich verhalten, wenn die Zahlen negativ sind.

Und dafür braucht man halt in Python so ein extra XOR.

Aber die Tatsache, dass er das quasi so mit dem 8-Punkt-Font über einem Bier, so auf dem Handy, mal eben so gesehen hat, quasi in einem ASCII-Format, was er noch nie gesehen hatte, das fand ich dann doch relativ krass.

Tja, so Leute gibt's.

Ich würde sogar fast sagen, das ist fast der Schluss von Thema.

Ja, ich glaube, wir sind mit dem Thema eigentlich mehr oder weniger durch.

Dann können wir eigentlich nochmal zu einem welchen Teil wechseln.

Wir konnten zum Beispiel ein bisschen Metageschichten machen.

Metageschichten, Mietergeschichten.

Ja, zum Beispiel hatten wir Anfragen nach.

Ach, das also eins als Metageschichten.

Ja, also wie sieht das eigentlich aus?

Wollt ihr nicht mal ein Hörertreffen machen?

Ja, wollen wir das?

Und genau, das hängt, würde ich meinen, davon ab, ob es Hörer gibt, die das auch gerne machen wollen würden, weil ansonsten sitzen wir da alleine rum irgendwo.

Das wäre ja auch irgendwie.

Also ich würde einfach mal eine Idee, jetzt können wir das natürlich auch machen, aber wenn, wenn, sagen wir mal so, man kann einfach eine Mail an hallo.podcast.de schreiben zum Beispiel, und wenn da jetzt fünf Mails kommen, dass man sich irgendwo Köln, Düsseldorfer Raum oder so treffen wollen würde, dann machen wir das einfach mal.

Genau.

Und genau, das ist eine Geschichte.

Dann gab es eine Nachfrage nach wie viel.

Ah, ich würde das gerne noch erweitern.

Also falls da fünf Mails kommen, die sich im Stuttgarter

raus treffen wollen.

Genau, dann.

Oh, oh ne, vielleicht müssen wir uns in der Mitte treffen, irgendwo in Frankfurt oder so.

Ah, in Frankfurt, nee.

Das ist Bimodal, oder?

Das ist Düsseldorf oder Stuttgart

und dann kann man das hin.

Alles klar, Frankfurt, da müssen halt Marburg dazu.

Da, wo sich mehr melden, da müssen wir dann hin.

Da ist zuerst.

Aha.

Da ist zuerst.

Okay, mal schauen.

Ich bin mal gespannt, ob sich da jemand meldet.

Das ist das könnten wir machen.

Genau.

Ja, dann hat sich immer noch ein.

T-Shirts machen, Jochen.

T-Shirts.

Ja, ja, könnten wir einfach machen.

Hat sich da gerade jemand freiwillig gemacht?

Müssen wir mal schauen.

Genau, eine andere Anfrage war von jemandem, der irgendwie altere Episoden durchhört, dass wir wohl irgendwann mal gesagt haben, oh, wir machen mal einen Discord-Server oder so.

Und dann kam die Frage, haben wir das denn mal gemacht dann?

Ja.

Und die Antwort ist ja.

Aber wir haben nie drüber geredet und vielleicht machen wir das jetzt auch mal und packen einen Link zu dem Discord-Server einfach irgendwie auch in die Shownotes oder so.

Und da kann man auch einfach dann mal drauf gucken, weil tatsächlich haben wir das.

Und ja, wir haben das aber nie kommuniziert, dass wir das haben.

Daher ist er auch wenig los.

Genau.

Wie ist eigentlich mit den tollen Transkripten von unserem Podcast, lieber Johan?

Ja, da habe ich jetzt am Wochenende gab es den PiDDF-Farbsprint und da habe ich angefangen, mich mal damit zu beschäftigen, weil ich dachte so, also ich meine, klar, dass man da kann man nicht, also in zwei Tagen kriege ich das nicht hin, aber ich habe zumindest angefangen und man kann jetzt auch, wenn man im Webplayer auf, da ist so ein zusätzlicher Button bei den Episoden, wo es Transkripte gibt.

Also falls ihr Taubzeiten uns trotzdem hören wollt, könnt ihr uns jetzt auch also lesen.

Ja, genau.

Das sieht aus wie so ein Dokumente-Icon.

Wenn man da drauf drückt, dann erscheint da irgendwie so ein Transkript-Tab drunter.

Und das läuft auch mit, wenn man dann den Player mit dem Player das abspielt.

Und das geht schon.

Aber das ist nur ein Teil von den Sachen, die man implementieren muss, wenn man Transkripte haben will.

Da kommen noch diverse andere Geschichten dazu, mit denen ich noch nicht fertig bin.

Aber das geht auf jeden Fall.

Dabei ist mir dann auch eine Geschichte aufgefallen, die halt blöd ist.

Ich dachte, ah, das ist voll super, wir haben ja auch die Spuren noch.

Das heißt, die Sprechererkennung brauchen wir gar nicht in einem Machine Learning-Modell machen, sondern das weiß man ja schon.

Ich hau einfach die Spuren getrennt durch Whisper durch oder so.

Und dann kann ich auch sagen, wer das gesagt hat.

Und dann habe ich gesagt, die Original-Dohen Spuren vor Auphonic sind halt von den Zeiten her anders, als das, was nachher rausfällt, weil halt manchmal Stille rausgeschnitten wird oder manchmal wird das halt also ein bisschen transformiert und dann passen die ganzen Zeitstempel nicht mehr.

Die haben die nicht aufgehoben, die eins.

Und ich habe die, ja, man kriegt von der Auphonic kriegt man auch die einzelnen Spuren zurück.

Nach dem Mastering sozusagen, aber die habe ich nicht aufgehoben und die werden nach irgendwie zwei Wochen oder 20 Tagen irgendwie gelöscht.

Das heißt, ich muss entweder alles nochmal durch Auphonic schieben.

Oh no.

Oder irgendwie, es gibt für die alten Folgen dann halt jetzt nur die Transkripte ohne Namen dran.

Vielleicht ist das auch schon okay.

Genau.

Und dann für die zukünftige mache ich das dann halt so, dass man dann auch die Namen an den Sprechern hat.

Ja, aber es gibt Transkripte, da tut sich was, das kommt jetzt.

Wir hatten das ja irgendwann schon mal so ein bisschen probiert, das war relativ wächterlich, aber so ist eigentlich relativ cool.

Ja.

Genau.

Ja, wir wollten auch picken, oder?

Picken wir nicht immer?

Genau.

Picks, genau, genau, genau.

Ich muss ja wieder irgendwas völlig Triviales picken, dann fange ich mal damit an, weil ich ja immer irgendwas anderes denke.

Und wieder hat nichts mit unserer Folge zu tun, aber ich habe ab und zu mehr Geld bezahlt tatsächlich irgendwie für ordentliche Freistellung von Bildern.

Keine Ahnung mehr warum, aber das war schon ein bisschen länger her.

Es gibt ein tolles Paket, das ich entdeckt, das heißt RAM BG oder sowas.

Das macht einfach den Background weg als Kommandozeilentool von irgendwelchen Bildern.

Wenn man das will.

Super praktisch.

Falls man sowas braucht.

Das war's.

Jetzt auf die vernünftige Sachen.

Ich mach mal weiter mit den unvernünftigen Sachen, die auch überhaupt nichts mit der Episode zu tun haben, aber mit der Zeit, in der wir leben.

Und zwar ist kürzlich die neueste größte Primzahl gefunden worden.

Ah, ja.

Das ist eine Mersenne-Primzahl, die heißt M136279841.

Also 2 hoch 136.279.841 minus 1, ist eine Primzahl.

Waren sehr viele GPUs beteiligt an der Überprüfung und das ist die erste seit 28 Jahren.

Die erste große Primzahl nach 28 Jahren.

Diese Primzahl hat 41.24.320 Stellen.

Und das allein ist schon eine schöne Sache.

Aber das Schöne, was ich gefunden habe, was heute mein Pick ist, ist eine Initiative, die versucht, diese Zahl zu sagen, bevor die nächste größte Primzahl gefunden wird.

Und zwar als verteilter Prozess.

Da gibt es eine Webseite, die heißt sayheprime.com.

Da kann man sich 419 Stellen geben lassen.

Die nimmt man dann als Video auf, lädt das Ganze auf YouTube hoch, schickt den Link ein und die machen dann eine ganz, ganz, ganz, ganz, ganz große Playlist draus, die hoffentlich diese Primzahl insgesamt sagt.

Und das Ziel dieser Initiative ist es, diese Primzahl einmal zu sagen, bevor die nächste größere Primzahl gefunden wird.

Wahrscheinlich kann man sie einfach mit selber multiplizieren und nochmal wieder eins abziehen, da hat man das schon.

Ja, diese Zahlen zu rechnen, ist nicht so schwierig, aber das beweisen, dass es eine Primzahl ist.

Was ist die Schätzung, wie lang diese Playlist, wie viele Jahre die es machen?

Ja, gut.

Wie lange braucht man eine Tat?

Sie sagen vor, dass man ungefähr 120 mit 120 ppm spricht.

Das heißt, es wären zwei Ziffern pro Sekunde.

Oh, da bin ich nicht runtergehen.

Das heißt, es wären ungefähr 20 Millionen Sekunden.

Das ist gar nicht so viel.

20 Millionen Sekunden, eine Millionen Sekunden ist ungefähr eine Woche oder so.

Jetzt müssen wir es mal ausrechnen, wie viel das tatsächlich.

Ja, warte mal, das sind 41 Millionen Sekunden.

Achso, dann

sind 230 Tage.

Tja.

243 Tage, ja.

Dreivierteljahr.

Tja.

Darum geht es ja gar nicht.

Es geht gar nicht darum, dass es jemand sich dann anhört, sondern es geht darum, dass es einmal gesagt würde.

Wir können ja jedes Mal jetzt an einer Episode so eine kleine Episode von dieser Primzahl mit.

Einfach im Hintergrund laufen.

Jeder, wer möchte, kann daran teilnehmen.

Es gibt ein sehr schönes Video von Matt Parker, wo er die Zahl einmal anzeigt in seinem Video.

Also er hat dann in jedem Frame zeigt er, glaube ich, 1000 Ziffern an und das geht dann eben über so und so viele Sekunden.

Oder vielleicht zeigt er 10.000 Ziffern an jedem Frame.

Auf jeden Fall irgendwie dreieinhalb Minuten lang zeigt er diese Zahl an und spricht über die Zahl.

Und das ist quasi das Audio-Äquivalent und jeder kann damit mithelfen und ich finde, jeder von uns sollte das tun.

Das ist mein Pick für diese Woche.

Saytheprime.com.

Ich habe tatsächlich auch über die Friebzahl nachgedacht, weil es ist nämlich relativ, ich finde es relativ lustig, dass man die in Python problemlos ausrechnen kann.

Also es ist überhaupt kein Problem, einfach mal zwei hoch 136 Millionen zu rechnen.

Das dauert quasi keine bemerkbare Zeit.

Das sind da so 16 Megabyte Zahl ungefähr.

Vielleicht ein bisschen ineffizienter dargestellt, aber ja, aber die zu printen, ist komplett unmöglich.

Weil also im Zweier-System ist es halt eine sehr einfache Zahl, es sind lauter Einsen.

Aber im 10er-System, das 10er-System umzuwandeln, das ist halt nicht linear zu machen, sondern das ist irgendwie N-log N oder so.

Und ja, das, also es ist ja eh inzwischen standardmäßig so, dass man große Zahlen nicht mehr printen kann.

Standardmäßig gibt es dieses Limit.

Das war auch ein Security-Problem, also ein Deni-of-Service-Problem.

Aber selbst wenn man das Feature ausschaltet, dann dauert es halt einfach zu lang.

Also das.

Zum Glück kann man die Zahl runterladen.

Gibt es auf mersen.org gibt es eine ZIP-Datei 18 Megabyte.

Falls man die braucht für irgendwas.

Kann man den Leuten statt X schicken, statt den X-Sourcen.

Gut, das ist mein völlig unkorrelierter Pick, aber es passt irgendwie in unsere Zeit rein.

Und das ist alles relativ neu.

Also es ist vom 21.

Oktober, als die Bestätigung kam.

Ja, oder CF, ich meine, keine Ahnung.

Ja, ich würde ja ungern die Reihenfolge an völlig absolut nichts mit dem Thema zu tun haben, den Picks unterbrechen.

Daher habe ich auch einen, der gar nichts mit dem eigentlichen Thema jetzt dieser Episode zu tun hat oder auch nicht mit Python oder sonst irgendwas.

Und zwar, ich war jetzt letztens auf so einer Podcaster-Konferenz auf der Subscribe-Ilf in Berlin.

Die Subscribe 10 ist übrigens schon vier Jahre her

oder so.

Fünf, die waren 2019.

Ja, okay, fünf.

Da waren wir auch und dann dachten wir, ja, da gehen wir zur nächsten auch und dann nichts war jetzt gerade fünf Jahre später.

Da war so zwischendurch irgendwie waren da so leichte Pandemieschwankungen irgendwie am Start und das hat halt.

Vor der Pandemie irgendwie schon egal.

Es war auch kleiner, als also es waren deutlich weniger Leute da als jetzt vor fünf Jahren und das lag vor allen Dingen daran, dass inzwischen so Infrastruktur auch weggebrochen ist, die vorher ganz gut funktioniert hatte, nämlich Social Media.

Also das war so ein Ding, alle, die man traf, ja, also klar, früher konnte man sowas, aber heute geht das ja nicht mehr, weil Social Media ist ja tot, da kann man das nicht mehr machen.

Also man kann zum Beispiel für so eine Konferenz auch nicht mehr gut Werbung machen, weil man kann den Leuten nicht mehr davon erzählen, weil, ja, wo will man es den Leuten denn noch erzählen?

Es gibt ja irgendwie nichts mehr.

Und dann war halt so die Frage, okay, was kann man denn jetzt tun, wenn es das nicht mehr gibt?

Und da war eine der Antworten halt, ah, naja, wir haben ja doch irgendwie ein Medium gerade so, wir haben da, baden da gerade unsere Hände sozusagen drin.

Warum sagen wir nicht irgendwie in unseren Podcasts quasi, dass es solche Sachen gibt?

Und dann war auch die Idee, dass man da so ein bisschen Werbematerial oder so schon mal fertig macht, dass man das eigentlich direkt verwenden kann, das ist dann noch nicht passiert, aber ich dachte, das kann ich jetzt mal nutzen, um das zu sagen, dass es sowas gibt.

Und wenn man irgendwie da Interesse dran hat, kann man da auch hingehen.

Da auch als Hörer, da waren zum Beispiel.

Du meinst in der nächsten fünf Jahren?

Nee, die nächste ist schon in einem halben Jahr.

Die Frequenz so ein bisschen erhöhen und die nächste ist daher schon im Frühjahr, nächsten Jahres.

Und es gab am Anfang so eine Vorstellungsrunde, wo alle gesagt haben, was sie so tun.

Und da waren tatsächlich ein paar Leute dabei.

Eine, eine Person hier auch aus Düsseldorf, die bezeichnet sich als Extremhörerin.

Also es waren auch viele Hörer da.

Es war sehr schön.

Schöne Veranstaltung und weißt du, wo die nächste ist?

Auch Berlin.

Ah, okay.

Gleicher Location, also Weißen See.

Und im Mai.

Vielen Stunden ist man Extremhörerin.

Pro Tag?

Ja, viele, viele pro Tag.

20 oder so.

Und sie meinte, ich war mit dir dann auf einem Hörertreffen am Samstagabend von einem anderen Podcast.

Und da ist halt so, ja, also ja, es ist immer schwer zu sagen, wie viele Stunden Podcast ich denn jetzt so höre, weil ich höre immer auf irgendwie so zweieinhalbfache Geschwindigkeit, worauf alle am Tisch so zweieinhalbfach.

Da muss man sich langsam rantasten.

Da fängt man nicht mit an.

Man fängt zuerst an mit so 1,2 und dann 1,5 und dann geht das immer langsamer.

Ja, jetzt 1,5 ist schon.

Ja, aber inzwischen kann ich das halt auch gar nicht mehr auf einfache Geschwindigkeit hören, weil da denke ich mir so, was ist.

Ja, bei meisten kostet das mir auch nicht, das geht nicht.

Ich finde es ja total lustig.

Also man gewöhnt sich hatte wirklich total dran.

Also ich bin nicht so extrem, ich höre vielleicht 1,2 oder 1,5 oder so.

Und an das Sprechen gewöhnt man sich total.

Aber wenn man so eine Zeit lang irgendwas mit normaler Geschwindigkeit und dann erhöht gehört hat, die Jingle klingt immer falsch.

Also selbst Jahre, ich höre jetzt, was weiß ich, wie heißt der Microsoft C-Sharp-Typ?

Hunzel Minutes.

Höre ich seit Jahren, 20% schneller, die Jingle klingt immer noch falsch.

Ja, es gibt

gute Jingles, die hören sich auf unterschiedlichen Geschwindigkeiten ähnlich interessant an.

Ich habe einen Python-Pick.

Es gab eine super kleine Studie von Erit Katril, das ist eine C-Python Core-Entwicklerin, die eine Studie darüber gemacht hat, wie viele PyPI-Pakete Return, Break- oder Continue-Anweisungen in Finally-Blöcken machen.

Weil es gab nämlich so eine kleine Diskussion darüber, ob man vielleicht, also Accept-Doppelpunkt, also ohne Angabe eines Exception-Typ abschaffen sollte, irgendwann in einer der nächsten Versionen.

Da gab es total viel Gegenmeinung und dann haben sie das Vorhaben auch wieder aufgegeben.

Aber eine der Ergebnisse von der Diskussion war eben einfach mal zu gucken, wie sieht das denn mit Finally aus?

Und Return, Break und Continue, Finally haben wir so ein bisschen so komische Effekte.

Wenn man einen Return macht, dann wird die Exception geschluckt.

Also wenn ich quasi try-finely habe und the code worked an exception and in the finally block machine Return, then return dann returne ich halt einfach from the function and the exception verschwinded.

And deswegen hat Irit eben gesagt sie schaut mal wie das in hier steht irgendwo wie viele Pakete sie angeschaut hat, here should go what the packets he had.

The 8000 beliebtesten PyPI packets analyzed.

Even a script geschrieben, was die abstrakten Syntax bäume durchgeht und schaut, ob eben das Finally Blöcke mit Break Continue and Return drin vorkommen und dann von Hand analysiert, wie viele von denen quasi wirklich so sein sollen und wie viele von denen ein Bugs sind.

Also es waren 120 Millionen Zeilen Python und darin waren 200 Fälle von Kontrollflussinstruktionen in Finely-Blöcken.

Davon waren 46 korrekt, aber diese 46 waren lauter Tests in irgendwelchen Lintern, die eben sicherstellen wollten, dass der Linter sagt, bitte verwende kein Return in Finele.

Acht Fälle waren wirklich korrekt, also wirklich, wo das quasi gewollt ist, dass die Exception dann geschluckt wird.

Und 149 waren dann eben Bugs, die Katrina dann auch immer bei den entsprechenden GitHub-Repositories gemeldet hat und die meisten dieser Bugs werden jetzt gefixt.

Also so sieht schon so ein bisschen aus, als wäre das jetzt nicht so das wichtige Feature und auch ein Feature, was vielleicht eher zu Missanwendungen als zu korrekten Anwendungen führt.

Sehr schön.

Ja.

Und wenn ihr wollt, habe ich noch ein mega nerdy Pick.

Oh ja.

Es gibt ein Paper, was einen C-Compiler für eine sehr kleine Timage von C nach Shell übersetzt.

Oh!

Das ist vollständig genug, dass der C-Compiler sich dann, wenn er sich selbst nach Shell übersetzen kann.

Und dann kann ich quasi, wenn ich nur irgendeine beliebige Unix-Shell habe, kann ich einen sehr kleinen C-Compiler-Bootstrappen.

Und also die haben auch Gründe, das sind irgendwelche Forscher, die gute Gründe dafür haben, machen sie das machen.

Nee, die haben so Trusting-Trust-Günde.

Also es gibt, also damit kann man halt sicherstellen, dass man keine langlebigen Backdoors in Compilern hat.

Aber die Kunde sind mir egal, warum ich das toll finde, ist, es gibt ja immer diese Argumente, C ist eine schnelle Sprache, weil die ist compiled und Python ist eine langsame Sprache, die ist interpretiert.

Und das von solchen Argumenten hatte ich gar nichts, weil das ist halt eine Eigenschaft der Implementierung, ob was compiled oder interpretiert ist.

Ich kann halt kompilierte Python-Implementierung haben und interpretiert.

Und das sagt jetzt, also es ist keine inhärente Eigenschaft der Sprache.

Und das ist einfach so ein schönes Gegenbeispiel, dass ich quasi eine kompilierte Version von C habe, die halt trotzdem ultra langsam ist.

Okay, sehr schön.

Ja, sehr schön.

Ja, ich würde sagen, das war ein passendes Schlusswort.

Jetzt könnt ihr ja auch wieder runterdrehen, eure Geschwindigkeit beim Hören.

Und wünschen euch einen wunderschönen Tag, wunderschöne Nacht, wunderschönen Morgen, wunderschönen Aufdehnt.

Bleibt uns gewogen, hallo at pythonpodcast.de für alles Feedback und so weiter.

Bis bald.

Jo.

Tschüss.

Tschüss.

Ciao.