Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Paisen-Podcast. Heute Jubiläumsepisode 60.
Hi Jochen.
Oh, Jubiläum. Herzlichen Glückwunsch und auch herzlich willkommen Dominik.
Ja, hey. Auch unsere Gäste.
Genau, ja, beziehungsweise...
Lieber Johannes, dich kennt man von.
Ja, genau.
Hallo zusammen und herzlichen Glückwunsch zur 60. Episode.
Danke. Und lieber TF, auch dir.
Ja, vielen Dank, hallo.
Du warst ja auch schon mal da, habe ich noch in Erinnerung.
Genau, Januar 23 haben wir gerade rekonstruiert.
Ja, wir sprechen heute über Python 3.13. Und ich würde sagen, da legen wir auch direkt los.
Ja, wollen wir noch News machen oder nicht?
Ich wollte gerade sagen, mit den News.
Genau, das ist natürlich irgendwie schon ein bisschen her. Wir sind ein bisschen spät dran. Aber es ist vielleicht auch noch interessant. Es gibt ein paar schöne Sachen, die man darüber erzählen kann, oder?
Ja, also wollen wir direkt
Python-Reihe 13 kommen wir auch direkt.
War gar nicht so viel los, oder?
Nee, sonst war auch nicht so viel los, stimmt.
Dann machen wir das doch direkt, ja.
Also ja, dann erzähl uns was.
Ich hab's jetzt auch schon überall
irgendwie installiert, wo ich irgendwie
Projekte angefasst habe und es funktioniert super.
Und
genau, ja, jetzt
haben wir da so einige Dinge.
Vielleicht fangen wir einfach tatsächlich mit der
neuen REPL an.
Irgendwie die halt aus dem
Pile-Pile-Projekt
übernommen wurde.
Mit der neuen REPL.
Was ist eine REPL?
Ja, so eine Read-Eval-Print-Loop.
Irgendwie das, was man bekommt, wenn man
einfach nur Python eingibt und unterdrückt.
Also nutzt ihr schon 3.13? Alle?
Außer Jochen?
Nee, ich habe es noch nicht installiert.
Ich nutze es nicht, ich nutze aber die neue REPL.
Ah, das ist natürlich ein
Spezialeinheit. Ja gut, ich benutze IPython überall.
Warum nicht Bipython?
Das hatten wir vorhin
vorgespräch schon mal kurz besprochen.
Also ich fand die Begründung interessant, warum sie
eigentlich überhaupt die REPL verbessern, wenn sie
sowieso ja wissen, dass die meisten
Leute halt sich sowieso als erstes erstmal IPython
installieren, weil das halt
viel viel netter ist. Aber der
Grund scheint zu sein, dass die
CPython Core Devs halt
während sie quasi dann die nächste
Version entwickeln, erstmal
geht PyPI nicht und
pip nicht und
IPython geht vielleicht auch nicht auf der neuen Version und
damit sie es quasi beim Entwickeln etwas netter haben,
haben sie sich quasi den schöneren Multi-Line-Edit,
schönere History-Farben-Rapple implementiert,
der jetzt in 3.13 released wird.
Also ich finde es auch toll, weil ich bin ja zu faul für iPython
und ich mache das eigentlich sonst immer klassisch.
Und toll, endlich, bunt.
Die Welt verbessert durch Eigennutzer, also Sauerei.
Ja, also das mit den Farben finde ich relativ abgefahren tatsächlich.
Also ich habe jetzt seit, weiß ich nicht, Oktober
jetzt auch den Farbing-Rapple.
Und wenn ich dann aber eine alte Version benutze
und es ist dann plötzlich nur noch schwarz-weiß
und es ist ja gar nicht so viel Farbe,
es sind ja wirklich nur die größer als Zeichen,
aber das kommt einem dann fast schon altbacken vor.
Ja, Back to the Future, das ist schon ein bisschen wie damals.
Aber schade, dass es nicht früher noch grün war oder so,
aber ein echter Hacker und so.
Ja, die Farbauswahl, die die C-Python-Entwickler getroffen haben,
das war ein riesen Diskussionsthema.
Das ist halt so Bike-Shedding-mäßig.
Also da kann man halt gut drüber diskutieren.
Und das Problem ist, dass man halt aus der Shell raus
nicht rausfinden kann, ob die Shell auf schwarz auf weiß
oder weiß auf schwarz eingestellt ist.
Das heißt, man muss Farben wählen, die bei beiden Hintergrundfarben
quasi noch einen einigermaßen brauchbaren Kontrast dann ergeben.
Und deswegen ist dieses Pink und Rot ein bisschen so ein Kompromiss,
weil das halt sowohl auf dem schwarzen Hintergrund
als auch auf dem weißen Hintergrund noch einigermaßen gut lesbar bleibt.
Ach okay, interessant.
Ja, aber
genau,
wie kommt das denn, dass du
die REPL schon verwendet
hast, obwohl gar nicht...
Ja, also die REPL ist
das ist quasi die PyPy REPL
nicht ganz, also die haben total viele neue Features
eingebaut und Bugs gefixt und so, aber so
dieses Kernfeature, dass es eben
Multiline Edit
gibt, also
vielleicht können wir auch kurz sagen, was das ist, also
wenn man quasi auf der Python
Shell eine Funktion angibt, die halt über mehrere Zeilen
geht und man macht dann irgendwie so einen Tippfehler
in Zeile 2 von 8,
dann musste man bisher halt quasi dann
mit der History Zeile für Zeile in der richtigen
Reihenfolge dann
die Funktion wieder so neu zusammensetzen, die
entsprechende kaputte Zeile dann reparieren
und dann die anderen wieder über die History holen
und das ist halt total nervig. Und deswegen
gibt es jetzt eben
Multiline Edit und PyPi hatte das,
wie ich gerade schon gesagt habe, schon quasi schon immer,
also in Anführungszeichen, also
seit PyPi 2.4 oder
2.5 oder so hatten wir das, dass man halt
quasi, wenn man nach einer Funktion
Pfeil nach oben drückt, dann kriegt man halt die ganze Funktion über
mehrere Zeilen. Man kann dann auch wie in einem Editor
mit Pfeil nach oben dann in die früheren Zeilen
der Funktion, kann das einfach editieren, geht
dann wieder ans Ende und mit Enter
definiert man dann die Funktion neu.
Und das hat ja halt, sagen wir mal,
zwei der frühen
Piper-Entwickler einfach so als
in Anführungszeichen normalen Python-Code geschrieben. Das war
einfach, also das hat eigentlich
keine Piper-spezifischen Features irgendwie
gebraucht. Michael Hudson,
Doyle und Armin Rigo waren das.
Und
so ungefähr von einem Jahr haben halt zwei
der C-Python-Entwickler, Luca Schlanger
und Galindo Salgado
gesagt, dass sie das auch gern für C-Python hätten.
Beziehungsweise die haben halt versucht,
sich zu überlegen, wie sie den Ripple verbessern können.
Der Ripple war bisher in C-Python NC geschrieben
und das macht halt alle Verbesserungen daran
relativ nervig und aufwendig.
Und dann haben sie halt geguckt, woher man vielleicht Python-Code
nehmen könnte, der irgendwie
einen Teil des Problems schon löst, ohne dann alles nochmal
neu machen zu müssen und dann habe ich
halt gesagt, dass sie vielleicht sich mal
anschauen könnten, was PyPy da hat und dann haben sie das eben
übernommen, angepasst,
den Code auch total verbessert,
weil in PyPy ist der auch immer noch
Python 2 kompatibel,
weil wir auch immer noch Python 2 Versionen releasen
und
also das haben die quasi so ein bisschen
Grund überholt und neue Tests geschrieben und so
und eben auch einiges an neuen Featuren
hinzugefügt, also
ich habe ein paar Notizen dazu gemacht, also einmal
die Farben, die haben wir nicht gehabt,
Dann diesen Paste-Mode, den es jetzt gibt, also wenn man quasi aus der Zwischenablage irgendwie mehrere Zeilen Code einfügt, dann geht ja oft die Einrückung kaputt und das ist jetzt eben auch repariert. Auch Support für Windows hatten wir bisher auch nicht und halt die Farben.
Was ich tatsächlich auch nicht kannte,
war, dass man einfach so ein Skript reinfügen
kann. Ich habe gehört, dass das schon ein bisschen älter ist. Ich weiß aber nicht,
bei welcher Version das reingekommen ist. Man kann
eine Environment-Variable setzen und dann
wird ein Skript ausgefügt. Das heißt, du hast deine
Imports, die du immer machst, direkt
mit dabei, wenn du zum Beispiel diese
setzt. Deine Lieblingsmodule?
Ja, nur sieben.
Sieben?
Finde ich ziemlich cool. Man kann dann lustige Sachen machen.
Python Starter heißt das.
Ja. Ja, ist ja
sehr schön. Muss ich unbedingt für
mein System auch bauen.
Ja, aber genau, also
ein großer Vorteil ist glaube ich auch jetzt,
dass es war vorher irgendwie
direkt in C, glaube ich, geschrieben
und jetzt ist es halt auch
Pure Python sozusagen und ich glaube, da kann man
jetzt auch einfach eine ganze Menge mehr
an die Innereien rankommen und dann auch das Verhalten so
ändern, dass man da eine ganze Menge lustige
Dinge mit tun kann.
Lukas Schlager hatte da auf der
Pure Python auch einen Vortrag gehalten.
Das war ein Performance-Vortrag.
Oder eine Performance performt.
Live-Musik-Coding-Geschichten.
Und da ist es natürlich praktisch, wenn man halt...
Lustig war, dass der Tontechniker,
der hat einen Euroreg dabei gehabt
und hat irgendwie so einen hohen Ton auf seinem Synthesizer gespielt.
Da hat der Tontechniker kurz Angst bekommen,
dass seine Anlage Schrott geht.
Hat alles runtergedreht auf so 20% Lautstärke oder sowas.
Und auf einmal war es sehr leise.
Und dann hat er fünf Minuten so gespielt.
Und irgendwann hat jemand geklopft beim Tontechniker
und hat dann überredet und gesagt,
ja, Lukas, wird diese hohen Frequenzen
jetzt nicht mehr spielen? Und dann durfte er wieder lauter drehen.
Ja, ich glaube,
das sieht man auch jetzt schon so ein bisschen. Es gibt halt einfach
viel mehr Bug Reports und Patches, was den neuen Rappel angeht.
Es ist immer noch so, dass es schon
so ein bisschen nervig ist, daran zu arbeiten, weil
wenn der Rappel kaputt ist, dann sieht man halt auch gleich
nichts mehr. Also der Debugger geht nicht
und also es ist schon,
die haben da schon
so ein bisschen eigene debugging-Sachen eingebaut.
Aber es ist schon
noch so, es bleibt so ein bisschen frickelig.
Aber ich glaube, man kann auch die alte wieder aktivieren.
Irgendwie insofern hat man da vielleicht die Möglichkeit,
auch mit der Umgebungsvariable wieder auf die alten Dings zu kommen.
Aber ja, klar, ist natürlich, wenn man es kaputt macht,
dann ein Problem.
Ah ja, wichtiges anderes neue Feature ist natürlich,
dass man jetzt bei Exit keine Klammern mehr braucht.
Oh ja.
Ja, und ich glaube, Quid geht auch.
Ja, vielleicht ist das so.
Ich meine, ja.
Ja, und Help geht auch irgendwie jetzt anders.
Aber ehrlich gesagt, keine Ahnung genau, wie.
Ja, es gibt jetzt diesen Help-Mode, der eingebaut ist mit F1.
Und dann kann man quasi aus der
Shell in so eine spezielle Help-Shell
wechseln. Und von da dann,
wenn man quasi die Namen von irgendwelchen Sachen, die man
dokumentiert haben möchte, eingibt, dann kriegt man die
direkt angezeigt.
Aber bei Print braucht man schon noch Klammern, oder?
Nee.
Ich möchte so etwas
Python 2 wieder haben.
Soll ich das mal als Feature-Request
vorschlagen? Also das kannst du jetzt auf jeden Fall
für deine
Raffle-Katze einbauen, dass sie sich dann wieder
in Python 2... Kann ich das machen?
Das mit dem Exit ist tatsächlich was,
was halt Newbies sich relativ
oft wünschen.
Q reicht, glaube ich, auch.
Ist das so?
Q reicht? Nee.
Warum steht denn das da?
Weiß nicht. Ach, für den Head-Mode.
Also Crit geht, aber
Q nicht. Schade.
Adidas QQ, da muss man direkt wieder in das
Skript reinschreiben.
Ja, aber so ist es auf jeden Fall
toll. Also ich finde das auch super, dass man da jetzt
irgendwie echt
eine ganz brauchbare Geschichte eingebaut hat
und gut, klar, also iPython
ist natürlich auch nicht schlecht oder wie Python
oder so, aber. Ja und dann
daran angelegt, wir haben jetzt Farben ja schon angesprochen, vielleicht können wir noch
über die Tracebacks sprechen.
Also in 3.11
gab es ja jetzt schon die Verbesserung, dass wir quasi
in Tracebacks diese
genaueren Positionen innerhalb
von der Zeile kriegen. Wie sagt man, Dechle, Johannes?
Genau. Dechle, ja.
Da, wo ich herkomme, sagt man Dechle.
Sind halt auch keine Dächer, sondern nur kleine
Dächer. So groß sind die gar nicht.
Ist halt so.
Genau, also es wird
jetzt quasi nicht mehr nur gesagt, das ist halt in Zeile
5 der Fehler, sondern auch noch dieser Teil
des Ausdrucks ist
der Teil, der die Exception hervorgerufen hat.
Und das
wird jetzt halt auch noch jetzt dann
farbig irgendwie anders dargestellt als der Rest der Zeile.
Ja, auch sehr nützlich.
Tatsächlich so ein bisschen readable
und man muss sich
erstmal gucken, wo ist denn jetzt der richtige Teil
vom Traceback, sondern
mit den Positionen, da
habe ich, das Feature habe ich
quasi durch einen geschickten
Tweet provoziert.
Da habe ich nämlich einen Screenshot
gefälscht, wo wir, also den hat
es nie, das Feature hat es bei uns nicht gegeben,
aber ich habe quasi einen fiktiven Traceback
auf Twitter fingiert
und das hat dann dazu geführt, dass
C-Python das wirklich entwickelt hat.
Das fand ich
großartig.
Feature-Request durch
Boßartigkeit.
Also wir können das und ihr?
Und dann gelogen.
Also ich hatte schon so einen Plan, wie ich das irgendwann mal,
wir haben das ja dann auch irgendwann
gekriegt, aber so und T-Python hat uns dann
halt einfach ganz schnell überholt und viel mehr Leute benutzen
T-Python.
Ja.
Genau, hier kann man es auch nochmal sehen.
Jetzt natürlich nicht, wenn ihr zuhört, aber
genau. Ich kann es jetzt sehen.
Das einzige, was zählt.
Ja, ja.
Genau. Ja, auch schön, man kriegt jetzt irgendwie gesagt, wenn man halt ein Modul genauso genannt hat wie eines aus der Standardbibliothek oder von sonstigen Dingen, die man installiert hat, glaube ich, also es gibt so ein bisschen bessere.
Oder wenn man halt irgendwie bei Keyword-Argumenten
das irgendwie falsch übergeben hat,
dann kriegt man jetzt auch, da gab es vorher einfach nur
so sehr, sehr kryptische Fehlermeldungen,
die halt Anfänger auch sehr verunsichert haben.
Das ist jetzt, glaube ich, auch besser.
Er macht das Vorschlag, er versucht sich dran zu erinnern,
was denn der Fehler schon sein könnte
und versucht so einen kleinen Hinweis dazu zu geben.
Ich meine, das wird halt in jeder Version
jetzt gerade so ein bisschen verbessert.
Es ist schon so ein, jetzt über einige Versionen
eigentlich so ein festes Bestandteil
von jedem C-Python-Release,
dass sie halt sich echt Mühe geben,
noch so ein paar der schlechten Fehlermeldungen zu verbessern.
Und ich unterrichte halt Python-Anfänger jedes Semester.
Das macht schon echt einen Unterschied,
ob da dann irgendwie halt Abkürzungen vorkommen,
die wir noch nie gehört haben
oder einfach nur Syntax-Error ohne irgendwas anderes steht
und wir so ein bisschen raten müssen,
was das Problem gewesen sein könnte.
Und ja, und das mit den Vorschlägen,
also wenn man sich halt vertippt,
wenn man irgendwie einen Namen vertippt,
das ist jetzt schon seit ein, zwei Versionen,
dass sie dann da dann Vorschläge
machen könnten, was halt der existierende
Name mit der kleinsten Edit-Distance ist.
Und jetzt
haben sie es eben noch zusätzlich hinzugefügt, dass es auch bei
Keyword-Argumenten geht.
Ah, okay.
Ja.
Also das ist auf jeden Fall vielleicht die
größte User-Facing-Änderung,
die man halt bekommt, wenn man
jetzt Python 3.13 verwendet.
Ja.
Ja, ich würde auch sagen, wenn die ganzen Bibliotheken
umgezogen sind, die man sonst nur nutzt, dann direkt
kann nicht mehr so lange dauern.
Wann zieht ihr denn immer um, bei der 3.1
oder bei der Punkt 1 oder Punkt 2?
Ich stelle eigentlich immer sobald,
ich probiere es vorher schon aus,
also einfach deswegen, um zu sehen, ob ich halt irgendwie
bei den Paketen, die ich
habe
oder die ich maintaine, ob da nicht
dann Dinge kaputt gehen, weil um mir dann halt,
damit ich den Ärger nicht
nach der Release kriege, gucke ich
das halt vor. Also du bist dann einer von denen, die dann die
Bug-Reports machen, wenn was nicht geht.
Ja, aber meistens
ist das halt so abstrakt, dass
ich da gar nicht in Bugs reinlaufe.
Also bisher,
wo ich es probiert habe, hat es eigentlich immer funktioniert.
Und dann
updaten,
das mache ich dann normalerweise, wenn es tatsächlich
dann erscheint. Ja, aber der Rest der Software,
den hast du ja noch nicht
alles umgezogen. Ich habe noch nicht alles
umgezogen. Ich habe auch bei einem Ding hat es nicht
geklappt. Das war irgendwie bei meinem
Fast Deploy Ding, habe ich nicht
updaten können auf 3.13.
weil irgendwas mit PyTest und Async und irgendwelchen Geschichten
nicht mehr ging dann.
Ich weiß es gar nicht mehr so genau.
Da dachte ich, okay, da warte ich jetzt mal noch zwei Monate ab
oder so und probiere es nochmal.
Mal gucken, vielleicht ist es dann gefixt.
Aber genau.
Aber die Dinge, die ich angefasst habe,
seitdem Python 3.13 raus ist, habe ich es umgestellt
und es war bis jetzt auf das eine Ding kein Problem.
Ja, die Datastandsverkehr sind immer so ein bisschen langsam.
Dann haben die immer diese Boundaries in ihren Versionen drin
und das nervt immer so ein bisschen.
Ja, ja, gut, okay. Ich habe jetzt auch gerade nicht so viel
Data Science in der Hand, daher
ist mir das nicht so aufgefallen.
Weil ich auch da das Gefühl habe, dass eigentlich viele Bibliotheken
sich da jetzt inzwischen echt Mühe geben und halt schon
bei den Betas und Release Candidates
halt gucken, ob es geht und dann schon.
Ja. Also es ist jetzt nicht mehr so, dass es ein halbes
Jahr dauert oder so.
Ja.
Ja, ich bin gespannt, wie lange es diesmal dauert. Tatsächlich, ja.
Ja.
Wollen wir hier mit den großen Blöcken
weitermachen oder willst du so ein paar der kleinen Sachen sammeln?
Ich weiß nicht, jetzt hatten wir schon einen großen.
Es gibt noch große Blöcke.
Es gibt noch zwei große.
Das war auch schon ein großer, ja.
Ich habe eben noch
die Dokumentation
durchgeschaut und den History-Modus,
den fand ich auch ziemlich gut.
Mit F2 kann man seine History ansehen.
Ist das auch persistent?
Ja, also ich habe eben in meinen
History reingeguckt in meiner Session,
die ich gerade gemacht habe. Das geht sehr weit zurück.
Ich war sehr überrascht, wie viel History da drin ist.
Oh, da muss man jetzt ja auch passen, was man
da noch brennt ohne Klammern.
Ja, das will ich jetzt nicht.
Ohne Anwalt möchte ich diese Frage
nicht beantworten.
Ne,
sehr viele schöne Sachen, aber
ich finde es sehr interessant, dass
3.13 so ein Release ist
mit einer riesigen Änderung
im Frontend, also jetzt diese Rapid-Sachen,
aber ja auch sehr
große Änderungen im Backend,
zu denen wir jetzt kommen.
Du meinst jetzt Nogel?
Ja, es sind tatsächlich
zwei.
Dann machen wir Ditt.
Da habe ich mir Notizen.
Ja, super, okay. Alles klar.
Also beides sind ja eigentlich Sachen,
die eher so im...
Vielleicht nochmal für alle Leute, die einsteigen, die noch gar
keine Ahnung von Weißwein haben, Ditt just in time.
Was ist denn das
und warum ist das interessant und warum ist das wichtig?
Vielleicht nochmal so einen kurzen Aufzug
lang und dann...
Ja.
Also C-Python ist ein Interpreter, also der Python-Code, der ausgeführt wird, der wird erst nach Bytecode übersetzt und der Bytecode wird aber dann von einem in C geschriebenen Interpreter ausgeführt und das gilt als nicht so schnell.
Das ist einer der Gründe, warum Python den Ruf hat, nicht so super schnell zu sein. Und seit ein paar Versionen gibt es da einiges an Arbeiten vom Faster Python Team, was zum guten Teil von Microsoft bezahlt wird, das zu verbessern.
Und was die machen ist, immer noch auf dem Interpreter, aber sie verändern quasi die Bytecodes zur Laufzeit in Abhängigkeit von den Typen, die in den Funktionen verwendet werden, was dazu führt, dass wenn ich halt an irgendeiner Stelle vor allem Integers benutze, dass dann für Integers angepasster Bytecode verwendet wird, was die Ausführung schneller macht.
Und das, also dieser Prozess, der hat in 3.11 angefangen und in jeder Version gibt es da eben so ein paar Verbesserungen. Und wenn man dann aber darüber noch hinaus will, dann muss man eben, oder was man dann eben machen kann, ist nochmal zu einer anderen Technik greifen, das ist der sogenannte Just-in-Time-Compiler und das ist eine Technik, die von allen schnellen JavaScript-Implementierungen oder auch von Java verwendet wird.
Und da ist die Idee, dass man zur Laufzeit eben Maschinencode erzeugt für die Funktionen, die man gerade ausführen möchte und das hat den Vorteil, dass man, also der Grund, warum man das zur Laufzeit macht, ist, weil man erst zur Laufzeit die Typen weiß, die in der Python-Funktion gerade verwendet werden und dann kann man eben Code erzeugen, der dann speziell angepasst ist auf die Arten und Weisen, wie die Funktionen, die man gerade ausführt, eben verwendet werden.
Aber das kann ja auch sehr dynamisch sein,
aber man muss dann wahrscheinlich ein paar Mal die so ausführen
und dann gucken, was passiert und dann...
Genau, also das ist der grundsätzliche Ansatz.
Man fängt eben an, das erstmal so mit dem Interpreter auszuführen
und dabei macht man so ein bisschen Beobachtung,
was für Typen eben konkret verwendet werden,
führt so ein paar Statistiken mit
und nur wenn die Funktion besonders oft ausgeführt wird
und man dann eben mit der Zeit eben so ein paar Informationen zusammen hat,
wie die Typen so sind,
dann fängt es sich an, quasi das so ein bisschen zu stabilisieren
und das ist auch dann der Zeitpunkt,
eben dann die Bytecodes umgeschrieben werden, quasi
jetzt seit Version 3.11
und jetzt, was
jetzt neu ist in 3.13
ist, dass dann eben dieser zweite Schritt hinzukommt,
wo man dann eben nicht nur
Bytecodes umschreibt und
für die Situation effizientere
Bytecodes, sondern eben auch noch
und das ist komplett optional, also bisher
in den Standard-Builds ist das Feature nicht drin,
das ist eher so ein
Feature-Outlook
für zukünftige Versionen,
dass man eben CPython auch neu bauen kann
mit so einem speziellen, experimentellen Build-Time-Flag,
was eben sagt, ich möchte jetzt gerne einen JIT-Compiler einbauen.
Und dann wird eben zur Laufzeit
dieser spezialisierte Bytecode genommen
und daraus Maschinencode erzeugt.
Und die Hoffnung ist, dass es dann eben noch schneller wird.
In 3.13 ist es aber leider noch nicht der Fall.
Also sie erzeugen quasi Maschinencode.
Aber der, ja, also der macht es halt nicht,
das macht es doch ziemlich schneller.
das ist so ein bisschen die schlechte Nachricht, aber
das ist trotzdem okay,
weil das Ziel ist quasi so,
das Fundament zu legen
für Verbesserungen, die dann in der nächsten Version
hoffentlich auch wirklich dazu führen, dass halt
dann C-Python das Sachen schneller ausführen kann.
Ja.
Und
das ist, glaube ich, eine spezielle Art
von
Just-in-Time-Compiler oder so, die es auch noch
gar nicht so lange gibt. Das geht irgendwie zurück auf
so ein Paper für
Lua irgendwie, für so Copy-on-Patch
Ich weiß nicht.
Also so ganz kann man das nicht sagen.
Die Idee gibt es schon sehr lang.
Das ist ein sogenannter Template JIT.
Und da ist die Idee, dass man,
also man hat ja dann diese spezialisierten Bytecodes,
also sowas wie Add to Integers oder sowas.
Und die Idee ist, dass man quasi für alle diese Bytecodes
so ein bisschen Maschinencode vorbereitet,
also zu dem Zeitpunkt, wo man CPython baut.
Und das dann, den vorbereiteten Maschinencode, also diese Templates, die werden dann so zusammen kopiert. Und die Idee von einem Template-Jit, die ist relativ alt. Aber was jetzt neu ist, und das ist eben dieser Copy-and-Patch-Ansatz, ist die Art und Weise, wie diese Templates hergestellt werden.
Und das ist eben die Einsicht von dem Copy-and-Patch-Ansatz. Das ist ein Doktorand in Kalifornien, glaube ich, Haorang Su. Und die Idee davon ist, dass man eben den C-Compiler benutzen kann, um diese Templates vorzubereiten. Das hat viele Vorteile.
Also man benutzt den C-Compiler, man hat so kleine Funktionen in C geschrieben, benutzt den C-Compiler, um die dann nach Maschinencode zu übersetzen und das bedeutet insbesondere, dass normalerweise, wenn man JIT schreibt, dann muss man halt anfangen für verschiedene Maschinenarchitekturen so ein Backend quasi von Null auf erstmal zu bauen und das ist halt super aufwendig, gerade wenn man viele Architekturen unterstützen will, wie das ja bei C-Python der Fall ist.
Und die Idee von dem Copy-and-Patch-Ansatz ist, man benutzt den C-Compiler, um sich den Maschinencode erzeugen zu lassen und kopiert den dann so mit Memcpy quasi an die richtige Stelle und patcht dann eben noch so ein paar Stellen, wo man dann irgendwelche Konstanten noch so in den erzeugten Maschinencode so reinpatchen kann.
Und dazu benutzt man linke Informationen. Das ist wirklich so ein relativ kreativer Ansatz, um halt mit vergleichsweise wenig Aufwand, also ohne so ein komplettes Backend schreiben zu müssen, trotzdem relativ schnell einen relativ guten Maschinencode erzeugen zu können.
Ja, ich glaube, das ist irgendwie LLVM oder so wird da benutzt.
Genau, das ist auch so ein bisschen das Problem. Also man braucht dann genau die richtige LVM-Version. Und wenn man die nicht installiert hat, dann bringt einem auch die Flag nicht. Man kann es dann trotzdem nicht bauen. Ich habe es tatsächlich noch nicht geschafft, das zu bauen, weil ich irgendwie das richtige LVM noch nicht hatte oder was. Aber ich glaube, die arbeiten da jetzt, also ich glaube, auf dem CPython-Main-Branch ist das jetzt auch irgendwie gelöst. Da werden halt dann Sachen schon eingecheckt oder, also man muss dann nicht mehr genau die richtige Point-Version von LVM installieren. Aber habe ich jetzt noch nicht ausprobiert.
Hat LLVM nicht auch so eine IR, eine Intermediate Representation, die auch irgendwie so abstrahiert ist?
Ja, also im Prinzip haben das die meisten optimierenden Compiler, die haben halt irgendwie so eine Zwischendarstellung, wo sie halt quasi diese benutzen, um Code zu optimieren.
Und bei LLVM ist die deswegen relativ sichtbar, weil sie halt gute Tools haben, um die dann in so eine ASCII-Syntax zu printen und auch wieder zu parsen und weiter zu verarbeiten.
Aber, ja.
Auch viele technische Bauteile
immer noch, ja klar.
Ja, es ist schon, also es ist jetzt schon
so ein bisschen, der JIT in 3.13,
das ist schon wirklich eher so,
das sind so vorbereitende
Arbeiten. Also die Hoffnung ist eben, dass das
dann so in den nächsten
Versionen,
also ich meine, bisher ist das relativ unbefriedigend.
Wir haben einen JIT, der erzeugt ganz tollen Maschinencode,
aber es wird halt nicht schneller.
Also,
Und es ist, ja, cool, aber halt irgendwie auch nutzlos.
Also warum sollte man es machen,
wenn sich die Performance halt dadurch gar nicht ändert?
Aber die Hoffnung ist eben,
dass sie dann, wenn sie jetzt weitere Optimierungen einbauen
und bei diesem Patching,
da kann man noch so ein paar extra Instruktionen dann wegoptimieren.
Das haben sie, glaube ich, jetzt oft im Main Repository auch schon gemacht.
Und die Hoffnung ist, dass dann eben, wenn 3.14 dann da ist,
erstens eben dann, dass sie so ein paar Bugs
gefixt haben, weil hoffentlich eben ein paar Leute
trotzdem den
experimentellen JIT halt mal ausprobieren
und dann vielleicht Bug-Reports schicken
und dass sie dann halt
in der nächsten Version dann auch die Performance
noch ein bisschen verbessern können.
Und insgesamt finde ich den Ansatz halt
cool, weil er in Anbetracht der Tatsache,
dass das C-Python-Team halt jetzt nicht so groß
ist, was bezahlte Entwickler angeht,
ich finde es halt einen relativ pragmatischen
Ansatz, wo sie ohne jetzt irgendwie
also was ich
Google vor acht hat, hat irgendwie
weiß nicht, 80 Leute oder so.
Das fand ich auch überraschend, ja.
Und
also das hier hat quasi mit der kleinen
Anzahl an Festangestellten halt
trotzdem
mit diesem Ansatz vielleicht irgendwie recht
pragmatisch irgendwo hinkommen können.
Ja, ich meine. Ja, ich finde das auch cool. Ich finde das
auch generell cool, ohne dass es jetzt
direkt eine Geschwindigkeitsverbesserung
bringt, einfach weil, wie du
gesagt hast, das ist eine wichtige
Grundlage, um dann irgendwann die Verbesserungen
rausholen zu können. Deshalb.
Richtige Richtung, meiner Meinung nach.
Ja, ich meine, wenn man jetzt nicht so viel Ressourcen hat,
muss man sich halt überlegen, wie man die ökonomisch einsetzt.
Und wenn man jetzt sieht, was
vielleicht V8 irgendwie macht
oder so und das dann halt einfach später,
wenn sich herausgestellt hat, was da gut funktioniert, halt
dann die wesentlichen Teile nimmt
oder so, das wäre schon... Wobei, ich weiß nicht
genau, gibt es irgendwo
quasi den gleichen Ansatz, der dann schon gut funktioniert?
Weil V8 ist ja dann wahrscheinlich doch
eher noch deutlich komplizierter oder so.
Sehr viel komplizierter. Also V8 hat halt nicht nur
einen JIT, sondern irgendwie drei oder so.
Oder vier.
Also halt dann erstmal einen, der quasi
schlechten Code sehr schnell erzeugt und dann
etwas besser optimiert, sehr gut optimiert.
Dann haben sie noch einen komplett getrennten JIT für
WebAssembly.
Also das ist schon
und dann natürlich auch wirklich dann
quasi richtige Backends für ganz viele verschiedene
Hardware-Architekturen.
Also das ist schon ein Aufwand, den
meiner Ansicht nach mit dem jetzigen
Funding das C-Python-Thema erstmal so nicht
hinkriegen kann.
Transpilen nach,
einfach Python transpilen nach
JavaScript.
Ja, oder nach
WebAssembly.
Das stimmt, das ist ja tatsächlich eine unterstützte
Plattform, ja.
Genau, das ist jetzt eine Tier-2-Plattform.
Ja, genau, das stimmt.
Also das ist
so ein kleines Ding, es gibt drei neue Plattformen
in 3.30. Ja, super spannend.
Soll ich mal,
ich lese mal hier vor, also
die erste, die
Tier 2 Plattform heißt
WASM32 WASI, also eine
WebAssembly Plattform.
CF, weißt du, was
Tier 2, weißt du, was die Tiere bedeuten?
Ich glaube irgendwie,
die machen Aussagen darüber, wie viel
Bildbots sie haben und was sie so versprechen
an
Support über die, genau, über die
Version. Da gibt es irgendwie ein Papp dazu.
Ja, okay, gut. Also das kann man
nachlesen. Aber ist jetzt eine höhere
Zahl besser oder eine kleinere?
Also eins ist am besten.
Die niedrigeren Zahlen sind besser, oder? Je näher du
am Ziel bist, an der
Spitze, umso besser ist es. Also
WebAssembly ist jetzt Tier 2
Supported Plattform mit vielen Buildbots und viel
Stabilität in der Version. Und es gibt zwei
neue Plattformen,
die, da war ich sehr überrascht,
die es gibt, nämlich Android und iOS
sind Tier 3
Officially Supported Plattform.
War ja früher ein riesen
Thema, wenn man Android, wenn man
Python auf Android ausführen wollte oder noch schlimmer
Python auf iOS.
Das ging auch schon sehr lange.
Das ging auch schon sehr lange. Ich meine, es ist ja
auch kein Problem, du kannst ja einfach
den Interpreter auch total kopilieren
und so. Und da ging auch
NumPy und so, das ging alles. Und es gab
da so eine schöne App namens
Pythonista.
Aber die hat
natürlich eigentlich schon gegen die App-Store-Regeln
verstoßen.
Also ich meine,
mein
Beowulf-Cluster aus iOS,
aus iPhones.
Was ist genau die Regel?
Also die App-Store-Regel ist,
du darfst da nur
Dinge installieren. Also
kompilierter Code, ja, aber auch irgendwie
C++, C, irgendwie
Objective-C,
und
was war es noch?
Ich weiß nicht, vielleicht
ist gerade eine Handvoll Sprachen.
Aber viel wichtiger ist doch die Regel, dass du keinen
dynamisch erzeugten Code nachladen musst.
Ja, das genau, ja.
Weil dann kann Apple ja nicht mehr prüfen,
ob du nicht irgendwelche schlimmen
Programme nachlädst.
Ihre Sandbox-Tests oder was auch immer die da noch mal machen.
Ja, ist auch ein
Und du konntest halt mit Python,
da kannst du halt auch einfach quasi Python-Code
auf deinem Telefon ausführen und
das geht natürlich eigentlich nicht.
Ja, ist klar.
Aber es ging dann doch. Ja, aber bei Android
wäre das ja prinzipiell gegangen.
Nur war halt das Tooling bisher immer
sehr umständlich. Also ich weiß,
dass es Beware gibt und es gab auch
Kiwi und viele andere
Ansätze schon, aber die waren schon
immer sehr umständlich.
Und wenn es jetzt...
Genau, das ist schon noch wichtig, dass es
dass es jetzt halt quasi von den
C-Python-Entwicklern halt mit
versorgt wird. Ich habe jetzt nochmal nachgeschaut, was genau
die Tires bedeuten. Also Tire 1
ist halt das richtig gute Zeug, also so
macOS, Windows,
Linux.
Tire 2 braucht man halt irgendwie
Buildbots und mindestens zwei
C-Python-Core-Developer, die
eben die Plattform unterstützen
und wenn es da
Buildbot-Failures gibt, dann
werden C-Python-Releases dadurch
blockiert. Und Tire 3
heißt eben
BuildBot einen Core-Entwickler,
aber wenn es da
Bugs gibt, dann kann man trotzdem,
also dann kann C-Python trotzdem released werden.
Also es ist quasi so,
wir geben uns Mühe, aber
wenn jetzt irgendwie
es nur noch irgendwie einen bekannten Bug auf Android
gibt, dann releasen wir halt möglicherweise trotzdem.
Und der
Core-Developer, der für Android und
iOS zuständig ist, ist übrigens Russell
Keith-McNeil, der der
auch Beware schon gemacht hat, der das schon lange
gemacht,
hat es jetzt offenbar eben reingekriegt.
Der diesen tollen Vortrag
gehalten hat, irgendwie
Black Swan Events für
ich weiß gar nicht, wie der Titel von dem Vortrag hat,
da ging es halt genau darum, was es könnte,
was eigentlich sind die bedrohlichsten Geschichten, die
jetzt Python noch zustoßen können
und ein Szenario war halt
so, ja, was ist, wenn
irgendwie künftige Generationen gar nicht
mehr vor so riesigen Desktop-Dingern
sitzen oder so, ich kann das
gar nicht verstehen, ich finde das total toll, aber
eher vielleicht auf Tablets oder Telefone gucken
und dann einfach ein Vergessenheit gerät, dass
es Python überhaupt noch gibt, weil Python gibt es halt
nicht auf iOS oder so.
Und dagegen sollte man vielleicht
was tun. Und dann, ja, jetzt ist halt was
passiert und das sieht ja schon ganz gut aus.
Ja, ich habe das bei meinen Studenten. Man muss nach Studenten echt.
Also ich habe halt, also ich mache
eine Python-Einführung für alle, also
da dürfen Informatiker nicht hin.
Und das heißt, ich habe auch Studierende
aus allen Fächern und
jetzt nicht viele,
aber da gibt es halt dann immer wieder Teilnehmende,
die dann halt einfach auch nur ein Tablet
haben. Tier 1?
Ja, also da sind wir noch nicht.
Wir haben kein Tier 1 Gerät, genau.
Und Jupiter Notebook
haben wir. Wir haben dann halt entweder die Möglichkeit,
das irgendwie über Google Call-Up zu machen,
also ich mache alles mit Jupiter Notebooks, aber das ist halt dann immer
so ein bisschen nervig mit die Input-Dateien
hochladen und so Zeug.
Und dann können die sich ins Rechenzentrum setzen,
da hast du es auch installiert, aber das ist natürlich auch total nervig,
du musst immer deine Übungsaufgaben da machen.
Und so einen richtig,
also richtig guten Jupiter Support
auf so einem
iPad gibt es halt einfach auch noch nicht.
Das ist schon einfach
im Vergleich zu installiert
an der Conda, dann ist alles in Ordnung, ist es halt schon einfach
sehr frickelig.
Ich muss
noch dazu sagen, nicht, dass wir jetzt hier Personen
übergehen, es gibt noch zweite
Maintainer für diese Plattform, neben Russell
Keith-McGee. Für Android
gibt es noch den Peter Victorin
oder Peter Victorin
oder wie auch immer man das aussprechen mag.
Einer von den drei,
mir verzeihen, die Wille auf Besuch.
Es gibt es noch den
NetDaily. Also wieder so eine tolle Name-Calling
gemacht, da muss ich ja nochmal kurz zum Sammelkartenspiel
zurückkommen, was er sich kurz angekündigt hat.
Weil ich ja auf
dem Talk von
Lukas Langa, der ja
in diesem tollen Rappel irgendwie dann ein
kurzes Befehlchen eingeben konnte,
um das Bild von, ich dachte,
es wäre John Romero gewesen, was
eigentlich Pablo Cardenas Agato war.
Und dann hatten wir kurz dieses Thema
und ich finde das eigentlich eine coole Idee, dass man demnächst
auf den Pycons so
Sammelkartenspiele. Wir bringen die erste
Edition mit, dann machen wir den Python-Podcast
das dann Team an.
Ich finde, die
sollten das selbst verteilen und
nur die Leute, die bei den Vorträgen waren,
kriegen auch so eine Karte. Also ich glaube,
man kann die verkaufen. Also ich vermute,
dass das wirklich die Art und Weise ist, wie man
endlich mal gutes Funding für 10 Seiten findet.
Ja, dann liebe
Zuhörer, schreibt uns, ob das die Wahrheit ist
und dann müssen wir das wohl machen. Damals als
NFTs. Irgendwann gab es ja auch so Sachen, die dann diese
Bilder dann gemacht haben und das dann als NFT.
Ja, aber das mit den NFTs
ist immer noch die Zukunft.
Ich weiß nicht.
Der einzige Vorteil von AI ist, dass die die NFTs
verdrängt haben.
Für einen ganz
kurzen Moment waren Grafikkarten wieder billig
und dann hat die AI
zugeschlagen.
Tja.
Okay, also es gibt zwei neue
Plattformen, Android und iOS und
das ist eine großartige Sache, finde ich.
Und WebAssembly.
Und WebAssembly, ja genau, WebAssembly ist quasi
aufgestiegen von M-Skripten
zu WASI.
Wir müssen noch
über den anderen JIT reden.
Es gibt nämlich
zwei JITs in 3.13 und der eine ist
der coole, der quasi das irgendwann mal schneller machen soll,
der aber quasi standardmäßig gar nicht
eingebaut ist und dann gibt es aber den
anderen, der quasi standardmäßig eingebaut ist,
aber für einen ganz anderen Zweck und
ich glaube in einer der
Core.py folgen, ist Pablo Galeno
Sagado, über den wir gerade auch schon geredet haben, sehr stolz
drauf, dass er quasi den ersten
C-Python-Jit gemerged hat und geschrieben hat.
Und das ist nämlich der Jit, der benutzt wird, um
besseres
Profiling machen zu können.
Und
das funktioniert mit dem Linux Perf
Profiler. Und das Problem,
wenn man jetzt so ein, also der Perf Profiler
ist eigentlich so ein Profiler für
C. Also man kann halt sehen, was macht
der Kernel, was macht der Linux Kernel oder was machen eben auch
die C-Programme, die im User-Space laufen
und man kann eben sehen, die und die
C-Funktionen werden jetzt gerade so und so oft
ausgeführt. Das ist so ein Sampling-Profiler, also
der Profiling-Aufhalt ist sehr gering.
Das Problem ist jetzt aber, dass wenn man
quasi Python-Programme profilt,
dann sieht man natürlich jetzt gar nicht, welche
Python-Funktionen wie viel Zeit verbrauchen, sondern
man sieht dann die ganze Zeit
nur, dass halt irgendwelche Interpreter-Funktionen
ausgeführt werden. Und da
gibt es jetzt eben dieses neue Feature, den
PerfJit. Und da ist die Idee,
dass man so eine ganz, ganz kleine, irgendwie ein paar
wenige Maschinencode-Instruktionen
lange Funktionen generiert
zur Laufzeit
und für jede Python-Funktion eben genau
eine so eine Funktion. Und das hat
den Vorteil, dass Perf eben die ganzen Python-Funktionen
voneinander unterscheiden kann. Wenn man eben
nicht nur eine interpretierige
Python-Code-Funktion
dann sieht in Perf,
sondern man sieht dann eben diese neu generierten
Mini-Funktionen. Und dann
gibt es irgendwie so einen Rückübersetzungsschritt,
wo man dann eben sagen kann, okay,
diese neue, neu generierte Assembly-Funktion
an Adresse sowieso, die entspricht
eben der Python-Funktion
f, wie auch immer.
Und so kann man dann eben mit
Perf sehen, in welcher Python-Funktion man
lange Zeit verbraucht hat.
Das hört sich nach einem
sehr umständlichen Weg an.
Es ist erstaunlich umständlich, aber Profiling
ist auch echt einfach ultra kompliziert.
Ja, gut, klar.
Also es gibt
ja irgendwie so
irgendwie eine große Sammlung
an Profilern für Python und für andere Sprachen, aber
C-Profile hat halt einfach
einen riesen Overhead. Dann gibt es verschiedene
Sampling-Profiler für Python. Wie heißt dieser?
PySpy oder so? Der funktioniert, glaube ich,
ziemlich gut. Habt ihr den mal benutzt?
Nee, ich weiß
gar nicht. Ich hab wieder vergessen, was ich
hab mal irgendwas benutzt.
Gibt es einen, der Hotspot heißt?
Aber Hotspot ist, glaube ich, eine UI nur, oder?
Wo da die Samples herkommen, weiß ich nicht so genau.
Ja, und dann gibt es also
unseren quasi, WMProf, der ist aber nicht mehr so richtig
maintained. Also auf Piper schon, aber
C-Python nicht so richtig. Ist auch Sampling.
Also Sampling heißt halt, dass man quasi
nicht jeden Funktionsaufruf mitschreibt, was halt
sehr, sehr hohen Overhead hat, sondern
einfach nur so tausendmal pro Sekunde halt guckt,
welche Funktionen gerade auf dem Stack sind.
Und dann sagt, so statistisch gesehen,
sind das die Funktionen halt, die dann viel Zeit brauchen.
Und
Perf ist halt auch so einer. Und der Vorteil von diesem
Sampling-Ansatz ist, dass man den Profiling-Overhead
eben beliebig klein machen kann.
Man kann halt die Anzahl der Samples immer kleiner machen.
Und wenn es dann nur noch 10 Samples sind, dann ist es halt quasi genauso schnell, wie es vorher auch war. Man hat aber auch schlechtere Informationen dann sozusagen. Also man kann dann quasi die Abwägung zwischen Genauigkeit der Informationen, die man hat und Overhead beliebig ausbalancieren.
Und Perf funktioniert halt sehr gut, wenn man da gute Informationen darüber kriegt, was auf dem C-Level funktioniert. Aber die Informationen, welche Python-Funktion da jetzt gerade involviert ist, die geht halt verloren. Und die kann man dann eben wieder zurückkriegen mit diesem neuen Perf-Integration-Feature, das jetzt in 3.13 released wurde. Aber ist auf jeden Fall frickelig.
Also ich glaube auf Mac ist es ja auch total schwierig, weil man braucht halt so ausführbare Blöcke von Maschinencode und Apple hat da halt auch einiges an Security Features. Man muss dann quasi sicherstellen, dass man so einen Codeblock eben so hin und her wechselt zwischen ich kann den Codeblock schreiben und ich kann ihn ausführen.
Also man kann nie gleichzeitig schreibbar und ausführbar haben, um eben so Security-Exploits unwahrscheinlicher zu machen. Und bis man das ganz genau richtig hingekriegt hat, das ist tricky. Wobei Perf ist eigentlich nur ein Linux-Projekt. Insofern habe ich, glaube ich, gerade Quatsch gesagt.
Ach so, das gehört. Ja, ich will
mit MacOS, ich glaube, im letzten
Copy-by-Episode war auch irgendwie
drin, dass der
Memory-Profiler, Memory, den Pablo
gerade geschrieben hat, der
hat auf MacOS nicht funktioniert,
weil
irgendwie sie
die malloc-Funktion irgendwie, also
nicht die...
Von einer
Mac-Version zur nächsten.
Kann man auch schon mal machen.
Warum nicht?
Ja, ich finde es cool, dass es Leute gibt, die sich dann
wirklich mit den Linkern auf allen Plattformen rumschlagen,
um dieses Problem zu lösen.
Ja.
Ja, ja, Profiling, tja.
Das ist... Wenn das so low-level ist,
sinkt dann eigentlich der Tier, ist dann Tier 0, oder?
Sorry.
Couldn't resist.
Es ist interessant.
Aber was ist denn das nächste
Thema auf unserer Liste?
Ja, na gut.
Dann, was jetzt auch drin ist,
das wurde auch viel diskutiert,
ist halt, ja, es nennt sich jetzt
Free Threading früher, No-Gill irgendwie,
dass man halt
optional den Gill
ausschalten kann, ist auch eine,
muss man Compiler-Flex setzen und dann
neu kompilieren oder halt sich ein entsprechendes
Binary halt via was auch immer, wie man
halt so Python installiert, halt
das damit installieren und dann
kann man das benutzen.
Tja, also... Was macht das denn überhaupt,
der Gill?
Oh!
Ja, es sorgt eigentlich im Grunde dafür, dass halt der, dass immer nur, dass Python immer nur auf einer CPU läuft, wenn ich das jetzt mal ganz.
Aber das ist ja noch eine Auswirkung, das ist ja nicht das, was dem macht.
Ne, ich glaube, das ist tatsächlich das, was.
Und es stimmt auch nicht, er kann auf vielen CPUs laufen, nur halt immer nur auf einer gleichzeitig.
Ja, immer nur auf einer gleichzeitig, genau, das meinte ich.
Aber das ist ja nur eine Auswirkung, das ist ja nicht der Grund,
warum man das macht. Der Grund, warum man das macht, ist, dass
viele Operationen,
gerade was Memory Management angeht,
man dadurch
halt nicht, da muss man halt nicht locken,
was man ansonsten halt müsste, weil
wenn man den Reference Counter von irgendeiner
Datenstruktur erhöht, oder
Also ganz allgemein, die ganzen
Datenstrukturen sind halt erstmal nicht
Threadsafe.
Und das bedeutet, dass wenn man
die von mehreren Threads aus benutzt,
wird alles kaputt, dass die dann kaputt gehen können.
Um das zu verhindern, müsste man halt locken
und wenn man lockt, dann wird alles so langsam,
dass man keinen Vorteil
mehr davon hat, dass man mehr
CPUs hat. Also ich glaube,
die ersten Versuche, das war
das Projekt hieß irgendwie
Gilectomy oder so.
Es gibt noch ein älteres.
Also so alle paar Jahre kommt mal jemand
und schaut ein Versuch aus.
Doch, bei 1.1 wieder nicht genau aufgepasst.
Ja, genau. Also es war wirklich so
1.6 oder irgendwie so was ganz frühes, wo das dann
kann gut sein, aber da war das
auch, also an den Versuch erinnere ich mich noch
und da war es halt so, dass wenn man das einfach nur
versucht hat zu locken und auch nicht
irgendwie was kompliziertes gemacht hat, sondern
einfach mal probiert hat, es nicht ganz so langsam hinzukriegen,
dann war irgendwie
Performance war so Faktor 40
weniger und
ja, dann hat man es auch
Single Performance, genau.
Und dann hat man es runtergekriegt mit Tricks auf
20, Faktor 20
irgendwie schlechter, aber das ist halt immer weit
entfernt von. Irgendwie
man will das verwenden, weil wenn das
so eine Auswirkung hat, dann lohnt sich
das eher nicht. Aber was macht man denn dann mit den ganzen
Objekten, die da irgendwo rumliegen? Wie holt man die denn dann weg?
Wie meinst du?
Wenn man nicht mehr braucht.
Du meinst Garbage Collector?
Ja. Gut, das ist nochmal ein anderes...
Der weiß ich gar nicht, ob der irgendwie...
Aber der Reference Count ist ja dafür da, oder?
Dass man das wieder wegräumen kann, wenn es auf null fällt.
Also an dem Garbage Collector hatten die quasi bei diesen
Gilectomy und so Versuchen auch nichts geändert.
was sie gemacht haben, ist jedem Objekt einen Log zu geben
und immer wenn ein Threat mit dem
Objekt eben interagieren will, insbesondere
wenn eben der Reference Count
verändert wird, musst du halt dir erstmal
das Log holen für das Objekt.
Und weil halt
ständig, um irgendeine Operation mit
dem Objekt machen zu können, du halt ständig an dem Reference Count
rumoperierst,
ja, musst du halt ständig auf das Log
warten und das hat halt
die bisherigen Versuche, den
Guild zu entfernen, einfach sehr, sehr teuer gemacht.
Also die Single-Thread-Performance eben komplett ruiniert.
Und jetzt kann es doch dann eigentlich sein,
dass so ein Objekt dann einfach weggeräumt wird,
obwohl es noch gebraucht wird?
Jetzt wird es super kompliziert.
Also wir haben jetzt, genau, es gibt ein Guild,
der verhindert, dass mehr als ein Thread Python-Core ausführen kann.
Also gleichzeitig auf einem Core.
Jetzt kommt eben der nächste Versuch
Und das ist von Sam Gross bei Meta über viele Jahre lang eben probiert worden und der hat einige sehr clevere neue Ideen da reingebracht, um zu versuchen eben die Verlangsamung für Single-Thread-Performance, soweit es geht, zu minimieren.
Und da gibt es eben so eine ganze Bandbreite an Optimierungen, womit er dann eben versucht, genau diese Probleme in den Griff zu kriegen. Und eine davon ist eben die Beobachtung, dass die allermeisten Objekte, die werden halt trotzdem nur von einem Thread benutzt.
Also wenn ich halt eine Funktion habe, die
irgendwie eine Liste erstellt und da was rein
appendet und so weiter, selbst wenn
auf ganz vielen anderen Threads halt noch Sachen laufen,
kommt halt kein anderer Thread
erstmal standardmäßig an diese Liste ran.
Das heißt, die erste Optimierung ist zu sagen,
für die ganzen lokalen
Objekte, die ich also nur von einem Thread
überhaupt jemals anfasse,
muss ich für das
Updaten der Reference Counts eben nicht locken.
Also das ist quasi
so die wichtigste Optimierung.
Genau, das heißt
Biased Reference Counting, weil quasi
dafür gesorgt wird, dass man eben
nicht gesharete Objekte,
die nur von einem Thread
eben erreichbar sind,
dass man da eben das Locking quasi
sein lassen kann.
Jetzt gibt es aber natürlich
eine ganze andere Klasse an Objekten,
die werden halt von ganz vielen
verschiedenen Threads angefasst, also halt
alles, was die ganzen Build-ins, also
None,
die ganzen Typen und dafür gibt es
dann also wieder einen ganz anderen Ansatz. Und da ist nämlich
die Idee, dass man da halt sagt,
diese Objekte, die können eh nicht sterben.
Also sowas wie NAN.
Warum nicht wegräumen? NAN gibt es halt einfach
immer und das gilt
halt für ganz, ganz viele andere Arten von
Objekten auch. Die meisten Typen gibt es halt immer
und die werden dann so
unsterblich gemacht.
Ist das dann ein Singleton?
Also NAN ist auch ein Singleton,
ja, aber das ist nicht das einzige
Kriterium. Man kann sich schon noch vorstellen, dass es Singletons gibt,
die halt vielleicht auch sterben könnten.
aber, also die man vielleicht wegräumen will, aber
es gibt
also die ganzen eingebauten Sachen, die
werden einfach nie, also die
werden halt nie garbage collected und deswegen kann man
da eben auch sagen, da kriegt jetzt der Reference Count
irgendwie so einen speziellen Flag und
dann erhöht und senkt
man den Reference Count eben auch nicht.
Und das, dann muss man die auch wieder nicht
locken, also.
Und dann gibt es noch den dritten Ansatz
und das ist das sogenannte Deferred Reference Counting
und da verstehe ich die ganzen Details auch nicht komplett,
aber da ist eben die Idee, dass man
eben das Erhöhen und
Senken des Reference-Counts nicht mehr
die ganze Zeit up-to-date macht,
um
eben zu, also da geht es um
Objekte, die so dazwischen sind, also die von einem
mehr als einem Thread erreicht werden können.
Also man erhöht, aber man
reduziert das nicht oder beides nicht?
Ich glaube beides
nicht, also und dann
das sorgt aber dafür, dass wenn der Reference-Count null wird,
dann kann man die auch nicht sofort einsammeln, sondern
da muss man eben warten und dann
warten, bis alle Threads zu irgendeinem
wohldefinierten Punkt kommen und dann kann man schauen,
ob es nicht noch irgendwelche References
in den Stackframes gibt oder so,
die dann noch dazugezählt werden müssen.
Deswegen eben Deferred. Und nur
wenn man da dann eben überall nachgeschaut hat und
feststellt, oh okay, das Objekt, das ist
jetzt wirklich auch von keinem Frame-Objekt mehr
erreichbar, dann kann ich das wirklich wegräumen.
Und das hat auch komplizierte
Interaktionen mit dem
Memory Allocator,
Da wechselt nämlich die Free-Threading-Version
auch zu Mimalog.
Das ist so ein von Microsoft geschriebener C-Memory-Allocator,
der eben auch besonders gut mit Multi-Threading interagiert.
Und da wird auf eine für mich noch nicht ganz verständliche Art und Weise
eben mit besonderen Mimalog-Features dann erreicht,
dass genau das Richtige passiert.
Dass genau das Richtige passiert, das ist immer toll.
Ja, das ist auch ...
Ja, aber das hört sich jetzt so ein bisschen an wie so Eventual Consistency für den Reference-Counter.
Ja, ich glaube, das ist genau.
Weil im Endeffekt ist die Zahl, die in dem Reference-Counter drinsteht, ja auch nur dann wichtig, wenn es eine Null ist.
Also Vorbemerkung ist, das gilt alles nur für Objekte, die eben von mehr als einem Thread erreicht werden können.
Ja, okay, klar.
Genau, aber für die hast du absolut recht, da ist eben da eine Zahl drin, die nicht unbedingt wirklich alle References von allen Threads dann widerspiegelt.
Und um das Objekt dann wirklich wegräumen zu können, muss man halt nochmal nachschauen, ob das wirklich alles so gestimmt hat.
Genau, aber für mich der Knackpunkt an dem, dass das überhaupt funktionieren kann, ist, dass die Zahl, die tatsächlich in dem Reference Count drinsteht, die meiste Zeit ja uninteressant ist.
Solange die Zahl größer als 0 ist, ist der exakte Wert nicht wichtig, sondern es wird erst dann wichtig, wenn der exakte Wert 0 erreicht.
Also so ein bisschen so, als wenn du die Box aufmachst und guckst, ob die Katze noch lebt.
Ja, aber du musst sie ja nur aufmachen, wenn du es wirklich wissen willst.
Solange es dich nicht interessiert, ob die Katze noch lebt, kannst du außen den Schalter drücken oder nicht drücken, so viel du willst.
Und ich glaube, das ist für mich in meinem Kopf so ein bisschen der Kern an der Sache, warum das überhaupt funktionieren kann.
Weil wir nur zu sehr wenigen Zeitpunkten wirklich den exakten Wert wissen müssen, weil wir nur zu wenigen Zeitpunkten wirklich draufschauen müssen und sagen müssen, okay, jetzt muss ich wissen, ob die Zahl wirklich null ist oder nicht.
Ich glaube, Eventual Consistency ist auf jeden Fall ein super Gedankenmodell, weil, also Eventual Consistency wird ja auch quasi aus den gleichen Gründen eingeführt. Also natürlich kann ich, will ich, eigentlich ist es besser, wenn meine Information halt die ganze Zeit konsistent ist.
Aber das hat halt im Datenbankbereich
dann auch entsprechende Nachteile, Performance-Nachteile.
Ja, und gerade in verteilten
Datenbanken. Genau.
Und quasi aus den gleichen
Gründen führe ich halt quasi
im Field, also auf einem ganz anderen
Maßstab natürlich, aber werden die
Deferred Reference Counts verwendet.
Ja, cool. Super coole Sache.
Ja, genau.
Aber es ist halt, wie gesagt, auch bisher noch
experimentell
und standardmäßig nicht eingebaut. Da gibt es auch noch
so ein paar Nachteile. Die Single Thread Performance ist
auch quasi in der
Free-Threading-Version schlechter im Moment.
Ich glaube vor allem, weil sie im Moment eben noch
dieses Bytecode-Rewriting,
wo wir vorhin in der JIT-Sektion drüber gesprochen haben,
noch abschalten müssen.
Eben aus dem Grund, dass wenn ich quasi mehr
als einen Thread habe,
der die gleiche Python-Version ausführt
und alle wollen jetzt den Bytecode umschreiben,
dann habe ich da eben auch wieder
quasi
Mutationen derselben Datenstruktur
von einem Thread und das will ich nicht immer locken
und deswegen haben sie das bisher einfach
abgeschaltet in der Free-Threading-Version
und das sorgt dann eben für
weiß ich nicht, 10%, 20%
Verschlechterung der
Single-Threading-Performance.
Oder
es gibt eben, ein anderes Problem ist, dass es
gibt eben einfach ganz, ganz viel Python-Code, der
so in der Welt ist, in irgendwelchen Bibliotheken,
der einfach nicht Thread-Safe ist.
Bisher konnte man sich halt so ein bisschen immer
so durchmogeln
mit der Tatsache, dass meistens ist man
halt vom Gill geschützt und
so viel Multithreaded-Python-Code
gibt es halt auch oft nicht und
deswegen finden wir jetzt
wahrscheinlich die nächsten zehn Jahre
Locking-Bugs in allen
PyPI-Bibliotheken.
Und für die C-Extensions
gilt das natürlich erst recht.
Ja, aber die C-Extensions hatten ja vorher schon
die Möglichkeit, den GIL
freizugeben, also NumPy zum Beispiel.
Ja, sobald ich quasi was
mache, was dann wirklich
weit weg von jedem
Python-Objekt.
Genau, was aus dem
Python-Memory-Management rausgeht.
Da kannst du schon mit deinem Fuß
deinen Sprecher kaputt hauen.
Ja gut, okay, Footguns.
Also genau, die große
Mathematik-Multiplikation, die NumPy macht,
die hat halt mit Python nichts mehr zu tun.
Und die konnte halt dann auch schon
auf dem extra Core dann
den Lüfter heiß laufen lassen.
Aber genau.
Ja, das sind die
wenigsten Operationen, das ist mir schon klar.
Die prinzipielle Möglichkeit gab es vorher schon.
Wenn ich mein eigenes Memory Management
mache, brauche ich auch, bin ich nicht auf den Gelenk.
Ja, aber da hat man sich dann ja auch wahrscheinlich
dann schon Gedanken drüber gemacht, wie man das dann tut,
ohne dass es kaputt geht. Oder wenn man
es falsch gemacht hätte, wäre es schon aufgefallen.
Aber ganz viel von dem, wo man sich keine Gedanken
gemacht hat, das wird dann jetzt wahrscheinlich irgendwann
auffallen, dass das nicht ganz richtig war.
Das ist auch in der Standardbibliothek.
Da gibt es einfach ganz viele solche Stellen.
Wir hatten heute so ein Bug-Report.
Es gibt das Line-Cache-Modul.
Das kennt keiner, weil man das quasi selber nie benutzt.
ist quasi dafür da, dass wenn ich Tracebacks
kriege, dass die Source-Code-Zeilen
halt quasi aus den Python-Dateien
geladen werden zum Anzeigen. Und das wird
gecached, damit ich nicht jedes Mal die Dateien eröffnen muss.
Und wenn ich jetzt aber
quasi Python-Code zu Laufzeigen erzeuge, mit
exec oder so, dann kann ich quasi auch
da dann in den Line-Cache
so Sachen reinschreiben. Und die
will ich aber vielleicht auch wieder löschen, damit
eben der Cache nicht mehr und mehr Speicher
verwendet. Und dann hatten wir einen Bug von
SymPy oder so, die schreiben da eben so
Sachen in den Line-Cache rein und löschen die dann auch wieder.
und dann stellt sich halt raus, dass der Line-Cache
nicht Thread-Safe ist. Also wenn ich
das quasi von mehreren Threads mache,
dann kriege ich halt irgendwelche komischen Exceptions
von irgendwelchen internen Line-Cache
Funktionen, von denen ich noch nie gehört habe
und ja,
also wenn, klar
das ist jetzt alles schon extra ultra
speziell, aber so Stellen wird es
halt in der Standardbibliothek auch noch an
anderen Plätzen geben, dass man halt dann
feststellt, oh okay, es gibt hier Python-Code,
da hat halt noch nie jemand drüber nachgedacht,
was passiert eigentlich, wenn ich das auf
vier Threads gleichzeitig ausführen.
Ja, und eigentlich sollte man sich ja auch keine Gedanken,
beziehungsweise es ist ja der
Ansatz, dass man sich keine Gedanken drüber machen soll.
Viele andere Sprachen lösen das Problem halt
auf eine andere Art und Weise, indem sie sagen,
da musst du jetzt halt selber explizit drüber nachdenken.
Also
man wird da... Das ist ja der Ansatz, dass man es in Python
nicht machen muss. Man wird da in Python schon drüber nachdenken
müssen. Also wenn du halt sowas hast, wie du hast
irgendein globales Dictionary und das wird
jetzt von zwei Threads mutiert und ich habe aber in beiden
eine Iteration darüber,
dann sind halt wahrscheinlich die Invarianten
der Schleife kaputt, egal ob die Datenstruktur
jetzt, also klar, die Datenstruktur
soll nicht kaputt gehen, aber ich kann
ja trotzdem dann plötzlich den Key
verlieren, den ich erwarte, dass da noch
eine Dictionary drin ist.
Ja, auch diese ganzen
Probleme, die bei Multithreaded Programming
auftreten, also allein,
wenn ich irgendeine Variable habe, die ich inkrementieren
möchte, dann, da muss
ich ja schon irgendwie einen
Mechanismus haben, der
Multithreading ermöglicht, aber
das ist ja nochmal eine ganz andere Ebene.
Ja, ja klar und das ist auch, also solche
Bugs haben wir definitiv auch schon gesehen, also
sowas wie, ja die sind ja auch leicht,
also ich meine, die hat man ja sofort,
ja, also sowas wie self.counter
plus gleich 1, das ist halt nicht
Atomic in
der Free-Threading-Version, ja, also wenn ich
da mehrere Threads habe, die das machen,
dann, ja,
dann könnten halt komische Sachen passieren.
Aber da gab es auch früher schon so,
Gab es auch früher schon so Stolperfallen, wo manche Sachen in Python Atomic aussahen und es dann aber irgendwie auch nicht.
Genau, also viele von diesen Bugs, die sind quasi bisher auch schon, das sind jetzt quasi keine Bugs, die nur in Free Threading wirklich vorhanden sind. Das sind quasi latente Bugs, die es schon immer gibt, die auch quasi in der ganz normalen GIL-Version von Python Bugs sind und Crashes verursachen können.
Nur bisher waren die quasi einfach viel unwahrscheinlicher, dass man die wirklich dann auch trifft, diese Bugs. Aber dadurch, dass jetzt eben mehr Leute versuchen werden, mit Multithreading in der Free-Threading-Version Programme dann schneller laufen zu lassen, wird die Wahrscheinlichkeit, dass man diese Bugs halt dann auch quasi in echt sieht, die geht halt hoch.
Das heißt, also ja, ich meine das ernst. Wir werden jetzt wahrscheinlich zehn Jahre lang Bugs in allen Bibliotheken finden, die irgendwas mit Threading zu tun haben.
Ja und es gibt ja auch keine so richtigen atomaren Operationen in Python oder keine, denen das ansieht, dass sie atomar sind. Das macht das Reasoning so ein bisschen schwierig.
Absolut. Und das ist ja auch eine der großen Schwierigkeiten des Free-Threading-Projekts, dass sie sich quasi bei allen eingebauten Containern, also wie Listen und Dictionaries und so weiter, jetzt überlegen müssen, welche der Methoden wollen wir eigentlich als atomar verstanden haben und welche halt dann auch nicht.
Das erkennt man nicht.
Ich glaube, das wird dann dokumentiert.
Ja gut, klar, das muss man nachlesen, aber ja.
Aber die Entwickler, die quasi Free Threading implementieren,
die müssen sich eben bei jeder Methode Gedanken darüber machen.
Also List Dependent ist halt Atomic,
aber List Extent bin ich mir schon mal nicht mehr so sicher.
Wenn das, was ich dann als Argument von Extent reinreiche,
wenn das selber ein Iterator ist
und da halt dann irgendwie mit einem Generator
Python-Code ausgeführt wird,
dann kann das halt auch eine Weile dauern, bis ich da durch.
bin. Und in der Zwischenzeit können
natürlich andere Threads dann laufen und
irgendwelchen Quatsch produzieren.
Ja, und jetzt machen wir uns
auf einmal Gedanken über Transaktionen und über
Transaktionsmanagement und das ist dann schon auf
Sprachebene was sehr Spezifisches.
Um die Frage zu beantworten, was für
einen atomaren Counter ich benutzen kann, da gibt's
irgendwie
itertools.counter oder so, heißt es glaube ich.
Und das gilt wirklich als,
also das ist die
Thread-Safe-Variante, um einen
atomaren Counter entfalten zu haben.
Also hätte ich jetzt nicht
gewusst. Ich auch nicht, aber
wir hatten halt Bug-Reports, die gesagt haben,
self.x gleich 1 geht halt nicht.
Ja, genau.
Ich erinnere mich noch, das habe ich vor Jahren
mal diese Meinung
vertreten, dass das Global Interpreter
Log mich davor schützt, dass ich
x plus gleich 1 machen kann, so viel ich will.
Und dann haben wir
im Chaosdorf
an einem Abend das einfach mal ausprobiert
und es stellte sich als falsch
raus, die Annahme, weil man eben sehr schnell
falsche Zahlen rauskriegen kannst.
Darf ich kurz fragen?
Ja.
Das ist selbstverständlich.
Was wissen wir hier?
Also das komplette, wie heißt das, Insider Baseball,
also das hat sich geändert in den letzten Python-Versionen,
also in den letzten C-Python-Versionen.
Du hast absolut recht, dass quasi, also ursprünglich war die Regel,
ein Bytecode ist atomar und aber theoretisch kann ich
nach jedem Bytecode eben einen Thread-Switch haben
und sowas wie
das erwähnte Beispiel
X plus gleich 1, das sind eben mehrere
Bytecodes, das heißt, da kann ich dazwischen
ein Threadswitch haben und entsprechend
ist das nicht atomar. In einer
der letzten Versionen,
ich weiß nicht, 3.12 vielleicht oder so,
haben sie quasi
in CPython die Bytecodes,
wo man Threadswitches
machen kann, also in der
regulären GIL-Version,
stark reduziert.
Und es gibt jetzt eben nur noch ganz, ganz wenige
Bytecodes, wo wirklich dann
Switches stattfinden können.
Das sorgt dafür, dass die
quasi beobachtbare...
Atomarität
zunimmt. Das heißt, plötzlich
in 3.12 war dieses Counter-Beispiel
atomar. Und das ist natürlich
total schlecht, weil
wenn man die Community darauf vorbereiten
will, dass jetzt irgendwann mal der Guild entfernt wird
und man quasi mit
Thread-Switches an viel mehr
Stellen rechnen muss,
ist es halt schlecht, wenn man in der Version davor
dafür sorgt,
dass viel weniger Thread-Switches
an viel vorhersagbareren Stellen, nämlich nur
am Ende von der Schleife oder sowas, stattfinden
kann. Also
das finde ich, also ich meine
klar, dieses Reduzieren der
Thread-Switches, das erhöht halt wieder die
Single-Threading-Performance, das war der Grund, warum sie das
gemacht haben, aber ich finde es
halt unstrategisch.
Also ich glaube, wenn du in 3.12 das mit
dem Counter nochmal ausprobieren würdest, dann würdest du,
das wäre es quasi nicht mehr beobachtbar.
Dann mache ich das jetzt mal nicht, zur Sicherheit.
Mach lieber gleich in der
No-Gill-Version.
Ja gut, aber
damit muss es ja gehen.
damit müsstest du es kaputt kriegen, würde ich
hoffen. Ja, gut, kaputt kriegen.
Ja, also.
Ich habe jetzt leider keine Node-Gate-Version hier
kompiliert, deshalb muss ich leider.
Aber ich glaube, da gibt es auch zum Beispiel so, also es gibt
Packages davon. Ja, ja, also bei
UV habe ich jetzt gesehen, gibt es das auf jeden Fall.
Ja, bei UV, bei Python
inside. Genau. Und in
bei Panf.
In Panf weiß ich nicht, aber in Ubuntu,
in dem Dead Snake
PPA gibt es auch.
Ja, aber ich meine, also
ehrlich gesagt, ich weiß nicht, habt ihr
jetzt alle schon einen Anwendungsfall,
wo ihr unbedingt das mal ausprobieren
wollt, ob dann nicht alles viel schneller wird?
Weil ehrlich gesagt, ich habe das
dann nicht so
wahnsinnig viele Dinge.
Es liegt aber halt vor allem auch daran, dass wir
daran gewöhnt sind, es nicht zu brauchen.
Gut, das kann natürlich sein.
Ich glaube schon, dass es dann
einiges gibt, wo das halt schon
irgendwie auch, klar, man muss dann
sich irgendwie umgewöhnen und vielleicht
gibt es auch ein paar schöne Bibliotheken, die das halt alles
ein bisschen weniger gefährlich machen,
dass man so ein paar schöne Abstraktionen auf jeden Fall
jetzt hat.
Aber ich denke schon, dass wir
an einen Punkt kommen können, wo man dann eben sagen kann,
ja,
also früher hätten wir vielleicht Multiprocessing
genommen und es wäre nervig und
also frickelig gewesen,
das dann gut hinzukriegen und jetzt nehmen wir halt
und es funktioniert gut.
Ja, das
ist halt auch, mit Threads
programmieren ist halt
auch was Gefährliches. Da gibt es ja, also ich
meine, selbst wenn diese Operationen alle
atomar sind und selbst wenn das so ist, dann gibt es ja
immer noch diese ganzen Probleme
und Deadlocks und
Race Conditions und lauter anderes. Und das
ist einfach eine schwierige
Sache. Ich habe kurz, ich habe eben nachgeguckt,
es gibt in PyEnv gibt es eine
3.13.0 Version und es gibt eine
3.13.0T Version.
Und das werden die beiden
und der Schädlichen sein.
Gut, dann muss ich jetzt Boomer installieren.
Genau, und dann muss man ein altes Skript
vom Chaosdorf finden.
Es war
nicht so ein beeindruckendes
Testhahn. Es war einfach nur
zwei Threads, die eine Variable gleichzeitig
erhöht haben. Also das kann man relativ
leicht wieder rekonstruieren.
Ja, ich sehe das auch so.
Ich bin,
ich habe so sehr gemischte Gefühle,
was das Free-Threading angeht. Einerseits ist es halt
cool, weil endlich diese endlose Diskussion
aufhören auf der einen Seite und weil halt auch
wirklich jemand mal Geld in die Hand genommen hat und das
richtig gut macht. Also
richtig gut, klar, da kann man dann auch Details
kritisieren, aber die Tatsache, dass jetzt eben
irgendwie einige Leute
von Meta dafür bezahlt werden, das
halt wirklich zu machen und auch
quasi den Aufwand
betreiben, das in C-Python reinzukriegen, was ja
auch wirklich immer viele Diskussionen
und viel Überzeugungsarbeit und viel
Debugging und sehr, sehr viel Aufwand
sind
dafür nötig und ich finde es erstmal gut,
dass das halt jetzt passiert und
dass quasi auch die
Community mitgenommen wird und irgendwie
verschiedene, also es gibt ja
jetzt wirklich auch schon einige an Bibliotheken,
die jetzt mitziehen und gucken, dass sie halt auch
FreeThreading-Versionen dann
Binary auf PyPI releasen
und so weiter. Und das
ist schon wirklich
gut. Klar, auf der anderen Seite sehe ich
das, ich denke
wirklich, das wird
eine Riesenumstellung und das wird schon auch
was die Bugs angeht und was die
Eingewöhnungszeit angeht und
sowohl in den Bibliotheken als auch in der
Sprache selbst.
Ich habe mal so einen, das ist schon ewig her,
aber ich habe mal einen Vortrag gehört von einem
der
Sun JVM JIT-Entwickler,
der auch in einem ganzen Laufzeitsystem
und dem
Multithreaded Garbage Collector
und so gearbeitet hat und der meinte so,
im Garbage Collector findet man halt
zehn Jahre lang Multithreading-Bugs
und die werden halt immer schwieriger
zu finden und
ich weiß halt nicht so genau, ob
wir darauf so richtig gefasst sind.
Also anders.
Ja.
Naja gut, hat halt ein bisschen
Zeit noch populärer zu werden, dann steigt
die Wahrscheinlichkeit, dass man die Bugs findet, das ist doch gut.
Dann kann man auch schwierige Bugs finden.
Ist jetzt schon auf dem Tyobi-Index
ganz oben.
Also ich sehe es so ein bisschen,
hat ein bisschen eine andere Perspektive. Ich glaube,
die Möglichkeit, Multithreading
zu machen, eröffnet eine ganz
neue Klasse an Programmen, die man
mit Python bisher nicht schreiben konnte.
Spiele wolltest du 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
Erlang-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-Problem heraus.
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 das bedingt sich so ein bisschen selber.
Das ist so ein Catch-22.
Du kannst es 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 Pepp auch geguckt,
wo begründet wird, warum will man das eigentlich haben.
Und da war zum Beispiel ein Beispiel, was ich dann auch einleuchtend 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-Umfelder Firmen gesagt haben, also 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, müssen da irgendwie so ein bisschen das irgendwie mal 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 sauteuer, 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 GIL, weil 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 wollen 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, tja, 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 keine Ahnung.
Ja, aber da würde ich sagen, damit bist du mit Async
schon, 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
deine OTP...
Ja, genau, die fahren auch
eine Reihe von Prozessen hoch und haben dann halt
eine schlaue Art irgendwie, die miteinander kommunizieren
können. Und intern machen die halt
einfach, das kannst du mit Falken ganz
genauso machen. Startest du auch mehrere Prozesse
und machst in jedem einzelnen Prozess
dann irgendwie
korroutieren.
Das ist nur nicht so
üblich, aber könnte man wahrscheinlich tun.
Also ich meine, ja, diese...
Async ist ja jetzt auch nicht gerade eine
uralte Entwicklung.
Diese Probleme gibt es ja auch schon lange.
Und Async ist ja auch noch eine Version,
das zu lösen. Auch mit Vor- und Nachteilen,
muss man auch sagen.
Ja, aber das ist auch...
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, es 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
das, das stürzt die ganze Zeit ab und
Sam Groves hat keine Lust mehr
und dann kann man es halt auch
einfach wieder weglassen.
Also was ich,
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
Agent-Geschichte, es 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
bis heute ist das noch nicht 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
und dann ist das Problem gelöst.
Ja.
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
klappt. Mal schauen, ob sich Dominik fragt, was das bedeutet.
Ja, ich warte nur darauf, dass du es sehr clear
hast.
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 is Dining.
Ja, okay. Ja, zwei Gabeln.
Very fine dining.
Und auch geteilte Gabeln
ist auch absolut, 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.
Das 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üssel Spaghetti und die haben gleichzeitig zwei Enden einer langen Spaghetti im Mund, weil die...
Das ist das Disney, die Disney-Variante, ne, 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 in die zweite kommen.
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 vollen Teller.
Deadlock quasi.
Und das ist ja eine extrem simple Situation, das ist ja eine extrem vereinfachte Sichtweise.
Du meinst, wir müssen miteinander reden und sagen, gib mir mal eine Gabel, bitte.
Ja, aber tatsächlich, Threads, die kommunizieren, sind ja auch was extrem Schwieriges, insbesondere wenn die gerade auf einen Lock warten, weil üblicherweise, wenn so ein Thread auf einen Lock wartet, kann er ja derweil nichts anderes machen.
Das ist dann blöd. Hat den 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 Deadlocks machen.
Mehr Karten verteilen?
Ja, das wäre eine Möglichkeit, aber normalerweise ist das schwierig. Also zum Beispiel in dem Modell vom Jochen einfach mehr GPUs einbauen, ist prinzipiell eine Lösung. Ist nicht ganz billig. Und es sind halt goldene Gabeln, 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? 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 so.
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.
Ja, kennt ihr das, wenn irgendwie an so einem Festival-Eingang
irgendwer stehen muss mit so einem Klicker,
wenn man draufdrückt, muss jemand reinrennen oder wenn man
an der anderen Hand jemand rausrennt,
also ich bin ja auch so sicher, der verdrückt sich die ganze Zeit
Irgendwann, man weiß gar nicht so genau, wie viele Leute
sind eigentlich auf dem Gelände, sondern es ist wahrscheinlich
ein ähnliches Problem. Wenn es so 18 Eingänge sind,
dann finden die dann raus, jetzt sind
gerade minus 10 Leute bei uns auf dem Festival.
Das ist doch 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 Threading ist
eine Riesensache. Man kann es ja mal positiv ausdrücken.
Die Hoffnung ist, dass es jetzt eben ganz, ganz tolle
Abstraktionen geben wird, die dann auf
der quasi Low-Level-Basis
von Threads
und Logs und was weiß ich, was es dann
eben an Infrastruktur gibt oder
geben wird, die das
unwahrscheinlicher machen, dass wir Deadlogs 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 sie für geniale Lösungen
findet. War das jetzt sarkastisch
oder nicht?
Die Zeit wird es zeigen.
Das möchte ich in Folge
600 besprechen.
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 Schnabelpolitik weggeht
und sich mal die Top 100 bei PI anschaut
oder so, dann wird es dann auch mal 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.
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 der 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-Op,
Chunk, CGI, CGI-TP,
Crypt, Image-Header,
Mail-Cap, MSI-Lib, NIS,
NETP-Lib, OSS-Audio-Dev,
Pipes, Sound-Header,
SPWD, SunAU,
Telnet-Lib, UU, XDR-Lib
und Libs 2-3.
Falls es jetzt konstruktiv gefallen
sei, weil euer Paket auf einmal weg ist,
dann solltet ihr aufpassen mit dem Update.
Genau, also wenn da jetzt was dabei war, was ihr gerne
haben wir. Ich glaube, die landen da auf PyPI.
Ja, ja, die gibt es doch.
Was CPython ja nur erreichen
will, ist, dass sie die nicht mehr maintainen.
Nicht, dass die jetzt verboten
sind und auf gar keinen Fall mehr von irgendjemand
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 also 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 nicht mal raten.
Ja, bei manchen, ja,
Was, keine Ahnung, NNTP-Lib
macht, okay gut, das ist NNTP-Lib.
CGI macht, das weiß ich auch noch, weil wir alt sind.
Ja, gut, da sind wir.
Aber wüsstest du jetzt den Unterschied zwischen
CGI und CGI-TP?
Ich glaube, das eine ist der Trace-Pack.
Ja, aber
Turbo.
SunAU ist so ein altes Audio-Format, oder?
Ja, ich glaube auch. Oh, MSI-Lib
für Microsoft-Installer-Dateien,
auch großartig.
Kennt ihr die meist untergeladene Datei
auf PyPI?
Irgendwas mit
Setup-Tools oder ich weiß nicht.
Okay, keine Ahnung.
Also auf jeden Fall das Richtige,
diese Sachen.
Es gibt so eine Liste, die sagt Botro 3.
Ah, oh, das liegt, ach ja,
das liegt in den Updaten irgendwie
alle zwei Stunden und
da das halt irgendwie eines der Hauptdinger
ist, dass du halt brauchst,
wenn du irgendwas mit
irgendwie AWS oder so machst.
Die drittbestes Boto-Core?
Ja, ja, das ist alles so.
Und Platz 2?
Ja, aber ist das nicht der Grund, warum Pipe.ai keine Statistiken mehr anzeigt?
Naja.
Also da könnte man jetzt denken, das wäre irgendwie wichtig,
aber das ist halt überhaupt gar nichts.
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 verdient.
Also du willst sagen, weil Counter halt zu schwierig sind.
Und nicht nur in der Benutzung,
sondern auch in der Interpretation.
Ja, ich meine,
die Zahl der Downloader ist auch irgendwie so ein bisschen
weird.
1,5 Milliarden
Die Zahl, die da rauskommt, ist halt, wie oft
das geupdatet wird, ist auf jeden Fall ein Faktor,
mit dem da multipliziert wird.
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
neu runtergeladen, wenn sich da irgendwas ändert.
Also, ja, naja.
Ja, wahrscheinlich braucht man irgendein anderes
Metric KPI
für irgendwie, ist das jetzt
irgendwie interessant oder nicht? Aber ich weiß auch nicht, welche.
Github-Sterne.
Auch schwierig.
Metric
KPIs.
Ja.
Es wurde schon mal in einem Podcast erwähnt.
Vielleicht sollten wir da sowas auch
so eine Quartettserie
von machen.
Von den PIPI-Bibliotheken.
Ja, genau. Hast du ein
Quartett mit vier, die besten PIPI-Bibliotheken
oder irgendwas mit den KPIs, kannst du
die ganzen Module da reinbauen, dann kannst du dich
gegeneinander, wer denn kennt, könnt ihr das?
Also meins hat
1,5 Milliarden Downloads.
Aha, 798
sich Megabyte. Mehr Kilobyte größer, genau.
Und Anzahl der Releases
wäre doch auch ein gutes.
Offene Issues.
Ist es besser, wenn es höher ist?
Tja.
Genau, aber
um auf die Dead Batteries zurückzukommen,
ich verstehe es 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
wie soll ich das Detail nicht verwenden?
Ja, aber die hätten ja jetzt auch schon
eine ganze Zeit lang Zeit irgendwie da was
und ich glaube auch nicht,
da ist auch nichts zu uns passiert.
Ja, ich weiß nicht,
haben wir vielleicht nur so kleinere Dinge
oder ich weiß es nicht genau,
gab es noch irgendwas Interessantes?
Typing, ja.
Ein Typing-Simple-Namespace, wolltest du sagen?
Das kannte ich noch gar nicht,
ich weiß gar nicht, welche Version das war.
aber... Ja, du kannst
es auch nicht. Okay. Ja, ich kann es auch
nicht. Simple Namespace
ist ein Dikt, dass man wie Attribute
dann die Keys benutzen kann.
So ein bisschen so ein Name-Tuppe.
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 noch mal kurz
hören und verstehen, warum das so blöd ist.
Ich habe doch schon gesagt, dass ich das zensieren will.
Nee, wir haben
so ein bisschen darüber geredet, welche
Standard-Bibliotheks-Module
uns als Piper-Entwicklern
irgendwie besonders oft Probleme bereiten
und Inam ist da immer mal
wieder so ein
wie heißt es? Eine eierliegende
Wollmilchsau. Ein 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 CPython-Version die Standardbibliothek
dann übernehmen, müssen wir
erstmal irgendwelche Python
Datenmodell-Core-Features fixen,
bevor ihr ihn 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. Ja, mit der Tuple und langsam, das war
mir auch neu. Ja, NameTuple benutzt
halt quasi, wenn man so einen neuen
NameTuple-Typ anlegt, dann
da wird halt auch mit exec dann irgendwie
mit Strings irgendwelche Python-Code generiert
und das mag der JIT 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 Machine-Code übersetzt werden müssen.
Und das sorgt eben dafür, dass
bei Name-Tuple die Performance
oft wirklich sehr, sehr
schlecht war in PyPy. Und inzwischen ist das gefixt,
aber so über so ein paar Versionen
hatten wir mit Name-Tuple immer mal wieder Probleme.
Mit Data-Classes am Anfang übrigens auch,
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 viel
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.
Oh.
genau, ja, Typing
waren auch noch so ein paar Dinge.
Ich bin ja nicht so
der Typing-User.
Die Features sind schon viel zu advanced
für mich.
Ja, ups.
Ja, aber
ich weiß nicht.
Da war jetzt auch Read-Only.
Ja, okay.
Hast du das gerade vor dir?
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.
Das ist wohl für Debugger wichtig.
Hier steht, es 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 es ja so,
das Dictionary, wenn ich da
Keys reinschreibe, dann
das ist wirklich das richtige Global Dictionary.
Und wenn ich danach das entsprechende
Global nachschaue, dann sehe ich auch die Änderung.
Und bei Locals hängt eben...
Und das macht sehr schöne Tricks.
Ja, das macht sehr schöne Tricks möglich. Bei Locals
ist das nicht so. Bei Locals war es eben manchmal so,
dass wenn ich Locals verändere,
dass sich dann die, 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,
nee, verschiedene Python-Implementierungen haben das
auch verschieden dann angegangen.
Also quasi
zwischen Funktionen, Global Scopes, Generatoren,
Core-Routinen, Comprehensions,
Class-Scope, also es gibt da
schon so einiges. Achso,
Code, der von exec oder eva 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 das 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 die einen, aber die Leute, die Debugger dann benutzen, denen gehören wir ja dann doch meistens.
Leider auch, doch tatsächlich.
Print-Debugging. Wir alle, die noch nicht sofort beim ersten Mal perfekten Code schreiben können.
Print-Debugging, mehr braucht kein Mensch.
Kennt ihr diese, das kann ich auch noch nicht, aber ich fand diese Analogie sehr schön.
Ich glaube auch aus der letzten Copyright-Episode, da gab es wohl irgendeinen Vortrag vor langer Zeit, wo jemand gesagt hat, sei kein Bond-Villain beim Debuggen zum Beispiel.
Also Bond-Villain, die machen aber alle irgendwie blöde Fehler, dass sie zum Beispiel irgendwie ständig erklären, was ihr Plan ist oder dass sie halt nicht irgendwie mit der großen Weltraumlaser-Kanone 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 man hätte
lieber den Weltraumlaser nehmen sollen.
Und die Idee ist sozusagen, wenn du debugst,
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, nimmst du das nächste, das geht auch nicht,
dann nimmst du das nächste. Fang lieber gleich mit dem
großen Ding an. Den großen Hammer nehmen und
draufhauen.
Erster Schritt, kannst nicht dein
Produkt schneiden mit dem Weltraumlaser.
Ja, aber die Idee hatte was.
Aber das ist einfach sehr individuell.
Ich kenne auch Leute, die leben nur im Debugger.
Da ist halt einfach der erste Schritt,
ich mache eine Funktion, die ist leer,
und wenn die Argumente reingereicht sind,
dann mache ich erst mal einen Debugger an.
Ich gucke halt, was für Argumente sind das jetzt hier
und wie müsste denn der Code aussehen?
Dann schreibe ich zwei Zeilen mehr und mache wieder einen Debugger rein.
Also in manchen Sprachen ist das ja auch noch viel mehr so, dass man das dann auch, dass die IDE 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, restartet die wieder. Also die Smalltalk-Leute machen das besonders gern, die es noch gibt.
ja, also ich kenne
auf jeden Fall auch in Python Leute, die halt sich das so
angewöhnt haben, dass sie halt
Tests schreiben, die Bagger anmachen und dann
kann man halt erstmal so gucken, was macht man denn eigentlich
für Objekte, was haben die für Methoden und wie,
ja, was macht man denn da jetzt?
NB-Dev so ein bisschen.
Ich habe auch versucht mal
einen zu überzeugen von
Jupyter Notebooks und so, aber ich bin begeistert
davon, dass er dann so, ja, nee, benutze ich nie, finde ich
blöd und dann so, ja, 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, ja.
Wenn man jetzt noch einen Debugger
hätte, der vorwärts und rückwärts steppen kann
und wo man zwischendurch den Code verarbeiten
kann, dann passt das schon.
Ja. 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 Coders 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 erste Version.
Zum Beispiel, dass wenn man so einen 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.
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 gekriegt hat.
Ja, also das sind schon
einige Dinge hier.
Um jetzt meinen Einwurf noch kurz zu retten,
das war eine Präsentation von einem Spieleentwickler,
die sich selber so ein System gebaut hat.
Jochen, du hattest die, glaube ich, auf dem Tomorrow Corporation.
Das war eine super Video.
Die haben sich genau so einen 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.
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
und man hat halt unten quasi beim
D-Bagger so einen Schieber
und das Spiel geht halt mit und man
schiebt den so da und das Spiel läuft rückwärts
und man sagt
da so ganz trocken so zu, ja,
das sind jetzt nicht irgendwie Screenshots oder so, nee, das ist
das echte Spiel, was wirklich irgendwie neu
gerendert wird.
Dann schiebe ich hier mal die Funktion ein kleines bisschen um und lasse das mal
wieder laufen von hier aus und jetzt ist auch
dieser Branch drin.
mal bitte diesen Vortrag.
Ja, kann ich auch in den Show Notes mal verlinken.
Ja, den könnt ihr auch in die Show Notes rein.
Also ich hatte, ich glaube
die Free-Threading-Leute, die
müssen solche Tools auch benutzen, weil es
ansonsten einfach echt zu schwierig ist. Und da gibt's halt
auch für C, so Back-in-Time-Debugger,
der, wie heißt der 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-Corrector-Bug hatten und
Und mit so einem Back-in-Time-Debugger kann man halt dann solche Probleme auch richtig gut lösen.
Also das ist quasi so ein Tracing-Debugger, der macht so eine Aufzeichnung der gesamten Prozessausführung.
Das kann man einfach hundertmal machen, bis der Crash stattfindet.
Und dann kann man sich die Ausführungen 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 Anführungszeichen nur ein Replay.
von dem, was eben bei der
crashenden Ausführung wirklich passiert ist.
Und da kann ich
da kann ich dann wirklich auch
ein Backward Next machen und dann bin ich wieder eine Zeile
davor. Oder ein
Backward Finish und dann bin ich
eben am Anfang der Funktion, die ich gerade ausführe.
Oder halt auch so Sachen
wie, ich mache ein 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 ein Watchpoint
setzen, wo du sagst, wer hat
diesen, 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
ziemlich magisch. Es ist sehr magisch. Es funktioniert übrigens
auch nicht, also technisch ist das nicht so
implementiert, dass es wirklich rückwärts läuft.
Weil es ist ja Maschinen-Code, 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.
Ja, gut genug.
Gut genug.
Okay, okay, ich habe hier noch den wichtigsten,
ich habe hier noch den wichtigsten,
die wichtigste Änderung in Python 3.13.
Bei Dockstrings werden jetzt die führenden Leerzeichen entfernt.
Oh ja, das ist ja auch was.
Das hatten wir uns schon angeguckt im Rappel tatsächlich.
Warum? Wofür ist das da?
Wie viel Prozent des Codes ist weniger?
Oder der Byte?
Fünf Prozent.
Fünf Prozent weniger.
Aber einfach, weil es korrekt ist, oder?
Man braucht niemals den Dockstring mit der Einrückung.
Naja, 5% finde ich
ganz schön krass. Also 5% sind Leerzeichen
von eingerückten Dockstrings in
unseren PYC-Dateien. Das ist irgendwie
würde man jetzt
erstmal so nicht erwarten.
Green Development danach.
Das liegt halt daran, dass wir alle so viele
gute und ausführliche Dockstrings
schreiben und ganz viel...
Vor allen Dingen aus Leerzeichen bestehen.
Ja, ich weiß nicht.
Jochen schreibt keine Dockstrings, dem passiert sowas nicht.
Doch, doch.
Naja gut, wenn ich einen Klassen habe,
Methoden-Dockstrings, dann sind die ja schon immer
8 Bytes eingerückt
pro Zeile Dockstring.
Ja, richtig.
Und das müssten ja eigentlich 10% sein,
weil wir gehen ja nur bis 80 Zeichen pro Zeile.
Ist das nicht 79?
Ja, streng genommen
ist es 79.
Ja, oder
79.
Was habt ihr denn für moderne Displays?
80x25, oder?
Wenn du
Python-Modus 4 auf deinem T64 schreibst.
Es gibt Leute,
die müssen auf ihrem Handy entwickeln.
Ich habe PyPy auf meinem Handy.
Ach, okay. Wie geht das denn?
PyPy ist
tatsächlich ein Paket auf
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 PyPyJIT jetzt gerade auf
für den Python-Code, den man auf dem Handy
laufen ließ,
erzeugt wurde.
Wenn man die richtigen Umgebungsvariablen weiß.
Aber Thermux kann das leider noch nicht, dass man mit dem Daumen
hoch und runter machen kann mit dem interaktiven
neuen. Nein, nein, aber das ist Scrolling
und ich meine jetzt durch die einzelnen Zeilen durch
vom Editor, vom
History Edit.
Ich glaube, achso, du meinst so
in der Konsole, ne, glaube ich nicht.
Ja, schade.
Habe ich, also jedenfalls
zu dem Thermux habe ich auch eine,
weiß nicht, 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, also
Forschern und Forscherinnen, die sich mit
Compilern und Optimierung
und Programmiersprachen und so auseinandersetzen
und da war ich dann mit einem relativ
bekannten C-Compiler
Prof, oder John Reggeier
heißt der, auf so einem Boot
in Kopenhagen Bier trinken, also
das Boot lag am Hafen,
man konnte auf Deck Bier trinken und
hab 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 Extraoperation, die braucht er doch gar nicht.
Und das war absolut
richtig und
Und der Grund war, dass die Divisionen 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 es. Ich würde sogar fast sagen,
das ist fast der Schluss von Thema 13.
Ja, ich glaube, wir sind mit dem Thema eigentlich mehr oder
weniger durch. Dann
können wir eigentlich noch mal zu einem
welchen Teil
wechseln. Wir konnten
zum Beispiel
ein bisschen
Meta-Geschichten
machen. Meta-Geschichten?
Ja, zum Beispiel hatten
wir Anfragen nach
Ach, das ist also ein Satz Meta-Geschichten.
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
sagen wir mal so, man kann
einfach eine Mail an
hallo.vereinenpodcast.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.
Und genau,
das ist eine Geschichte.
Dann gab es eine Nachfrage nach...
Ich würde das gerne noch
erweitern, also falls da fünf Mails
kommen, die sich im Stuttgarter Raum
treffen wollen.
Oh je, vielleicht müssen wir uns in der Mitte treffen,
irgendwo in Frankfurt oder so.
Ja, in Frankfurt?
Nee, das ist
bimodal, oder? Das ist Düsseldorf oder
Stuttgart und dann kriegt man das hin.
Alles klar.
Da, wo sich mehr melden, da müssen
wir dann hin. Da ist zuerst.
Aha.
Da ist zuerst.
Ja. Okay, mal schauen.
Ich bin mal gespannt, ob sich da jemand meldet.
Das könnten wir machen.
Genau. Ja, dann hat sich...
Sollen wir T-Shirts machen, Jörg?
T-Shirts.
Ja,
ja, können wir
auch machen.
Hat sich da gerade jemand freiwillig
gemeldet?
Müssen wir mal schauen.
Ja, genau.
Eine andere Anfrage war
von jemandem, der irgendwie alte 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 draufgucken,
weil tatsächlich haben wir das und
ja,
wir haben das aber nie kommuniziert, dass wir das haben.
Daher
ist da auch wenig los. Genau.
Und...
Wie ist es eigentlich mit den tollen
Transkripten von unserem
Podcast, lieber Jürgen? Ja, da habe ich jetzt
am Wochenende, da gab es den PyDDF
Herbstsprint 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 Taubseiten
es trotzdem hören wollt, könnt ihr uns jetzt auch
also lesen. Ja, genau.
Das sieht aus wie so ein Dokument-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 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, 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 haue einfach die
Spuren getrennt durch Whisper durch
oder so und dann kann ich
auch sagen, wer das gesagt hat.
Und dann habe ich festgestellt,
die rohen 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 so ein bisschen
transformiert und dann passen die ganzen Zeitstempel
nicht mehr und dann geht das nicht. Und Jochen hat nicht aufgehoben
die einzelnen Spuren. Ja, man kriegt von
Auphonic 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
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 Transkripte, da tut sich
was, das kommt jetzt.
Wir hatten das ja irgendwann schon mal so ein bisschen probiert, das war so relativ
fürchterlich, 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 für dich 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 mal 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 habe, das heißt RemBG
oder sowas. Das macht einfach den
Background weg als Kommando-Teilen-Tool von irgendwelchen
Bildern, wenn man das will.
Super praktisch.
Falls man sowas braucht.
Das war's.
Jetzt dürft ihr vernünftige Sachen bekommen.
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.024.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 saytheprime.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 sich einfach mit selber multiplizieren
und dann nochmal wieder eins abziehen, dann 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 lange diese Playlist,
wie viele Jahre die spielen wird?
Wie lange braucht man eine Zeit?
Sie sagen vor, dass man
mit 120 BPM
spricht. Das heißt, es wären
zwei Ziffern pro Sekunde.
Das heißt, es wären
ungefähr 20 Millionen Sekunden.
Das ist gar nicht so viel.
20 Millionen Sekunden.
Eine Million Sekunden ist
ungefähr eine Woche oder so.
Jetzt müssen wir es mal
ausrechnen.
Das ist ein halbes Jahr oder so.
Warte mal, das sind
41 Millionen Sekunden
durch.
243 Tage.
Dreiviertel Jahr.
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
in einer Episode, so in einer kleinen Episode von dieser
Primzah mit sind.
Einfach im Hintergrund laufen.
Die
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 tausend Ziffern an und
das geht dann eben über
so und so viele Sekunden oder
vielleicht zeigt er zehntausend Ziffern in 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
Priebsal nachgedacht, weil es ist nämlich
relativ, ich finde es relativ lustig,
dass man die in Python problemlos
ausrechnen kann. Das ist überhaupt kein Problem.
Einfach mal zwei hoch
136 Millionen zu rechnen,
das dauert quasi keine
bemerkbare Zeit. Das sind so 16 Megabyte
Zahl ungefähr.
Vielleicht ein bisschen ineffizienter dargestellt, aber
die zu printen ist
komplett unmöglich, weil
im 2er-System ist das halt eine sehr einfache
Zahl, das sind lauter Einsen.
Aber
im 10er-System,
um zu wandeln, das ist halt
nicht linear zu machen, sondern das ist irgendwie
N log N oder so.
Und ja,
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 irgendwie ein Security Problem.
Aber selbst wenn man das Feature ausschaltet,
dann dauert es halt einfach zu lang.
Ja.
Zum Glück
kann man die Zahl runterladen.
Auf messen.org gibt es
eine ZIP-Datei, 18 Megabyte.
Falls man die
braucht für irgendwas.
An den Leuten statt X
schicken, statt den X-Sourcen.
So.
Ja.
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.
Jochen, was denkst du denn? Oder CF?
Ich meine, keine Ahnung.
Ich würde ja ungern die Reihenfolge
an völlig
absolut nichts mit dem Thema zu tun haben,
denn Pics
unterbrechen. Ich habe auch einen, der
gar nichts mit dem eigentlichen Thema
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 Subscribe11
in Berlin.
Dieses Crap 10 ist
übrigens schon vier Jahre her oder so.
Fünf, die waren 2019.
Da waren wir auch.
Da gehen wir zunächst auch.
Nix war jetzt gerade fünf Jahre später.
Zwischendurch waren da so leichte
Pandemie-Schwankungen
am Start.
Es war auch kleiner.
Es waren deutlich weniger Leute da als
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, sagten, naja, also klar,
früher konnte man sowas, aber heute geht das ja nicht mehr, weil
Social Media ist ja tot, daher 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,
wir 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.
Auch als Hörer, da waren zum Beispiel
Du meinst die nächste in 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
Person hier auch aus Düsseldorf, die sie
bezeichnet sich als Extremhörerin
und es waren
auch viele Hörer da. Es war sehr schön.
Schöne Veranstaltung. Weißt du, wo die nächste ist?
Auch Berlin.
Gleiche Location, also Weißensee.
Und in Mai...
Wie viele Stunden ist man extrem höher?
Pro Tag?
Ja, viele, viele pro Tag.
20 oder so?
Und sie meinte, ich war
auf einem Hörertreffen
am Samstagabend von einem anderen Podcast
und
da ist halt so, ja, also
es ist immer schwer zu sagen,
wie viele Stunden Podcast ich denn jetzt so höre,
weil ich höre immer auf irgendwie
so zweieinhalbfacher Geschwindigkeit,
worauf alle am Tisch so
ja, 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.
Schnell als 1,5 ist das schon.
Ja, aber inzwischen kann ich das halt auch gar nicht mehr
auf einfache Geschwindigkeit hören,
weil dann denke ich mir so was.
Ja, bei den meisten kostet das für mich auch nichts.
Ich finde es ja total lustig.
Also man gewöhnt sich ja da wirklich total dran.
höre, 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?
Hansel Minutes?
Höre ich
seit Jahren 20%
schneller, die Jingle klingt immer noch falsch.
Ja, es gibt so gute
Dingles, die hören sich auf unterschiedlichen Geschwindigkeiten ähnlich
interessant an.
Ich habe einen Python-Pick.
Es gibt eine super
kleine Studie von Erit Katril, das ist eine
C-Python-Core-Entwicklerin,
die eine Studie darüber gemacht hat,
wie viel
PyPI-Pakete Return,
Break oder Continue-Anweisungen in
Finally-Blöcken machen. Weil es gab
nämlich so eine kleine Diskussion darüber, dass man,
ob man vielleicht, also Except-Doppelpunkt,
also ohne Angabe einer 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 Continuum in Finally
haben ja so ein bisschen so komische Effekte.
Wenn man Return macht, dann wird die Exception geschluckt.
Also wenn ich quasi Try-Finally habe
und der Code
wirft eine Exception und in dem Finally-Block
mache ich dann Return. Dann return
ich halt einfach von der Funktion und die Exception
verschwindet. Und deswegen
hat Irit eben gesagt, sie schaut mal
wie das in,
hier steht irgendwo, wie viele Pakete sie sich angeschaut hat,
die 8000 beliebtesten
PyPI-Pakete
analysiert, eben ein Skript geschrieben,
was die abstrakten
Syntaxbäume durchgeht und schaut, ob eben
das Finally-Block hier mit
break, continue und return
drin vorkommen und dann von Hand analysiert,
wie viele von denen quasi wirklich so sein sollen
und wie viele von denen Bugs sind.
Also es waren 120 Millionen Zeilen Python
und darin waren 200 Fälle von Kontrollflussinstruktionen
in Feinlieblö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
Finally. 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
Katarina 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
ja, zu
Missanwendungen als zu korrekten
Anwendungen führt. Sehr schön.
Ja. Und wenn ihr wollt, habe ich noch
einen mega nerdy Pick. Oh ja.
Es gibt ein Paper,
was ein C-Compiler für eine
sehr kleine Teilmenge von C
nach Shell
übersetzt.
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, warum sie das machen.
Die haben Gründe.
Die haben so Trusting-Trust-Gründe, also damit
kann man halt sicherstellen, dass man keine langlebigen
Backdoors im Compiler hat, aber
die Gründe 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
von solchen Argumenten halte 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 interpretierte und
das sagt jetzt, also das 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.
Ja.
Jetzt könnt ihr auch wieder runterdrehen, eure Geschwindigkeit beim Hören.
Und
wünschen euch einen wunderschönen Tag,
wunderschöne Nacht, wunderschönen Morgen, wunderschönen
Aufdehnen. Bleibt uns gewogen,
hallo at peißenpodcast.de für alles Feedback und so weiter.
Bis bald.
Ja. Tschüss.
Tschüss.