Transkript: PyPy - Just in Time

Ja, hallo liebe Hörer und Hörer, willkommen beim Python Podcast, Episode 48.

Heute geht es um PiPe.

Hallo Jochen.

Ja, hallo Dominik.

Hallo Karl.

Willkommen.

Hallo Karl.

Ja, wir wollen erstmal News machen.

Was hast du denn da, Jochen?

Jetzt muss ich mal ein bisschen hochscrollen.

Ja, also es gab jetzt einen Python Enhancement Proposal tatsächlich, der glaube ich schon, also ich meine, das richtig gelesen zu haben, dass das jetzt schon für Python 3.12 irgendwie ein Compiler-Flag einführen soll, das den Global Interpreter-Log optional macht.

Also die letzte Woche große Neuigkeit.

Also ich glaube, es gibt zwei große Themen, Packaging und irgendwie diesen PEP 703.

Ja, und ich habe dann auch so ein bisschen reingeguckt.

Ich bin ja immer so ein bisschen der Ansicht oder ich habe dir so ein bisschen vertreten, dass ich das eigentlich nicht so ganz nachvollziehen kann, warum das so ein Riesenthema ist, weil ehrlich gesagt betrifft es mich meistens nicht und ich bin eigentlich bisher kaum je in die Situation gekommen, dass dieser Global Interpreter-Log für mich jetzt ein großes Problem gewesen wäre.

Aber ich habe mir den jetzt nochmal angeguckt und tatsächlich, also es gibt da schon viele Situationen, wo einen das halt Ärger machen kann.

Also mein Beispiel war, ich hätte ja mal gefragt, ob jemand ein anderes Beispiel hat.

Also wenn jetzt eine Datenbank in Python schreiben will, dann könnte einem das Ärger machen.

Und es gibt aber noch viel mehr Beispiele und da standen auch welche drin, wo ich dann sagen muss, okay, doch, das hat schon, da haben Leute schon ein Problem dann eventuell.

Gerade so im Data Science-Bereich, das war mir gar nicht klar.

Also ganz wichtig ist da wohl, dass man halt nicht von unterschiedlichen Prozessen aus auf den GPU-Speicher zugreifen kann, tatsächlich so richtig.

Und dann kriegt man natürlich sehr schnell ein Problem, wenn man da nicht mehrere Sets auf unterschiedlichen CPUs laufen lassen kann.

Ja, genau.

Ja, das war so, das ist ganz interessant gewesen.

Aber ist noch voll auch in Diskussion, oder?

So ein richtiges, so einen klaren Konsens gibt es da noch nicht, oder?

Hast du da einen Überblick?

Nee, genau.

Also die Diskussion habe ich mir teilweise angeguckt, aber auch nicht komplett.

Und ob es jetzt wirklich kommt oder nicht, keine Ahnung.

Es stand auch irgendwann ein Zeitplan in dem Pep selber drin, der eher so sagte, ja, also der Plan ist eher, das ab 2024 einzuführen und dann 25, 26 dann halt irgendwann dazu überzugehen, dass halt quasi.

Ich weiß jetzt gar nicht mehr, welche Versionsmad das dann ist.

So 13, 14, 15, ja, 15, dann irgendwann umzusteigen auf per Default ist der Global Interpreter locker aus und dann irgendwann es zu deprecaten und bis irgendwann 2030 oder so wegfallen zu lassen, aber das ist dann halt sehr weit in der Zukunft.

Keine Ahnung.

Und der Plan ist aber erstmal, das quasi hinter einer Interpreter-Compile-Time-Flag zu verstecken.

Ja, okay.

Alles klar.

Das haben wir ja gleich am Anfang so was Schwieriges gemacht.

Vielleicht können wir ja vielleicht nochmal ganz kurz erklären, was nochmal ein G ist.

Ja, soll ich gerne.

Also das Problem ist einfach, dass der Python-Interpreter selber nicht Thread-Safe ist.

Dass quasi die ganzen Datenstrukturen, die quasi der Interpreter selbst verwendet, halt nicht mit irgendwelchen Logs versehen sind, sondern es einfach nur davon ausgegangen wird, in der Implementierung überall, dass zu jedem Zeitpunkt halt nur ein Python-Thread, äh ein Thread wirklich Python-Code ausführen kann.

Und das führt dazu, dass man halt quasi, wenn man Python-Code schreibt, nur von einem Thread aus wirklich gerade ausführt, ausführen kann.

Und dazu, das hat halt die Auswirkung, also es war lange kein Problem, weil halt keiner irgendwie ein Multi-Prozessorsystem hatte.

Aber jetzt, wo es halt Multi-Oc-Core gibt seit 20 Jahren oder so, ist es halt immer wieder ein großes Diskussionsding, dass es halt nicht so toll ist, dass man wirklich Multithreaded-Algorithmen in Python schreiben kann.

Ist das brauchbar zusammengefasst?

Ja, ja, doch, nee, klingt gut.

Und ich glaube, das coole an der PEP ist eigentlich, dass halt wirklich eine Firma, nämlich Facebook, soweit ich das verstanden habe, die den nötigen nicht ganz kleinen Engineering-Aufwand halt mal investiert hat, um sich anzuschauen, wie man denen loswerden könnte.

Also und halt auch das Loswerden ist jetzt gar nicht so das prinzipielle Problem, sondern das Problem ist halt, man will den loswerden, ohne dass Single-Threaded Python viel langsamer wird.

Das ist quasi das Schwierige.

Jaja, weil es gab ja schon mal von Larry Hastings oder so, hatte das, was er jetzt auch fast zehn Jahre her oder so da dieses Gelectomy-Projekt, wo eben halt auch versucht hat, das loszuwerden über so Fine-Grained Locking, weil normalerweise ist halt, also für den Garbage Collector braucht man, also das ganze Reference-Counting ist halt hinter dem Gill oder ist halt der Grund dafür, warum das, warum der Gill das halt schneller macht, als wenn man es halt einzeln locken würde.

Und ja, da war, das war halt immer so, das war die erste naive Implementation war irgendwie so 40 Mal langsamer als mit Gill und dann ist es im Verlauf der Zeit auf 20 mal langsamer runter oder so.

Aber das war halt immer noch nicht wirklich so, dass man das halt verwenden kann.

Und jetzt die aktuelle Geschichte hat angeblich irgendwie so, wie es dann implementiert werden soll in den PEP.

10% Kosten in Single Thread Performance, was ja so, und es gibt halt schon einen Ding, das kann man auch über PyEnv zum Beispiel installieren, ich habe das mal ausprobiert, das nennt sich irgendwie Python Nogil oder so.

Das macht nur 5% quasi Performance einbußen, aber das hat noch ein paar Sachen da drin, die jetzt in dem aktuellen Pap nicht drin sind.

Also und daher wäre das ein bisschen langsamer, aber ja, also so, bei 10% ist jetzt noch nicht so allzu viel.

Es gibt auch noch so ein paar andere Sachen, wie zum Beispiel, man muss jetzt halt da, es gibt dann so ein paar Tricks, die da verwendet werden.

Und einer ist halt auch, dass es jetzt halt immer einen Pointer auf den Thread gibt in jedem Python-Objekt, der das erzeugt hat, weil man, da gab es Köln, zwar sie nur innerhalb der von einem Thread erzeugten Sachen aufräumt oder Reference-Counting macht und dann muss man das dann halt vielleicht nicht mehr locken.

Aber dann muss man halt sich merken, welcher Thread das war.

Und das sind halt ein 64-Bit-Ding.

Und dann hat man noch so einen Pointer auf.

Ich weiß gar nicht mehr genau.

Das sind insgesamt drei Pointer, die jedes Objekt mehr kriegt.

364-Bit-Pointer und das ist natürlich schon irgendwie, das sind halt 24-Byte mehr pro Objekt.

Das ist schon nicht so ohne.

Also speichermäßig ist es auch ganz schön.

Und ja, ja, also es sind halt nur Trade-Offs, ne?

Wenn man es gebrauchen kann, ist es vielleicht gut, aber wenn man es halt irgendwie nicht braucht, dann

kann es auch sehr nervig sein.

Und dieses Application Binary Interface ist halt auch nicht mehr kompatibel, sodass halt man im Grunde halt die C-Extensions, also für jede C oder für jedes Paket, das halt eine C-Extension ist, muss man halt die entsprechend richtige Version installieren für den Interpreter, den man verwendet.

Also man muss quasi jede C-Extensions einmal anfassen und halt zum Teil die C-API-Usage irgendwie dann korrekt machen und die Logs einführen, wenn das nicht Thread-Safe ist.

Also das ist halt möglicherweise schon auch Aufwand.

Okay, also das wird dann tatsächlich ein Breaking Change sein, dann, wenn ich es hier nicht mehr geben.

Das ist dann eigentlich Python 4?

Nee, also sagen wir so, du kannst ja parallel verwenden.

Ja, aber das ist dann irgendwann, das ist in der weiteren Zukunft.

Also das ist halt noch Jahre.

Ja, aber wenn das Python 3.5 ist, das ist Python 4.

Ja gut, ich meine, wenn niemand bis dahin umgestellt hat und es keine Pakete gibt, dann wird man das wahrscheinlich einfach nicht machen.

Wenn es alle schon machen, alle relevanten, dann ist es halt auch nicht mehr so schlimm, wenn man das deprecated.

Also ja, keine Ahnung, ist wahrscheinlich jetzt sehr schwer, da irgendwelche Voraussagen zu machen.

Ich glaube, wir müssen uns nachher einfach aber auf jeden Fall uns merken, dass wir noch ein bisschen über C-Extensions reden müssen.

Oh ja, ich glaube, das

werden wir.

Wer war denn aber bei Facebook nochmal mit dabei?

War das?

Sam Gross oder?

Sam Gross, genau.

Kann es sein, dass du, du hattest vielleicht den Vortrag auf der Europäischen letztes Jahr gesehen?

Ja, ja.

Ich habe nicht so viel verstanden, aber ich habe mir angeguckt.

Okay.

Ja, ja, ist auch ein schwieriges Thema, glaube ich.

Also der, der, der, also einige der Ideen sind auch schon, also diese Geschichte mit den drei Pointern, die es jetzt gibt, es gab ein akademisches Paper dazu, wie man das denn bauen kann.

Und da wurden die diese Informationen, die da drin stecken, in einen Pointer reingefriemelt irgendwie, reinkodiert.

Und das war den Leuten aber dann jetzt hier zu heiß und sagen so, nee, nehmen wir lieber rein, das ist zu gefährlich.

Was können da alles bei Overflows passieren?

Hilfe!

Und also daran sieht man schon, dass es halt, dass sie sich das nicht getraut haben, das einfach so zu übernehmen, es ist kompliziert.

Also, würdest du das Paper bitte auch verlinken?

Das klingt

eigentlich spannend.

Ja, ja, kann ich machen.

Mach auch den Talk von Some Grass von der EuroPython rein, wenn es denn irgendwas schon gibt.

Weiß ich nicht weiß, aber

ich füge das mal hinzu.

Alles klar, mache ich.

Weil er hat das nämlich genau erklärt, wie er das irgendwie so vorhat und dass das schon.

Auch ein spannender Typ.

Ja.

Okay.

Ja, habt ihr noch nicht sowas gesagt, Packaging?

Ja, ich hab noch.

Ja, Packaging.

Ja, das war ein anderes großes Thema, auch so vor zwei Wochen oder so gestartet oder noch ein bisschen länger.

Und das köchelt immer noch so vor sich.

Es gibt einen sehr, sehr langen Thread.

Ich weiß gar nicht genau, wo war das denn.

Das Ding heißt irgendwie Python Packaging Strategy Discussion Teil 1.

Das ist auf Discuss Python-Ralk.

Ah, okay.

Ja, und habe ich nicht ganz gelesen, das war mir dann zu viel, aber es gab, dann haben auch diverse Leute da längere Blogposts drüber geschrieben, was sie denn so denken.

Also ja, das Problem ist natürlich, irgendwie bei allen Umfragen, die man zum Thema Python macht, dann wird das von Leuten, die da nicht so erfahren sind, immer als Painpoint Nummer 1 beschrieben, dass es halt so kompliziert ist und dass man nicht weiß, welchen, was man denn jetzt nehmen soll für welche Tools und wie man die denn jetzt am besten, wie rum man die hält, damit es nicht irgendwie keine furchtbaren Sachen passieren und ja, das ist ein Problem.

Aber es gibt auch keine so richtig einfache Lösung.

Ja, und ich weiß es nicht so genau.

Ich glaube, das Fazit war mehr so, ja, es liegt halt vor allen Dingen daran, dass halt auch Python einfach sehr alt ist und Leute das auf sehr unterschiedliche Art verwenden und man kann es nicht gut lösen, weil man kann nicht allen gerecht werden.

Weil manche Leute brauchen halt sehr feingranulare Geschichten und andere lieber ein Interface und das kann man, ja, wie will man das unter einen Hut bringen?

Das ist schwierig.

Also auch interessant, fand ich genau, ich weiß nicht, ob das in dem Zusammenhang aufgetaucht ist, aber auch jetzt wenige Wochen alt von Nathaniel Smith, ein neuer Paketforscher, Posey heißt er.

Oder Posey, ich weiß nicht genau, wie man es ausspricht.

Das ist eine Rust-Binary, die quasi das ganze Zeugs von Python übernehmen soll.

Also den Interpreter mit ausliefern und Pakete bauen und Dependencies bauen und deren Graphen bauen und so.

Und das sah, fand ich, relativ interessant aus, weil genau das auch eins der Paces, die allen Leuten, mit denen ich irgendwas in Python machen will, erstmal erklären muss, hä, wie geht das?

Oh, das ist aber kompliziert und warum ist das denn so?

Und ja, sobald dann halt, also wenn die einen Python machen, okay, aber wenn die nochmal eine andere Python-Version irgendwann, habe ich es ja später so, geht alles kaputt und Pfad anpassen und ich sag, das ist für einige Menschen gar nicht so einfach zu handeln.

Ja, und Natalia ist auch jemand, dem man quasi den Geschmack zutraut, das richtig gut zu machen.

Also das ist ja also bekannt wie er hat ja Trio geschrieben, also eine andere Implementation für so Async-Geschichten und eine andere Art, das zu machen, er hat auch einen sehr tollen Artikel geschrieben, irgendwie für Structured Concurrency, den verlinke ich auch mal gerne oder Sachleuten, dass sich das mal durchlesen sollen.

Ja, insofern, ja genau, das habe ich auch da direkt aufhorchen, dass man sich gehört hat, wer das gemacht hat.

Ja, auf der anderen Seite weiß ich jetzt nicht so genau.

Also er schreibt, gut, er macht das jetzt in Rust, weil er wollte schon immer mal was für Rust machen.

Ich weiß nicht genau, wo man das unbedingt.

Also alle Leute machen momentan irgendwie Dinge, Tooling in Rust.

Bei JavaScript verstehe ich das so ein bisschen, weil die haben da, also jede Änderung im Code führt halt dazu, dass irgendwie so 20 Transpiler, irgendwelche Linter, sonst was irgendwie loslaufen und Dinge machen.

Und wenn dann jedes Mal so ein fetter Node.js-Prozess gestartet wird, dann dauert das dann, addiert sich das natürlich irgendwie auf in der Latenz.

Aber Python hat man das ja jetzt so eigentlich auch nicht.

Naja, bei MN hast du eine vorkompilierte Binary, die du irgendwie ausliefern kannst und in Rust ist das vielleicht so ein Typensicher und irgendwie ordentlich schnell und verpasst.

Okay, ich glaube, man kann die halt auch relativ leicht dann so statisch verlinken und hat halt wirklich halt nur eine Datei.

Ja, genau.

Ja, okay, ansonsten hat man das Bootstrapping-Problem, dass man erstmal einen Package Manager installieren muss, damit man sich den richtigen Package Manager, also das Problem, was Poetry hat mit dem Curl und Get Poetry schrecklich Shell-Skript irgendwie von der Webseite ausführen.

Ja, okay, gut, das löst es, das stimmt.

Das sind so ein paar Sachen, die glaube ich echt gar nicht schlecht haben.

Also ja, aber Rust ist cool.

Ich habe es auch mal ein bisschen ausprobiert in Advent of Code, aber die Weihnachtszeit ist ja jetzt schon wieder vorbei.

Ich weiß nicht, was wir finde, also ich meine, mein, das, was ich meistens verwende, ist halt für Pakete bauen Flit.

Das macht eigentlich nur das.

Ansonsten verwende ich für Abhängigkeit Pip-Tools und ja.

Ja, Piptools fand ich ja fürchterlich, aber du findest Poetry fürchterlich.

Und was Poetry ist auch für die Fahrt.

Ja, Poetry

länger verwendet, also fürchterlich ist ja.

Der hat Wertness ja, glaube ich, das war schon ein, zwei Folgen her mal über dieses Problem mit den Pint-Dependencies irgendwie schon auseinandergesetzt.

Warum das vielleicht blöd ist, aber ich sag mal so, theoretisch kann man die ja trotzdem einfach dann selber einstellen in der Pi-Project Hummel.

Ja, ja, das Problem ist, dass das Poetry implizit halt, wenn man sagt, Poetry Add irgendein Paket, irgendwie ein Upperbound auf die Version macht.

Ja, das verwendet.

Wenn man eine Library schreibt, für andere halt sehr blöd ist, weil die dann sofort in Dependency-Probleme laufen, Konflikte laufen.

Muss man manuell quasi tatsächlich dann wegnehmen.

Naja, gut.

Ach ja, genau, also mit Pit, ist glaube ich eine gute Idee.

Keine Lösung ist.

Ich habe letztens gesehen, Piptools in PiProject Hummel irgendwie reingemelt.

Ja, jetzt letzte Woche war PyDDF-Treffen und Jans hatte da irgendwie das mal irgendwie erzählt, dass er das jetzt macht.

Er benutzt Piptools, ist auch nicht so super zu, nicht hundertprozentig zufrieden, aber irgendwie das auch häufiger und hat einen Weg gefunden, wie man das relativ einfach, die Einfänglichkeiten auch in der Pi-Project-Tunnel da reinschreiben kann und hat mir mal gezeigt, wie man das macht.

Das könnte ich auch verlinken, stimmt.

Das wird auch nicht so schlecht.

Weil dann hat man alles wieder, weil das ist natürlich.

Also im Moment ist das ganze Packaging und Dependency-Management-Zeugs irgendwie relativ furchtbar.

Das funktioniert auch nicht OS-übergreifend gut und das ist ziemlich ermissen.

Ich hoffe ja wirklich, dass dieses Raspberry einiges ändert, weil das will man so alles nicht haben.

Ja.

Wird uns noch eine Zeit lang begleiten, das sehen wir doch nicht.

Ja.

Okay, kommen wir zu erfreulicheren Ding.

Django gibt es jetzt eine neue Alpha-Version, also die Django 4.2 kommt im März irgendwann, hoffentlich.

Ist das wieder die LTS?

Ja.

Ja.

Genau, wobei das nicht so eine große Rolle spielt.

Die offizielle Empfehlung an der Stelle ist immer, die neueste zu nehmen.

Die letzte Stabile zu nehmen und nicht LTS.

LTS ist mehr so, naja, es gibt halt Firmen, die das irgendwie haben wollen oder keine Ahnung.

Aber das ist nicht mehr so, wie man das machen sollte.

Es wird nicht empfohlen, immer auf eine LTS-Version zu bleiben.

Dafür verdernt sich auch einfach zu wenig.

Also es gibt schon lange nicht mehr irgendwie so große Probleme, wenn man upgradet.

Daher braucht man das eigentlich nicht mehr so wirklich.

Genau, was dabei ist, ist ganz nett Psycho PG3-Support, das heißt Async-Datenbank-Unterstützung kommt damit halt so rückt näher.

Es ist halt, es gibt ja jetzt auch ein Interface, seit Django 4.1 für Async-Geschichten mit dem ORM.

Ist alles noch nicht wirklich implementiert, aber das Interface ist schon mal da, sodass man das halt so verwenden kann, dass wenn irgendwann sich unten drunter das mal so verändert, dass halt mehrere Sachen gleichzeitig irgendwie an die Datenbank geschickt werden und dann also concurrent und dann wieder zurückkommen, das ist einfach so, dass man einfach so davon profitiert ohne dass man selber nochmal was ändern muss.

Das muss ich auch schon mal irgendwann verstehen, wie das mit der Datenbank funktionieren soll.

Naja, du kannst, also im Grunde, der OM weiß ja, was er an Queries an die Datenbank schickt und der schickt dann halt, also was momentan, so der übliche Weg ist halt, dass er halt ein Query nach dem anderen an die Datenbank schickt und die Latenzen sich alle aufaddieren.

Das ist halt so, wie es, was jetzt, wenn man nicht so viele Querys macht und wenn man ein bisschen aufpasst, dann ist es auch nicht so schlimm.

Aber kann natürlich schon sein, wenn man jetzt 50 Queries hat und jede dauert 10 Millisekunden, dann ist man natürlich bei einer halben Sekunde allein Datenbank, Latenz.

Besser wäre es ja, wenn man alle gleichzeitig an die Datenbank schickt.

Oder alle, die nicht voneinander abhängen, kann man gleichzeitig in die Datenbanken schicken.

Und dann hat man, ist die Gesamtlatenz, nur die Latenz von dem Query, was am längsten dauert, sozusagen.

Und das könnte natürlich die Gesamtlatenz deutlich reduzieren.

Also es wäre sehr nett, wenn das irgendwie ginge.

Ja, aber es ist natürlich sehr komplizierte Änderungen.

Aber dann musste die Datenbank ja natürlich schon parallel auch rechnen können.

Ja, das können die, das machen die, das können die alle.

Und wie stellt die Datenbank sicher, dass ich jetzt keine Probleme habe, festzustellen, dass Dinge auf die gleichen Stellen zugreifen?

Ja, das ist ja das, was die Datenbank eigentlich oder das ist ja so die Kernkompetenz eines Datenbankmanagementsystems sozusagen.

Ja, aber das Problem hast du jetzt.

Aber das Problem hast du jetzt ja auch schon, wenn du mehrere Frontends hast oder mehrere Prozesse auf deinem Frontend, die gleichzeitig alle irgendwie.

Ja, aber man muss ja gucken, dass sie ein Lok setzt dann irgendwie und dann muss sie irgendwie gucken, ist das Lock auch da oder muss halt einsetzen, wenn sie da irgendwie dran rumfuchtelt und dann muss ich jetzt wieder.

Also wenn du meinst jetzt so Richtung Write-Zugriff oder was?

Ja, ja, aber ich meine, dann schadest du halt eine Transaktion und siehst, dass dann, du hast eine konsistente Sicht der Dinge innerhalb der Transaktion oder die wird halt dann committed oder abortet und das, das ist, also ich glaube, ich stimme dir zu, dass wir machen zu, dass das halt genau das ist, was die Datenbank halt im Prinzip richtig gut können sollte.

Also so.

Aber das macht ihr doch eigentlich dann langsamer, oder?

Wenn ich halt dann.

Ja, natürlich macht das alles.

Das macht alles viel langsamer.

Wenn man Transaktionen ausschaltet und F-Sync ausschaltet, dann wird das eine Datenbank viel schneller.

Also, aber das Problem ist halt, dann sind halt deine Daten eventuell auch weg.

Das ist ja doof.

Das ist auch wieder doof.

Wieder so ein Trail auf der Arten.

Also dieses Problem hast du auch, wenn du zwei Frontends hast, die auf den gleichen Daten arbeiten, hast du das ja auch schon.

Auch ohne, dass die Frontends in sich selber nochmal irgendwie Concurrent-Dinge machen.

Die machen ja auch Sachen concurrent auf Prozessebene oder auf Rechnerebene, die da auf die gleiche Datenbank zugreifen.

Also das sollten die Daten, das sollte eine Datenbank schon können.

Ja.

Also das ist gut, man hat nochmal ein bisschen Probleme, weil zum Beispiel Postgres kann halt nur, oder dieses, es kommt darauf an, welches Protokoll man verwendet, aber das Textprotokoll von Postgres kann halt nur eine Query gleichzeitig beantworten.

Das heißt, bisher war das kein Problem, weil man kann sowieso immer nur Imput synchron eins nach dem anderen machen.

Aber jetzt kann man ja mehrere, das heißt, man muss auch mehrere Verbindungen aufmachen, weil halt immer nur ein Query pro Verbindung geht.

Das heißt, da muss man dann, Django muss dann halt intern poolen oder muss irgendwie ein Außenpool verändern.

Es ist sowieso alles sehr kompliziert.

Auch die ganze Geschichte im ORM, was man dann umstellen muss, ist alles noch, das wird noch lange dauern, bis das alles richtig funktioniert.

Aber wenn es dann mal irgendwann funktioniert, sehr cool.

Und es ist jetzt ein weiterer Schritt dahin.

Also wir haben jetzt also in URM, Async Views, Async Tests.

Jaja, also in ORM haben wir noch nicht.

Wir haben nur die Interfaces.

Jetzt auch den Support für eine Library, die man dafür braucht, um das überhaupt machen zu können.

Das heißt, das letzte, was dann für UM dann.

Genau, aber das ist halt auch noch das komplizierteste Stück Arbeit, was noch da bevorsteht, genau.

Ja, dann gibt jetzt Unterstützung für Kommentare, für Spalten und Tabellen.

Das ist irgendwie ein Issue, der ist seit Jahren offen und war irgendwie kompliziert zu fixen, ging nicht so gut.

Aus welchen Gründen auch immer, ich weiß gar nicht genau.

Das geht jetzt.

Also sie haben irgendwie einen Weg gefunden, wie sie das so hinkriegen, dass es kein Problem mehr ist.

Und das ist was ganz nettes.

Dann früher oder ab dann wird man halt eventuell das, es gibt so Django In-Memory Storage, ich weiß es nicht genau, gibt es ein externes Paket nicht mehr brauchen, das ist dann auch in Django selber drin.

Das heißt, man hat jetzt ein In-Memory Storage Backend für Django mit dabei, das man einfach so verwenden kann für Tests zum Beispiel.

Macht halt Tests einfach schneller.

Und, das freut mich besonders, es gibt jetzt eine Streaming-HTTP-Response mit Async-Iteratoren dran.

Das ist im Grunde, wenn man jetzt zum Beispiel Files ausliefern will, ist das halt ein Problem.

Das ging bisher nicht so gut, einfach deswegen, weil man da halt über die Blocks eines Files, die man rausschicken wollte, halt da so in nicht Async drüber iteriert hat.

Und genau, ich habe da ja mal auf der Django 2021 einen Vortrag, wie kann man eigentlich Files mit Django Serven gehalten.

Da habe ich das halt, dieses Ding rausgepatcht, irgendwie so per Monkey-Patching.

Es gibt noch ein Paket Django File-Response, wo ich das so mache.

Das ist dann nicht mehr nötig, weil das macht jetzt ASOG-Iterator.

Das heißt, es müsste eigentlich File-Surven müsste jetzt einfach so gehen.

Ja, das ist natürlich auch sehr cool.

Wir haben noch ein paar Konferenzen.

Von zwei weiß ich jetzt schon die Daten.

DjangoCon EU ist irgendwie 29.

Mai bis 2.

Juni 2023 in Edinburgh.

Edinburgh, ich weiß gar nicht, sprechen wir es auf.

Edinburgh.

Tja.

Und PyCon.de PyData ist in Berlin.

17.

bis 19.

April, da gehe ich wahrscheinlich auch hin.

Europeißen es vom 17.

bis zum 23.

Juli.

Okay.

Aber ich weiß nicht wo.

Okay, ja, Top Secret.

Damit auch ja keiner einen guten Flug buchen kann.

Genau.

Das wird in Europa passieren wahrscheinlich.

Oder das ins Budget fürs Jahr einplanen kann.

Für was auch immer.

Ich habe gerade das Management Team hat da gewechselt.

Ja?

Ja, also die letzte hat noch Markandrie mit organisiert und jetzt machen das irgendwie andere Menschen.

Okay, was ist.

Die haben so eine neue Art und Weise, wollen die machen, mit wer das wie veranstaltet und sich was ein neues Konzept da überlegt.

Mal gucken, ich bin gespannt.

Jojo.

Okay, ja, nee, dann, äh, da sind wir ja nach nur fast 20 Minuten mit den News durch.

Diesmal relativ flott.

Dann kommen wir zum Punkt.

Das ist eine ganz schnelle Folge.

Das glaube ich nicht.

PiPi?

Ja.

Warum macht.

Ja, die Folge ist ja PiPi.

Mach mal damit nicht was schneller oder was ist der Zweck davon?

Oder weißt du was, womit wir anfangen?

Karl, wer bist du denn eigentlich?

Hi.

Hi.

Hallo, ich gebe mir schon die ganze Zeit so meinen Senf dazu.

Aber ja.

Also ich bin Karl Friedrich Bolz der Eck.

Ich bin hier an der Uni, ein wissenschaftlicher Angestellter in Düsseldorf.

Und habe da eine halbe Stelle und bin im Prinzip angestellt, um eine Python-Einführung zu erhalten jedes Semester für Leute, die nicht Informatik studieren.

Also das ist so Studium Universal-mäßig.

Und wenn ich die mache, gemacht habe, kann ich die restliche Zeit so ein bisschen frei einteilen.

Das ist eigentlich ein ganz angenehmer Deal.

Und ich bin seit irgendwie 2005 ungefähr einer der Kernentwickler des Piper-Projekts, über das wir jetzt auch dann gleich noch mehr reden wollen.

Also ich habe da halt irgendwie am Anfang vor meinem Studium angefangen.

Ich war dann auch bei den EU-Projekten, die da am Anfang eine Zeit lang für Finanzierung gesorgt haben, recht intensiv involviert und bin halt so mit mal mehr, mal weniger Involvierung seitdem immer wieder halt daran beteiligt.

Und ja.

Also an dem Open Source Fund-Ding, was dann PiPy direkt entwickelt.

Genau, also ich bin jetzt quasi einfach erstmal nur so quasi in Anführungszeichen, also nur einer der Kernentwickler, also die halt quasi Commit Rights und Zeug machen.

Ich bin aber halt auch einer der recht aktiven im Moment.

Also das Projekt schrumpft so ein bisschen, da können wir vielleicht später auch noch drüber reden.

Und ich bin einer derjenigen, die jetzt halt gerade noch recht viel machen.

Genau, aber das Projekt hatte über seine Lebenszeit halt immer wieder auch Phasen, wo das wirklich auch viel Geld hatte.

So EU-Förderung, Forschungsförderung, immer mal wieder auch Geld von Firmen und bei einigen von diesen Forschungs oder Förderungsprojekten war ich halt auch dann quasi aktiv dabei.

Da musste auch mal direkt erzählen, was PyPy überhaupt ist.

Ja, genau.

Also da genau, das ist jetzt quasi die andere Frage.

Also PyPy ist quasi eine Alternative für CPython.

Wenn man halt irgendwie Python in Python seine Programme schreibt, dann geht man halt normalerweise auf Python.org und oder vielleicht kriegt man das auch irgendwo anders her, aber man hat halt ein Executable, das heißt Python 3 in der Regel oder Python.

Das führt man aus und dann kriegt man halt irgendwie seine Shell und kann da Python-Code eingeben oder kann halt damit dann auch Python-Dateien ausführen und kann auf diese Art und Weise irgendwie seine Programme laufen lassen.

Und dieses Programm, das wird halt von den Kernentwicklern der Sprache Python geschrieben und das gibt quasi vor, wie sich die Sprache entwickelt.

Und das ist in C geschrieben, also dieses Programm ist in C geschrieben und deswegen kann man das halt auch, um es von der Sprache zu unterscheiden, kann man das halt auch C-Python nennen.

Also das ist quasi so ein bisschen so ein Terminologiet, dass man halt quasi die Sprache und die Implementierung, dass man denen zwei verschiedene Namen gibt.

Also Python ist halt dann die Sprache und das ist quasi erstmal so eine abstrakte Entität und dann gibt es aber halt die konkrete Implementierung, die man fast immer verwendet und das ist halt CPython.

Und C-Python funktioniert jetzt so, dass es halt ein Interpreter ist.

Also wenn ich jetzt damit irgendwie meinen Python-Code ausführen will, dann gibt es so ein bisschen so einen versteckten Bytecode-Compiler-Schritt.

Also der Python-Code wird dann irgendwie analysiert und geparst und in so ein Bytecode-Format übersetzt und dann werden auch so PY-C-Dateien irgendwo auf der Festplatte auch noch so ein bisschen zwischengespeichert, damit man das nicht jedes Mal machen muss.

Aber dieser Bytecode, der wird halt dann jedes Mal von einem Interpreter ausgeführt.

Und was Pyper jetzt ist, ist quasi der Versuch, Python-Code schneller zu machen.

Also es ist ja immer so ein bisschen so ein Meme, dass Python halt irgendwie besonders langsam sein soll.

Und PyPy ist halt ein Forschungsprojekt oder halt auch ein Open Source-Projekt, mit dem man eben das Ziel erreichen können möchte, dass man den Python-Code einfach unverändert viel schneller laufen lassen kann.

Und das macht man eben so, dass man eben sich sein Binary nicht von Python.org runterläddt, sondern von PyPy.org.

Man kriegt dann ein Binary, das heißt halt irgendwie PyPy.

Und das verhält sich erstmal eigentlich ganz genau so, idealerweise quasi ununterscheidbar so, wie der Interpreter, den man von Python.org kriegt.

Vielleicht nochmal ganz kurz, PyPy ist nicht PyPI?

Genau, also PY, PY.

Also das ist so ein bisschen doof, dass die so ähnlich sind, aber.

Ja, weil man von PyPI ja auch viel runterlädt, man das irgendwie.

Genau, ja, ja, absolut.

Also aber PyPI lädt man quasi in Python geschriebene Bibliotheken runter, die dann auf der Python-Implementierung laufen, aber PyPy ist eben wirklich das Binary, also die Excel-Datei sozusagen.

Also was ich mir erzählt, eigentlich war diese, weil ihr relativ gleich alt seid als Projekte, war die Unterscheidung früher gar nicht so einfach, weil das andere waren die Cheesecakes.

Genau, also der PyPI hatte halt vorher dieses Cheese Shop-Bringing, weil das ist so ein Monty-Python-Sketch mit dem Cheese Shop, wo man halt keinen Käse kaufen kann.

Ich weiß nicht, ob du das kennst.

Ja.

Da geht halt der Kunde dann so ganz viele Sorten durch und die gibt es aber alle nicht.

Und kennst du auch das Wortspiel mit den Wheels?

Nee.

Naja, im Cheese Shop gibt es halt Käseräder.

Ja.

Und die Wheels sind halt Käse.

Okay, ah.

Also, ja.

Okay, das heißt, im Käse-Shop gibt es die Wheels.

Ja, okay, verstehe.

Und deswegen gibt es Wheels auf Pipe PI.

Genau, und

irgendwann haben die halt dann aufgehört mit diesem, weil Cheese Shop ist halt doch sehr idiosynkratisch oder verspielt, ist vielleicht eine positive.

Der erste Draft-Name von unserem Podcast war The Ministry of Silly Talks.

Ah ja, alles klar, nicht schlecht.

Also irgendwann wurde halt Pipe PI dann ein bisschen ernsthafter und hat halt angefangen, dann sich nicht mehr The Cheese Shop zu nennen.

Und dann wurde halt die Verwechslungsgefahr plötzlich dann auch akuter.

Aber weil halt PiPI und PyPy ziemlich genau gleich alt sind, also PiPI ist ein kleines bisschen älter, so ein paar Monate oder so, hat man halt beide Projekte nicht so richtig eingesehen, sich jetzt umzubenennen.

Und deswegen müssen wir dann jetzt halt mit dieser Verwirrung leben.

Genau, also wir waren an dem Punkt, man kann von PyPy.org sich ein Binary runterladen, das heißt PyPy.exe unterwinteres oder halt einfach nur PyPy.

Und das verhält sich eigentlich idealerweise ganz genau so wie das Binary, was man von Python.org kriegt.

Man kann damit Python-Code ausführen, man kann damit einen interaktiven Interpreter kriegen und alle Command-Line-Switches sind die gleichen.

Und es verhält sich genau gleich.

Mit dem einzigen Unterschied, dass der Python-Code, den man damit ausführt, halt hoffentlich

schneller ist.

Was ist mit Paketen und Libraries und so weiter?

Genau, also alles, was quasi in Python geschrieben ist, sollte halt gehen.

Wir haben natürlich ab und zu Bugs.

Also irgendwie, es gibt immer irgendwelche super spezifischen Feinheiten, wo man dann halt doch so ein bisschen Verhaltensunterschiede finden kann.

Aber so der Anspruch an uns selber ist halt, dass wir quasi wirklich das komplette Verhalten der Sprache eins zu eins nachbauen.

Und zwar bis in die Bugs rein.

Also es gibt halt immer wieder so Randfälle, wo man dann anfangen kann zu diskutieren und sagen kann, naja, was ist denn jetzt mit diesem Randfall?

Könnte man dann nicht argumentieren, dass CPython da halt irgendwas komisches macht?

Aber das machen wir halt nicht, sondern wir sagen halt immer, im Zweifelsfall bauen wir halt auch die ganz, ganz komischen Sachen nach, weil es stellt sich halt raus, dass irgendjemand verlässt sich so ein bisschen auf alles.

Also es gibt eigentlich keinen Randfall, der so merkwürdig ist, dass es nicht eine Bibliothek gibt, irgendwie eine kleine vielleicht, die halt sich dann beschwert, wenn man das kaputt macht.

Also selbst wenn man halt dann sagt, na, wir sind aber viel konsistenter und das macht ja so viel mehr Sinn, nee.

Das ist halt doof.

Für so eine Bibliothek ist es doof, wenn sie halt dann so unterscheiden muss, auf welcher Python-Implementierung sie jetzt gerade laufen.

Und deswegen versuchen wir da halt auch nichts mehr zu verbessern oder irgendwie.

Ja, es gibt natürlich trotzdem Stellen.

Also wir haben halt dann, was weiß ich, mal eine leicht andere Federmeldung in irgendeinem Fall oder so.

Sowas kommt halt schon vor.

Aber vom Anspruch her sollte sich halt genau gleich verhalten.

Und der einzige Unterschied ist quasi wirklich idealerweise, dass bei uns die Programme halt viel schneller laufen.

Und warum macht man das dann nicht direkt immer mit PiPy alles?

Ja, also genau, jetzt können wir so ein bisschen über die Nachteile reden.

Also das eine ist halt, wir sind halt nicht die maßgebende Implementierung, die jetzt die Evolution der Sprache selbst vorgibt.

Also C-Python hat halt so eine Doppelfunktion.

Das ist einmal die Default-Implementierung, die halt von fast allen verwendet wird.

Aber auf der anderen Seite ist es halt auch die Gruppe an Leuten, die letztlich darüber entscheiden, in welche Richtung sich die Sprache weiterentwickelt.

Weil in jeder neuen Version von C-Python ist es ja so, dass da eben nicht nur irgendwie technische Verbesserungen an der Implementierung gemacht werden.

Das kommt natürlich auch mal vor, also jetzt sind drei Elf zum Beispiel ganz toll.

Aber insbesondere gibt es da halt auch bei jeder Version irgendwelche neuen Sprachfeatures.

Das heißt, python.org, diese Community, die ist halt für zwei Sachen zuständig.

Einmal dafür, dass das alles funktioniert, aber auf der anderen Seite eben auch für so Fragen wie, welches Pab nehmen wir an, welches neue Language-Feature wollen wir haben, welche neue Stahlbibliothek, so Geschichten.

Und da, also da sind wir halt raus.

Also aus diesen ganzen Sprachdesign-Fragen, da haben wir keine Meinung zu.

Ihr nehmt euch dann einfach das letzte Office-ZBDs und dann ist das ein C-Python und baut das dann eure Änderungen ein.

Genau.

Und es ist schon dann mal so, dass wir bei den C-Python-Diskussionen dann auch mitreden und sagen, ja, aus unserer Sicht hat das DD, also gibt es jetzt hier diese Trade-Offs oder so.

Aber also wir versuchen uns halt so erstmal aus Sprachdesign-Fragen auch irgendwie erstmal rauszuhalten.

Also einfach auch, weil das unser Leben so ein bisschen leichter macht, dann gibt es halt, ich meine, ich habe da natürlich dann quasi so privat auch manchmal eine Meinung dazu, was es jetzt an Featern gibt und manche finde ich cool und manche finde ich weniger cool.

Also ich meine, das geht ja allen Python-Programmierern so, dass man halt eine Meinung hat.

Aber wenn ich dann quasi meinen PiPy-Hut auf habe, dann versuche ich diese private Meinung halt dann auch zurückzunehmen und zu sagen, das ist jetzt halt so, das ist Teil der Sprache und das implementieren wir jetzt halt.

Also du bist ja eigentlich gar kein Dann Python-Programmiere, hast du selber gesagt.

Ja, über die Architektur reden wir gleich noch.

Also irgendwie dann schon, aber halt auf eine bisschen indirekte Art und Weise, genau.

Also ja, ich wollte noch was zu den Versionen sagen.

Wir sind immer so ein bisschen hinterher.

Das ist nicht so gut.

Also eigentlich haben wir so ein bisschen den Anspruch, dass wir quasi eine Major-Version hinterher sind.

Weil, also wir können halt nicht Schritt halten.

C-Python hat halt einfach viel mehr Leute und die rennen uns halt davon.

Und was halt so ein bisschen unser Ziel ist, ist, dass wir quasi immer so eine Major-Version hinterher sind.

Das ist auch immer ganz gut, wenn dann quasi 3.11 rauskommt, dann haben so langsam alle Bibliotheken sich darauf eingestellt, dass die 3.10 supporten.

Und wenn wir dann auch mit unserer 3.10 rauskommen, dann passt das so ganz gut zusammen.

Gerade sind wir ein bisschen mehr, also wir haben jetzt nicht so krass getaktete Releases wie C-Python, sondern das wird halt, also wir machen alle paar Monate ein Release, aber das heißt nicht unbedingt, dass dann auch die neue C-Python-Version supportet wird.

Und gerade sind wir so ein bisschen hinterher, also 3.9 ist jetzt eigentlich sehr, sehr stabil und 3.10 ist in der Mache, aber noch nicht released.

Und danach kommt halt dann 3.111.

Also das ist quasi ein Nachteil, warum man PiPy halt nicht nehmen sollte, ist ein bisschen hinterher.

Und dann habe ich vorhin gesagt, naja, jedes Python-Programm sollte halt gehen und idealerweise schneller sein.

Da gibt es jetzt zwei Fußnoten an dieser Aussage.

Die eine Fußnote ist halt C-Extensions.

Aber NumPy ist kaputt?

Nee, kaputt halt nicht.

Also inzwischen ist das so, dass wir so eine komplette Kompatibilitätsschicht haben, mit der, sag ich mal, 80% aller in C geschriebenen Bibliotheken in Pipeline auch gehen.

Aber das ist wirklich, wir emulieren halt dieses Interface.

Für C Python ist das Interface halt wirklich genau so, wie der Interpreter auch wirklich funktioniert.

Und der Interpreter benutzt halt Reference Counting und die C-API, die hat halt überall die Tatsache, dass das Reference Counting ist, exposed.

Es gibt halt ein Increase-Reference Count-Makro und ein Decrease-Reference-Count Makro.

Und alle Libraries, die dann gegen diese API implementiert sind, die müssen das halt überall auch korrekt verwenden.

Aber bei uns ist es so, dass wir unseren Speicher halt nicht mit Reference-Counting verwalten.

Das heißt, wir müssen dann für die Bibliotheken so tun, als hätten wir einen Reference-Count.

Und das ist halt, das kostet halt so ein bisschen Performance.

Das heißt, bei uns sind in C geschriebene Erweiterungen halt quasi, die funktionieren, die können aber halt oft einfach langsamer sein.

Und das ist natürlich doof, weil

ein Massenpaket, der schneller sein will, aber die Sachen sind langsamer als würde die eigentlich auf normalen Python auf das Bildung.

Genau.

Ja, ja.

Also ich meine, der Grund, warum man.

Es gibt ja so ein bisschen zwei Motivationen, warum man in C geschriebene Bibliotheken verwendet.

Einmal, weil man halt gerne mit irgendwelchen Bibliotheken geschrieben reden will, die halt in C geschrieben sind.

Das ist halt ein Ansatz, aber ein anderer Grund ist halt, weil man irgendwas schneller machen will, indem man es in C schreibt.

Und diese Motivation, die funktioniert halt dann auf PyPy oft nicht.

Und es wäre dann zum Teil einfach auch echt besser, wenn man halt einfach Python-Code nehmen würde.

Aber weil halt für C-Python alle jetzt schon ihre tollen in C-geschriebenen Optimierungen gemacht haben, ist das dann für uns oft auch halt eine Verschlechterung.

Könnte man da nicht vielleicht einfach auch den C aus PyPy heraus irgendwie, einfach den C-Python-Interpreter wieder aufrufen und diesen Kram händeln lassen?

Ja, da gab es auch immer mal wieder so ein paar Experimente, aber dann verliert man halt, also man will halt, dann verliert man halt möglicherweise die Vorteile für den Python-Code wieder.

Also, weil das Problem ist, du willst ja halt beide Seiten auch miteinander reden lassen.

Wenn du halt nur C-Code hast, dann ist halt eh die Frage, warum du eigentlich, was hast du da noch mit Python zu tun.

Also spannend wird es halt dann, wenn du quasi Python, also wenn dein Programm halt wirklich aus interessanten Teilen auf der Python-Seite besteht und interessanten Teilen auf der auf der Bibliotheksseite.

Die andere Fußnote ist, dass es manchmal nicht klappt.

Also man gibt halt, manchmal hat man wirklich einen Python geschriebenen Code und wir, der wird nicht schneller.

Also man muss halt einfach, man muss halt einfach messen.

Und um mal so ein bisschen so eine Größenordnung zu nennen, wir haben halt so Speedups zwischen so im allerbesten Fall, wenn halt alles ganz toll ist und du Pure Python-Code hast, gar keine Bibliothek, die in C geschrieben ist, und das ist alles jetzt, sag ich mal, sehr numerisch.

Also du hast viele Zahlen und irgendwie viele Floats oder, aber du machst das auch wirklich alles in Python.

Dann kannst du halt so Speedups von 50 Mal schneller als C Python kriegen.

Also das ist halt, das ist schon, also alle Leute, die halt sowas wie Advent of Code machen, ja.

Advent of Code ist so, ich scherze, aber ist irgendwie auch was wahrs dran.

Advent of Code ist halt irgendwie einer der hauptcoolen Use Cases für PyPy.

Da sind halt, es ist halt irgendwie nicht so viel Code, es passt auf ein paar Bildschirme, es ist irgendwie sehr algorithmisch und man braucht nicht so viele Bibliotheken.

Und das wird halt dann, und Performance ist irgendwie auch wichtig und da ist halt PyPi einfach mega gut dafür.

Genau, und bei Performance ist es halt so, man muss halt einfach messen.

Also du kannst halt nicht quasi so a priori entscheiden, dass es immer jetzt Speedup X bringt, sondern es führt quasi keinen Weg darum, dass du deine konkrete Anwendung halt ausprobierst und schaust, bringt es was oder halt nicht.

Habt ihr irgendwie ein Referenzsystem oder macht das einfach immer so objektiv von dem über den Richter?

Du meinst jetzt quasi, inwiefern das von der darunterliegenden Hardware abhängt?

Ja, zum Beispiel, ja.

Das ist, glaube ich, nicht so ein Problem.

Also wir unterstützen so einen Haufen CBU-Architekturen, aber da ist jetzt, da sind wir nicht so sensitiv.

Es geht eigentlich dann eher darum, was für Bibliotheken benutzt dein Projekt und sind die eher so C-lastig oder was es gibt halt Teile der Sprache, wo wir einfach richtig, richtig gut drin sind, die schneller zu machen und Teile der Sprache, wo wir dann nicht ganz so viel rausholen können.

Wie viel lernt C-Python von euch?

Das ist eine gute Frage.

Achso, ich wollte kurz die andere Abschließung.

Also im besten Fall so 30, 40X.

Ich antworte gleich noch nicht.

Und im schlechtesten Fall ist man halt auch mal 30% langsamer und das ist halt dann doof.

Da will man halt dann nicht sein.

C-Python, also ich habe manchmal so quasi so Momente des Zweifels.

Ich verbringe seit irgendwie 18 Jahren einen Teil meiner Freizeit und irgendwie einen Teil meines Berufs damit, an diesem Projekt zu basteln.

Und so richtig, also was weiß ich, 99% von allen Deployments sind halt neben C-Balten.

Und man kann sich dann halt die Frage stellen: warum macht man das eigentlich?

Also mir macht das natürlich irgendwie einfach unglaublich viel Spaß.

Also ich bastel da gern dran rum, aber es ist natürlich auch schön, dann so ein bisschen so quasi externe Motivation aufzukriegen.

Und klar, es gibt immer wieder Leute, die das halt dann benutzen und das ist halt auch sehr cool, aber es gibt halt immer wieder auch Momente, wo wir dann quasi so rück, politische Rückauswirkungen auf C-Python haben.

Und das ist quasi meiner Ansicht nach auch so ein bisschen so ein zweite Grund, warum ich halt der Ansicht bin, dass es eine gute Sache ist, dass es eine zweite, sehr ernsthafte Implementierung der Sprache Python gibt.

Weil wir quasi.

Ja, dann doch so ein bisschen Feature-Entwicklung durch die Hintertür.

So ein bisschen

Feature-Entwicklung durch die Hintertür, ganz genau.

Und das ist zum Beispiel interessanterweise bei den Fehlermeldungen passiert.

Also so ein paar von den.

War das, das war 3.10 als 3.10.

Ja, 3.10 und 3.11, glaube ich.

Ja, das ist Verbesserungen.

Und bei beiden, also ich will jetzt wirklich nicht.

Keine Credits claimen.

Ich will keine Credits claimen.

Ich will auf gar keinen Fall, also was Pablo und Batuan Taskaya und sowas, was die da an den Aufwand reingesteckt haben, unglaublich nervig.

Und auch wirklich sehr, sehr cool.

Ich bin sehr zufrieden mit den Verbesserungen.

Wie gesagt, ich unterrichte Anfänger.

Ich kriege das quasi immer mit, wenn das halt mal schief liege mit den Fehlermeldungen.

Aber so ein bisschen, so der ursprüngliche Drive kam halt so ein bisschen von Pipe.

Also zum Beispiel dieses mit den nicht gematchten Klammern.

Das ist ja so eine der neuen Fehlermeldungen, dass es halt steht.

Die öffnende Klammer, die öffnete eckige Klammer auf Zeile 5 wird mit einer runden schließenden Klammer auf Zeile 9 geschlossen.

Da stimmt das nicht.

Das war halt einfach, das haben wir halt, das habe ich einfach vor ein paar Jahren mal implementiert.

Und irgendwann hat es halt in C-Python dann doch jemand mal gesehen und fand es cool genug, um es halt dann doch halt auch dann mal quasi nachzuimplementieren.

Und jetzt ist es so ein bisschen, fast so ein bisschen so ein Race manchmal.

Also gerade sind die, haben die ganz schön auch vorgelegt.

Also so ein paar der Fehlermeldungen haben wir jetzt noch nicht wieder übernommen.

Aber an ein paar Stellen gibt es halt immer noch ein paar, wo ich mit unseren dann zufrieden habe, zum Beispiel so ein absoluter Standard-Anfänger-Fehler, wo man halt echt Riesenprobleme hat, wenn man in Python einsteigt, wenn man so Objektorientierung lernt und man schreibt halt seine ersten Klassen und schreibt Methoden und kommt halt vielleicht von Java und vergisst das Self.

Und dann ruft man, versucht man die Methode aufzurufen.

Es ist Argument fehlt.

Und dann stimmt halt die Argumentzahl nicht.

Und dann vergleicht man halt einfach mal die Aufrufstelle mit der Funktionsdefinition und sagt, was ist denn eigentlich dein Problem?

Ich habe ja doch drei Argumente, warum beschwerst du dich denn, dass ich da nur, dass ich nur zwei reinreiche?

Oder ja, so, das ist ja, das stimmt ja dann immer nicht.

Und da mache ich in PiPy einfach nur, wenn es quasi ein Off-by-One-Error bei einem Methodenaufruf gibt, genau in diese Richtung, dann schaue ich, dann schaut der Interpreter nach, ob das erste Argument self heißt.

Und wenn nicht, steht einfach nur noch da, did you forget self in the method definition?

Ja, das ist wahrscheinlich eine gute Idee.

Ja, keine Ahnung.

Das ist natürlich, also bei diesen Fehlermeldungen ist es halt auch wirklich so, du hast halt einfach tausend Fehler.

Also das ist auch nicht übertrieben.

Es gibt halt ganz, ganz viele Stellen im Interpreter, wo halt Fehler produziert werden.

Und jede einzelne ist halt dann irgendwie vielleicht auch gar nicht so wichtig.

Also so diese Arbeit an Fehlermeldungen, die ist halt wirklich auch in gewisser Weise sehr nervig, weil man sich um jede einzelne irgendwie halt Gedanken machen muss.

Und da gibt es halt auch keine Shortcuts so.

Aber das ist halt eine, wo ich mal dann so einen Tag dran Spaß hatte, mir zu überlegen, wie man das halt vielleicht verbessern kann.

Aber ich bin halt so ein bisschen, wie gesagt, ich will keinen Credit clown, aber ich habe so ein bisschen das Gefühl, dass wir da einfach so ein bisschen so einen Push gegeben haben, so einen Initial-Push.

Wir hatten halt an vielen Stellen da so ein paar Sachen dann zuerst implementiert und das fließt jetzt ganz stark ins C-Python an, da bin ich einfach mega glücklich drüber.

Das ist der Forscher Drang, ne?

Der so ein bisschen auch in die richtige Richtung, dann geht fein.

Der was?

Der Forscherdrang?

Ja, keine Ahnung, es ist jetzt nicht mein, eigentlich ist das nicht mein Forschungsgebiet, ne?

Das war eher so ein bisschen, ich habe halt dann wirklich gesehen, dass es für die Studenten echt dann zum Teil wirklich blöd ist.

Zum Beispiel auch mit diesen, das wurde jetzt auch abgeschafft, ich glaube jetzt auch in 3.11, also oder in 3.10, ich weiß nicht so.

Also zum Teil gab es diese Fehlermeldung, diese Syntax-Fehlermeldungen, die echt so ganz komische Abkürzungen drin hatten, die halt einfach nicht ausgeschrieben waren.

Insbesondere bei, zum Beispiel, wenn man die, wenn man die Quotes vergessen hat beim String.

Also einfach nur X gleich Anführungszeichen A, B, C und dann hast du hinten die Quotes vergessen.

Da war früher die Fehlermeldung, irgendwie EOL while scanning String Literal.

Genau, auch noch ganz genau, ganz genau.

Und das haben sie jetzt gefixt.

Das heißt, es ist halt wirklich end of line, weil ich meine, woher soll irgendjemand wissen, was EOL heißt?

Was Scanning heißt und auch noch was String Literal heißt.

Also das ist halt wirklich, und das ist jetzt wirklich schöner.

Und das ist zum Beispiel eine Triple Quoted String, sagt er dir jetzt auch die Fehlermeldung, wo die, also da war die Fehlermeldung halt immer in der allerletzten Zeile der Datei.

Weil er sucht ja einfach

immer weiter.

Triple Quoted String ist es halt einfach dann wahrscheinlich der ganze Rest quasi, der da drin liegt.

Und am Schluss ist halt, da fehlt was dann.

Genau.

Und jetzt, das ist jetzt wirklich in das wurde in drei Zehen gefixt.

Es ist jetzt halt so, dass er dir wirklich dann die Zeile zeigt, wo die öffnenden Triple-Boot sind und das ist natürlich viel schöner.

Und die andere Zeilennummer kommt aber auch vor in der Fehlermeldung, das heißt, du hast dann wirklich beides.

Und ja, also das ist alles schon sehr, sehr cool.

Und ich meine, die in 3.11, die Position Informations, die sind halt auch so ein bisschen, das war quasi noch ein bisschen fieser von mir, das hatte ich noch nicht mal implementiert.

Da habe ich nur so ein Screenshot gefaked, wo ich halt einfach nur im Editor einfach mal so diese Tilde unter den Teil des Ausdrucks gemacht habe, wo der Fehler herkommt.

Dann habe ich einen Screenshot davon getwittert.

Und das hat halt Pablo gesehen und dann super aufwendig.

Es ist ein wirklich sehr nerviges Feature.

Ja, das glaube ich.

Ich hab mich schon gefragt, wie das implementiert wurde, weil das ist natürlich so, oh ja, sehr cool, aber oh mein Gott, wie ist das denn implementiert?

Wie kriegt man das denn alles raus an den Stellen?

Man muss halt wirklich einfach die gesamte Information durch den gesamten Stack so durchfädeln.

Und das ist an jeder Stelle, da muss man das weiterreichen und an jeder Stelle hat man halt, am Anfang hatten die Syntaxbäume halt auch die Information gar nicht.

Am Anfang hatte der Syntaxbäum halt nur eine Zeilennummer und dann kam irgendwie noch die Spaltnummer dazu, aber halt nur den Anfang.

Also das Ende, bis wohin das dann geht, das war halt, das kann man nicht vor.

Also nochmal für einen hätten sich das noch nicht genannt, es gibt halt viele Männer, da wird ja jetzt eine Position, wo das der Fehler passiert ist, mit so Dreiecken unter Kringelt quasi unterstrichen, wo das halt auch getroffen sein könnte.

Und da hatte ich halt diesen

Tweet gefaked und jetzt gibt's das.

Also, das ist mega geil.

Das sollte ich einfach öfter machen.

Und also ich muss das jetzt, das kommt dann wieder zu mir zurück, weil wenn wir eine 3-11 unterstützen, dann muss ich das ja auch implementieren.

Also insofern habe ich mich jetzt da ein Stück weit auch selber mit reingelegt, aber dass es jetzt halt in C-Balten drin ist, finde ich einfach mega cool.

Ja.

Dann weiß man halt schon, dass es sich lohnen wird, das zu implementieren.

Und ich meine, das andere große Feature, wo wir halt dann quasi so ein bisschen, also jetzt nicht Druck ausgeübt, aber halt dann quasi Einfluss produziert haben, sind halt die Order Dictionaries.

Also das ist ja in 3.6, glaube ich.

Ja, informellt.

Aber ab 3.7 wird dann auch tatsächlich garantiert, dass es.

In 3.6 haben sie halt gesagt, ihr dürft euch nicht drauf verlassen, dass die Dictionaries jetzt in der Einführungsreihenfolge sind.

Und in 3.7 haben sie dann gesagt, na, das funktioniert so gut, dass wir jetzt halt sagen, wir werden das auch nicht wieder abschaffen.

Und man darf sich jetzt drauf verlassen, weil es halt an ganz vielen Stellen echt auch viele Vorteile hat.

Und das ist ein Pipe-Feature.

Achso, okay, dann ist es.

Also gar nicht klar, ja.

Da gab es halt von Raymond Hattinger Prototyp, aber in Python, in Pure Python.

Und wir haben halt einfach gesagt, das sieht halt als Algorithmus echt gut aus.

Und wir machen jetzt das ganze Engineering, was man halt braucht, um das dann wirklich quasi in Produktiveinsatz in die Implementierung einzubauen.

Das haben wir halt einfach dann irgendwann mal gemacht.

Und zwar noch nicht mal für unsere 3.6-Versionen, sondern halt für unsere 2.7-Versionen.

Also bei uns sind halt Dictionaries schon immer, also nicht schon immer, jetzt schon seit ungefähr zehn Jahren irgendwie geordnet.

Und das war auch ganz schön, also dann, das war auch dann schon noch ganz schön viel Aufwand.

Also dieser Python-Code war halt so ein, jetzt Sketch wäre ein bisschen untertrieben, hat halt den Algorithmen so, den Algorithmus so irgendwie präsentiert, aber quasi dann das zu nehmen und es dann so weit zu pushen, dass es halt so gut ist und quasi an allen Stellen mit dem bisherigen Dictionary-Algorithmus dann auch wirklich mithalten kann und trotzdem die Insertion Order halt quasi erhalten bleibt.

Da haben wir halt dann wirklich nochmal sehr viel extra Aufwand reingesteckt.

Also Maschek Fischakovki und Armin Rigo haben das vor allem gemacht.

Und dann hatten wir das halt irgendwie und dann gab es halt einen C-Balton-Entwickler, der Name fällt mir gleich auch wieder ein, der hat das dann quasi wieder rückportiert.

Also hat halt unseren Code genommen und hat gesagt, ja cool, wir bauen das jetzt in C-Breiten ein, hat dann das irgendwie die nötige, ich weiß nicht, ob es da ein PEP für gab oder ob er die nötige Mailinglistendiskussion geführt und dann landete das halt in 3.6 und dann wurde es halt quasi auch offiziell Teil der Semantik.

Und ich meine, es ist halt eigentlich auch ganz cool, weil es ist halt wirklich, ich meine, das ist ja ein extra Feature und es ist.

Das ist intuitiv irgendwie trotzdem.

Das ist intuitiv, ich finde es auch zum Lehren viel nicer, wenn man halt sagen kann, wenn man nicht immer erklären muss, warum beim Printen plötzlich halt einfach die Keys halt so durcheinander gewirbelt werden.

Das war ja früher so.

Also früher war es halt irgendwie, hing es von den Hash-Werten ab, das war halt komplett intransparent, warum halt dann die Sachen plötzlich ganz anders dastehen.

Und es ist halt auch gar nicht so, es ist halt auch a priori gar nicht so klar, dass das wirklich effizient geht.

Weil man könnte ja halt auch denken.

Wie machen wir das jetzt?

Macht man quasi so ein Extra dazu, das immer noch von den Hashwerten abhängt?

Das ist gar nicht so einfach.

Also so, da gibt es halt so eine komische Indirektion jetzt drin, dass man quasi einmal die Hash Map hat und dann aber noch ein zweites Array, wo die Sachen in der Insertion Order drin sind.

Und dann würde man halt erstmal denken, dass man halt da plötzlich ganz viel Speicher irgendwie mehr braucht, weil man diese Indirektion hat.

Und da gibt es halt dann so einen Trick, und das ist wirklich auch das, was ich nicht verstanden hätte vorher, bevor die Leute das an sich halt ausgedacht haben, der Trick ist jetzt, die Hash Map, die darf ja nicht voll sein, weil du sonst Collisions kriegst.

Ich weiß, also wenn du quasi, wenn deine Hash Map irgendwie zu voll wird, dann musst du halt irgendwie die verdoppeln, um sicherzustellen, dass.

Beim nächsten Mal speicherfreis oder irgendwas reinkriegst.

Genau, ja.

Und der Trick ist jetzt aber, dass du mit dieser Indirektion jetzt den großen Teil einfach linear speicherst.

Also du kannst dann, diese Lücken fallen dann weg.

Die Lücken sind nur noch in deiner Indirektion drin, aber nicht mehr in deinem wirklichen Array, wo halt für jeden Eintrag ein Hash, ein Key und ein Value gespeichert werden.

Weil ein Eintrag von einem Dictionary besteht ja quasi aus drei Maschinenwörtern.

Und wenn die dann quasi immer noch so Lücken haben, hast du halt ständig Lücken, die alle drei Maschinenwörter groß sind.

Aber wenn du die in Direktion einbaust, dann ist quasi ein Eintrag nur noch ein Index in den dicht gespeicherten Insertion-Order-Speicher.

Jetzt sind wir an dem Punkt, wo wir eigentlich gerne ein Bild malen würden.

Ja, ja, aber das geht

natürlich im Plan.

Vielleicht ist dann der Blogpost, ich finde den mal und wir verlinken den dann, aber für mich war es halt erstmal nicht klar, dass es wirklich auch wirklich eine gute Idee ist, das so zu machen.

Also ist es aber.

Also stellt sich halt raus, es ist es.

Ja, cool.

Dann hat man quasi dann für drüber iterieren, muss man dann einfach nur noch durch die echte Liste gehen und ganz genau gar nichts drum macht.

Das iterieren ist halt auch besser, weil vorher war es halt so, man musste quasi über die Hashmap drüber iterieren und bei jedem Eintrag gucken, ist das überhaupt ein Eintrag oder nicht.

Jetzt kann man aber quasi über den dichten Speicher drüber iterieren, wo einfach alle Einträge gültige Einträge sind.

Und man muss halt gar nicht mehr, man hat dann quasi, verliert auch ein If in jedem Next-Aufruf.

Also vorher war es so, dass man quasi in einem Next-Aufruf eine Schleife brauchte, um den nächsten gültigen Eintrag zu finden.

Und jetzt weiß man halt einfach, es ist der nächste Eintrag.

Schick.

Ja, genau.

Also das wäre halt auch noch so ein Beispiel, wo wir quasi dann die Implementierungsebene so ein bisschen beeinflusst haben.

Aber sonst, also so die ganzen Kerntechniken, die wir, also wir haben jetzt noch gar nicht so, bisher haben wir eher so ein bisschen phänomenologisch darüber geredet.

Wir führen das aus, es wird schneller.

Und ich glaube, irgendwie jetzt müssen wir vielleicht so ein bisschen anfangen darüber zu reden, wie das eigentlich geht.

Also die Kern, ja.

Ich hätte noch ein, zwei Fragen vorher.

Also wenn das ja, werden alle Sachen schneller, du hast gesagt, okay, C-Extension nicht so schnell.

Was mit anderen Sprachen, also kann er C<unk> irgendwie, wenn das irgendwie angebunden ist, ein Problem?

Also weil das halt es wird halt erstmal vor allem Python schneller.

Also wirklich, wenn du Python-Code ausführen würdest, wird

er schneller.

Aber die anderen Sachen laufen noch?

Die anderen Sachen laufen noch und es kommt so ein bisschen drauf an, was die genau machen, ob die dann vielleicht langsamer werden oder halt einfach gleich bleiben oder und dann gibt es halt auch noch so Randfälle, zum Beispiel reguläre Ausdrücke sind auch sehr, sehr schnell bei uns in PyPy, obwohl die natürlich eigentlich kein Python-Code sind, aber da haben wir dann eine extra Optimierung dafür.

Es ist ja quasi so eine kleine DSL in Python, in gewisser.

Also du musst ja DSL nochmal beschreiben, welche Länge bist du meinst.

Genau, eine Domain-Specific Language für String-Matching.

Also ich meine, das ist eine sehr häufige, die halt quasi überall eingebaut ist, aber es ist ja schon eine andere Programmiersprache als Python letztlich.

Aber wir haben halt dafür auch dann quasi ganz viel Optimierung gemacht, dass das halt auch schon alles.

Normalerweise kann ich die per Pi-Env einfach installieren, dann mein PyPy auch?

Ich glaube, Pienv unterstützt auch PyPy, ja.

Also auch Talks hat eigentlich zum Beispiel PyPy-Support, wenn du das testen willst.

Das ist schon an vielen Stellen quasi so ganz gut in die Infrastruktur.

Nach den Semesterferien kriegen wir hoffentlich einen Alpha-Release.

Und ja, also ich, da arbeite ich gerade halt dran.

Heute Morgen habe ich zwei Bugs gefixt.

Also das ist das, was ich jetzt gerade so halt wirklich konkret mache.

Und also die großen Features sind halt fast fertig.

Also Patternmatching ist da und 3.10 hatte, also außer Patternmatching halt auch viele so mittelgroße Sachen.

Aber Patternmatching, das war wirklich auch.

Kann ich mir vorstellen, das macht der beim Parsen ein relativ großes.

Ich glaube, das konnte ja auch nur deswegen in C Python irgendwie gemacht werden, weil da dann der neue Pack-Parser irgendwie verwendet wurde.

Und ich weiß gar nicht, bei PyPy, äh, Pipey.

Pipe Pipe ist eigentlich reingefallen.

Da weiß ich gar nicht, was da verwendet wird, aber das könnte ja dann auch auswählen.

Da hatte ich zum Glück sehr gut vor.

Also vor einem Jahr hatte ich dann 3.9 implementiert und da war 3.10 ja schon raus und da habe ich halt so gesehen, der Packparser wird wichtig.

Und ich habe dann quasi bei 3.9 schon die ganze technische Vorarbeit dafür geleistet.

Also wir haben halt, wir haben auch einen Pack-Parser, quasi mehr oder weniger die gleiche Architektur.

Wir können nicht ganz das gleiche Input-File nehmen, weil ich weiß nicht, ob du mal in diese Grammatikdatei reingeschaut hast.

Nee, nicht wirklich.

Also es ist halt im Prinzip so ein bisschen so ein Kontext von freier Grammatik, wie man das halt irgendwie aus irgendeiner Informatikvorlesung vielleicht mal gesehen hat.

Aber im Unterschied zur alten Grammatik ist das so, dass jetzt in dem, in der Pack-Grammatik, da sind halt so Schnipsel an C-Code drin.

Und die können wir halt, die wollen wir halt nicht haben.

Und wir müssen quasi die Schnipsel an C-Code, die mussten wir halt quasi von Hand einfach einmal überall ersetzen.

Und das war sehr, sehr nervig.

Und das ist auch so ein bisschen meine Kritik, dass quasi die Grammatik der Sprache vermischt wird mit den Parsing-Actions, die in C geschrieben sind bei C-Python.

Bei uns sind die nicht in C geschrieben, wir werden gleich noch darüber sprechen, worin die bei uns dann geschrieben sind.

Aber das war halt dann einmal sehr, sehr nervig, da drüber zu gehen und alle diesen C-Schnipsel dann da auszutauschen.

Und da gibt's, da habe ich dann auch immer mal wieder einen Fehler gemacht, die finde ich dann jetzt auch immer mal wieder einen.

Also das war halt einfach Aufwand.

Aber ich habe halt damals quasi schon, vor dem Jahr dann quasi schon vorgearbeitet und gesagt, wenn dann 3.10 kommt, dann will ich halt quasi auch schon darauf vorbereitet sein, dass das Patternmatching dann in den Parser zumindest einfach einzufügen ist.

Aber es ist halt nicht nur ein Parser, es ist ganz viel neue Syntax, aber es sind halt auch einiges an neuen Bytecodes und der Bytecode-Compiler hat halt ganz, ganz viel recht komplexe Logik auch gekriegt.

Und das habe ich jetzt aber, das ist zum größten Teil jetzt halt ziemlich fertig.

Also da fehlt mir noch so ein, so ein Randfall, der muss ich jetzt irgendwann noch fixen, der hat mich bisher noch zu sehr genervt, aber das ist quasi fast durch.

Und dann, also jedes Release, so der, ich versuche mal so ein bisschen ein Gefühl dafür zu vermitteln, wie sich das anfühlt, an so einer neuen Python-Version zu arbeiten.

Es gibt halt immer irgendwie fünf große Features, die man halt auf der What's New Seite kennt.

Und die implementiert man halt.

Das ist dann irgendwie halt auch nice, ja, weil das ist so ein klar umrissener Task und man freut sich vielleicht halt auch über, vielleicht ist es halt auch ein Feature, was man gut findet.

Ich weiß nicht, wie ist euer Bauchgefühl, wie findet ihr Pattern Matching?

Ich liebe es.

Okay, ich habe es noch nicht wirklich viel verwendet, weil.

Also ich mag das total gerne nicht.

Statt if Elif irgendwie einfach schöne Case zu machen.

Gerade für so API-Parsing oder.

Also ich finde, man muss sich

ganz, also ich verstehe absolut, dass man das total cool finden kann.

Ich habe es auch noch nicht so richtig im Produktiv, also noch nicht wirklich irgendwas geschrieben, was halt nicht einfach so ein tolles Beispiel ist, aber man muss sich schon so ein bisschen reindenken.

Also ich finde, es unterscheidet sich halt in mancher Hinsicht schon so ein bisschen von dem Feeling von Python an so ein paar anderen Stellen.

Also ich glaube, wenn man dann da so mal gedanklich drin ist, ist es, glaube ich, wirklich auch sehr, sehr cool.

Aber man braucht so ein bisschen.

Oder ich habe das Gefühl, dass ich so noch so ein

bisschen brauche.

Man kann irgendwie so direkte Kommandos geben und man kann da direkt sagen, was das ist.

Und in Zusammenhang mit den Typen, finde ich, ist das sehr schön.

Weil man, wenn man halt tatsächlich Typen definiert hat irgendwie, dann kann man halt einfach diesen Typ als Case nehmen.

Und das ist halt genau das, was man wahrscheinlich irgendwie.

Aber also was man dann wirklich in die Patterns reinschreibt, das ist halt quasi nochmal so ein bisschen so eine Sprache in der Sprache.

Und die ist halt schon so ein bisschen anders halt auch als der Rest von Python.

Ja, aber jetzt, ich glaube, du musst vielleicht gleich nochmal so ein bisschen ausholen darüber, was eigentlich so eine Sprache aus deiner Sicht halt ist.

Und ausmachen.

Das ist jetzt ziemlich schwammig.

Genau.

Aber auf jeden Fall, also man hat halt so ein großes Feature, sowas wie Patamatching.

Das ist halt schön.

Da kann man, weiß, man hat, das ist relativ klar umrissen.

Wenn man das Feature cool findet, dann macht es halt auch richtig Spaß, das zu implementieren.

Ja, dann so über ein paar Tage hinweg fängt das halt dann an zu funktionieren.

Das ist halt einfach immer wieder auch sehr cool.

Und irgendwann ist man halt dann mit allen großen Feature fertig und dann gibt es so ein bisschen, zusätzlich zu den fünf großen Feature, gibt es halt vielleicht 30 kleinere und mittlere Feature.

Das ist halt so ein bisschen Fleißarbeit.

Und dann gibt es aber halt einfach 1000 Details.

Und das sind halt, das ist der Teil, der quasi am längsten dauert und ein bisschen am nervigsten ist.

Also weil man halt jeden Tag einfach fünf kleine Details fixen kann.

Und man findet die, indem man halt die Test Suite, die Teil der C-Python-Standardbibliothek ist, ausführt.

Und dann halt die fehlenden Tests nach und nach fixt.

Und mit den großen Features ist man halt irgendwann durch.

Also es gibt halt Test Padma, das hat man halt irgendwann dann, das passt dann, dann ist es alles super.

Aber dann ist halt in allen anderen Dateien gibt es halt dann so einen fehlschlagenden Test.

Und jeder von diesen fehlsteiligen Tests dauert halt zwei Stunden.

Und das ist halt einfach das, was einfach ganz, ganz, also da gibt es halt quasi dann so ein Long Tail an irgendwelchen Details.

Und der quasi Fortschritt, den man dadurch erzielt, dass man das fixt, ist halt auch irgendwann dann nicht mehr so groß.

Wahrscheinlich denkt man sich dann irgendwann so, das lohnt

sich halt.

Genau.

Okay, aber das ist halt tatsächlich dann TDD auch, was ihr da macht.

Ja, also Piper ist von der Entwicklungsphilosophie sehr, also ich meine, wir haben ja vorhin ganz kurz gesagt, dass es jetzt irgendwie 20 Jahre altes Projekt ist.

Also es wurde jetzt fast genau, also irgendwie 17.

Februar war das erste Treffen von so ein paar Leuten in Hildesheim.

2003.

2003, genau.

Also völlig anderes Zeitalter so ein bisschen.

Und damals war das halt irgendwie so ein bisschen, hatte das so ein bisschen so ein Extreme-Programm-Kontext auf der Entwicklungsphilosophie-Seite, also so mit Test-Driven Development und Agile before das kommerzialisiert wurde, so in der Idee her.

Es ist wirklich so, dass diese Implementierung von vornherein komplett test-driven entwickelt wurde.

Das ist halt an vielen Stellen auch wirklich ganz tief drin in der Philosophie des Projekts.

Und das ist auch so, dass PiTest aus Piper hervorgegangen ist.

Also der Holger Krickel, über den haben wir, bevor wir auffangen aufzunehmen, kurz schon geredet, der war halt einer der.

Der ist Holger.

Ja, ich erinnere mich.

Der war halt einer der Gründer des PyPy-Projekts, also der hat das erste Treffen in Hildesheim organisiert und am Anfang wurde dann für die Tests halt einfach Unitest genommen.

Und Unitest ist ja ein von Java portiertes, an Java-Architektur angelehntes Testing-Framework.

Aber ich glaube, JUnit ist irgendwie S-Unit von Smart Talk.

Aber durch diesen Umweg über Java ist es halt irgendwie doch ein bisschen Ungelenk an vielen Stellen.

Und weil Holger halt dann das alles auch ganz schön doof fand, hat er recht früh als Teilprojekt von PyPy halt angefangen, PyTests zu entwickeln.

Und das ging dann quasi aus dem PyPy-Projekt irgendwie so ein Stück weiter vor und ist jetzt natürlich eine Million Mal erfolgreicher als alles, was PiPi irgendwie jemals sonst so gemacht hat.

Pipei spannend, also am Anfang habe ich es gehasst und jetzt finde ich es richtig gut, weil das halt echt total gut ist und ich finde es sehr Pythonic und wenn man einmal so ein bisschen vielleicht verstanden hat, wie das funktioniert, das ist sehr, sehr, sehr schön zu nutzen.

Also ich meine halt einfach so dieses, dass man davon wegkommt, dass man diese 97 Self-Assert irgendwas Funktion braucht, um gute Fehlermeldung zu kriegen.

Das ist halt schon.

Self-Assert-Equal irgendwie Camel-Case und sowas.

Equal oder Equals?

Genau, ja, ja, genau.

Das macht bloß kann nichts Falsches sein.

Ja, und Camel-Case natürlich auch mal.

Ja, und ich finde halt also gerade so die Hürde, man schreibt halt einfach eine Funktion, die Test heißt, dahin und dann geht halt, das ist halt schon sehr, sehr cool.

Ne, genau, also Test-Driven Development war halt einer der Kernideen so auf der, wie entwickeln wir dieses Projekt.

Das andere war halt, das ist so ein bisschen verloren gegangen über die Jahre, aber einer der Ideen am Anfang war halt wirklich, wir wollen eine sehr gut verständliche Implementierung der Sprache schreiben.

Und da müssen wir irgendwann jetzt halt dann doch mal zur Architektur kommen.

Warum heißt das Ding eigentlich PyPy?

Weil es PyPy noch nicht gab.

Ja.

Nein, Entschuldigung.

Also das Projekt ist halt entstanden aus Diskussionen auf erst der deutschen Python-Mailing-Liste und dann irgendwie auch Complang Python von halt Python-Fans, also halt so ein paar Leuten, die irgendwie Python als Programmiersprache toll fanden und die halt gesagt haben, naja, es ist doch philosophisch eigentlich irgendwie blöd, dass wir alle Python so toll finden, aber der Interpreter für Python, dass der ja in C geschrieben ist.

Und PyPy ist halt wirklich, die Idee war wirklich, wir schreiben jetzt eine Implementierung für Python, aber wir wollen dafür halt nicht C nehmen, weil C so eine blöde Sprache ist, sondern wir wollen dafür halt Python nehmen, weil wir alle Python-Fans sind.

Und das war quasi, also da kommt der Name her, PyPy ist Python in Python.

Und das war halt so ein bisschen die Ursprungsmotivation, wir wollen jetzt die Sprache nehmen, die wir cool finden, um die Sprache selbst zu implementieren.

Und das klingt halt erstmal ganz, also nach einem sehr akademischen Experiment.

Und das war es ein Stück weit, glaube ich, auch erstmal.

Also erstmal war halt so ein bisschen die Idee auch, wir wollen irgendwie Code schreiben, den man halt einfach erstmal schön lesen kann.

Und der soll natürlich schon auch irgendwie funktionieren.

Aber insbesondere soll der halt einfach architektonisch toll sein und irgendwie elegant und alles schön, diese Sprachsemantik soll irgendwie ganz klar ausgedrückt werden in diesem Python-Code.

Das war quasi eine der Ideen.

Und erst später kam es dann hinzu, dass quasi Performance eigentlich ein immer wichtiger Teil der Projekt der Projektmotivation war.

Also irgendwann hat man halt gesagt, naja, okay, wir haben das jetzt, aber warum sollte man das machen?

Und wir machen jetzt halt auch noch ganz, ganz, ganz viel Aufwand, um, also welchen Aufwand da rede ich vielleicht gleich noch ein bisschen was dazu.

Wir machen halt ganz, ganz viel Aufwand, um das dann doch irgendwie auch schnell zu kriegen.

So, und vielleicht können wir da auch einfach wirklich historisch vorgehen.

Also die erste Idee, um das jetzt schneller zu kriegen, also man hat dann jetzt irgendwie so eine Python-Implementierung, die ist in Python geschrieben und die ist schön und elegant, man kann das lesen, aber das bringt einem halt einfach gar nichts.

Weil man braucht ja einfach immer noch darunter einen Python-Interpreter, um das ausführen zu können.

Und dann ist es halt einfach quasi ein Python-Interpreter, der auf einem, der auf C-Python läuft.

Das ist halt einfach ganz, ganz langsam.

Aber man kann natürlich dann viel über die Sprache vielleicht lernen.

Genau, man kann dann was lernen und man kann da bestimmt auch irgendwie dann schön einfach irgendwie Experimente durchführen.

Aber das ist jetzt nichts, was man irgendwie im Produktiveinsatz haben wollte.

Es wäre halt dann wirklich einfach eher so ein, es wäre halt vielleicht so ein cooler Blogpost oder so, oder?

Ein cooles Buch.

Okay, aber halt viel mehr auch nicht.

Und die erste Idee ist quasi, dass man jetzt sagt, wir machen einen Prozess, den man halt irgendwie Bootstrapping nennen kann.

Wir nehmen jetzt diesen Python-Interpreter, der in Python geschrieben ist, und übersetzen den, also schreiben einen Compiler, der jetzt diesen Code nehmen kann und den nach C übersetzen kann.

Und das geht halt nicht für allgemeinen Python-Code.

Also man kann Python-Code halt nicht nach C kompilieren, das bringt nicht viel.

Aber deswegen beschränken wir uns auf eine Teilmenge von Python in dem Code, den wir in der Implementierung des Interpreters verwenden.

Also der Interpreter ist quasi in einer Teilmenge geschrieben und die ist so gewählt, dass man diese Teilmenge gut nach C übersetzen kann.

Und dann wird man quasi dieses Interpreterturm problemlos.

Also dann kann man quasi den Python-Interpreter nehmen, der ist nicht mehr in Python geschrieben, sondern in, ich sage jetzt gleich den Namen, in RPython.

Das ist eine Teilmenge der Sprache und die ist so gewählt, dass man sie nach C übersetzen kann.

Und RPython heißt es halt, weil es restricted Python ist, weil man halt einfach so ein bisschen die ganz dynamischen Sachen, die man in Python machen kann, die macht man halt einfach nicht.

Um eben das Übersetzen nach C zu ermöglichen.

Also man ändert keinen Typ einer Variable irgendwie on the fly.

Ganz genau.

Also das ist, glaube ich, sogar noch nicht mal ganz so schlimm.

Also man macht halt so Sachen, man fügt einer Klasse keine neuen Methoden zur Laufzeit hinzu.

Oder in Python gehen ja alle möglichen komischen Sachen.

Man kann halt ja auch bei einer Instanz dann da Class zuweisen und so.

Also so dieses ganze, ganz dynamische Metaprogrammierungszeug, das ist halt einfach verboten, weil da ist halt nicht so klar, wie der C-Code dann aussä, den man da generieren würde.

Also das ist der erste Schritt.

Der erste Schritt ist, das ist nicht mehr Python in beliebigem Python-Code, sondern das ist Python eine Implementierung für die Sprache Python in einer Timenge von Python und wir haben dazu noch ein anderes Tool, was jetzt diese Teilmenge nimmt und daraus C-Code erzeugt.

Und so wird man C-Python erstmal los.

Also danach, du drückst dann auf den Knopf und dann nimmt der halt den Interpreter, der in der Tilmenge geschrieben ist, erzeugt C-Code daraus, dann startest du den C-Compiler und der nimmt den C-Code und macht daraus halt eben wieder ein Binary, über das wir ja vorhin schon gesprochen haben, dass das runtergeladen werden kann.

Und das ist halt dann quasi einfach ein etwas merkwürdiges, also geschriebenes, aber das verhält sich jetzt, also es ist quasi noch näher dran an dem, was man von Python.org runterladen kann.

Es ist halt ein nicht in hand geschriebener C-Code, sondern generierter C-Code, aber es ist halt einfach dann ein Interpreter für Python in C, letztlich.

Und das bringt halt schon dann mal die ersten, also vorher, so um mal so eine Größenordnung zu nennen, wenn man das, wenn man dann PyPy auf C-Python ausführt, dann hat man halt irgendwie so einen Interpreter, der vielleicht 2000 Mal langsamer ist als C-Python.

Also dann ist es halt wirklich, das ist nur ein Spielzeug.

Und wenn man dann diesen Bootstrapping-Trick macht, dass man eben wieder C-Kode erzeugt, dann gewinnt man halt von diesen 2000 Mal langsamer, gewinnt man halt 1000 Mal zurück.

Dann hat man quasi einen Interpreter, der ist

nur tausendmal langsamer.

Nee, nee, nur zweimal langsamer.

Achso, okay.

Also Faktor 1000 kriegt man wieder.

Aber einen Faktor 2 hat man halt immer noch.

Und das ist natürlich immer noch nicht gut.

Also warum sollte man das machen?

Man, weil es halt in Python geschrieben ist und wir alle Python so toll finden.

Das reicht halt irgendwie als Motivation nicht.

Und jetzt ist so ein bisschen die Frage, wo kommt jetzt, wo kommt eigentlich wirklich das Speed her?

Und da wird es halt dann so ein bisschen akademisch, also das ist quasi der Forschungsanteil.

Also ich habe da meine Doktorarbeit drüber geschrieben, das ist quasi wirklich so ein bisschen ein, ja, also war wirklich so ein bisschen ein ganz klassisches akademisches Forschungsprojekt, da war ja währenddessen auch gar nicht so klar, ob das wirklich klappen kann, so von der Idee her.

Und hat auch, sag ich mal, vielleicht fünf, sechs Jahre gedauert, bis es dann klarer wurde, dass es halt wirklich geht.

Und die Idee daran ist, dass du, also sagt man ja auch immer so ein bisschen so, wenn man halt irgendwie das schnell kriegen will, dann braucht man halt irgendwie einen Jet-Compiler.

Also wenn man halt irgendwie eine dynamische Programmiersprache schnell ausführen will, dann braucht man einen Just-in-Time-Compiler.

Und was ist das?

Ein Justin-Time-Compiler, also so ein normaler Compiler, der funktioniert halt für Python nicht, weil man ja gar keine Typen hat.

Also das ist jetzt mit Typen-Annotation heutzutage so ein bisschen anders.

Aber die Typ-Annotationen, die sind ja auch so ein bisschen so eine Fiktion.

Die dürfen ja auch falsch sein.

Also vergessen wir die erstmal.

Also das Problem ist, wenn man einfach Python-Code anschaut, dann kann man den halt nicht unbedingt jetzt kompilieren.

Wenn man halt eine Funktion hat, die A und B als Argumente nimmt und die Funktion macht irgendwie Return A mal 2 plus B, dann kann man halt diese Funktion nicht nach Maschinencode übersetzen, weil man weiß halt gar nicht, was das mal macht.

Also man kann die Funktion halt mit ins aufrufen, man kann die mit Floats aufrufen, man kann die mit Strings aufrufen oder man kann die halt mit einer Klasse aufrufen, die halt einen Unterstrich-unterstrich-Ad-Methode hat und eine Unterstrich-Mull-Methode und die halt irgendwas super Weirdes macht.

Das heißt, man muss quasi die Anwendungsfälle kennen, in denen das aufgerufen wird, irgendwann in diesem Programmablauf und dann daraus jeweils unterschiedliche Implementierungen im Zinkencode zu schreiben, die man dann falsch hat.

Ganz genau.

Und das kann man aber halt quasi nicht ohne weiteres statisch machen.

Also man kann jetzt, es ist nicht leicht, sich quasi nur den Quellcode anzuschauen und zu sagen, aha, A und B sind ja immer Inns.

Weil es kann ja sein, dass es halt an sieben verschiedenen Stellen wird die Funktion jetzt aufgerufen wird und an zwei davon sieht es so aus, als könnten das Ins sein, aber an den anderen drei weiß ich nicht so genau und das ist überhaupt eine Bibliothek drin und ich weiß halt überhaupt nicht so genau, wie die Bibliothek jetzt verwendet wird, konkret von irgendeiner Anwendung.

Das heißt, so einfach, wenn ich mir nur den Quellcode anschaue, kann ich für diese Funktion F keinen guten Maschinencode erzeugen.

Und deswegen braucht man halt quasi, also ein normaler Compiler geht halt nicht.

Und deswegen braucht man halt eben den Justin-Time-Compiler und das ist ein Compiler, der erzeugt zwar schon Maschinencode, aber der macht das nicht so einmal vor der Ausführung, sondern der macht das quasi während das Programm schon läuft.

Und der Grund, warum ein Dustin-Time-Compiler eben funktioniert, ist, weil er einen ganz krassen Informationsvorteil hat.

Der Dustin-Time-Compiler, der kann halt einfach gucken, mit was für Typen von Argumenten die Funktion aufgerufen wird.

Also der ist halt einfach quasi, der Compiler ist maximal faul und sagt, ich kompiliere erstmal gar nichts.

Ich führe einfach alles ganz normal mit dem Interpreter aus.

Und wenn sich dann herausstellen sollte, dass F jetzt in dem Programm eine wichtige Funktion ist, macht man so ein bisschen Profiling, dann schaue ich halt mal, was für Typen werden jetzt hier konkret verwendet.

Und wenn, dann irgendwann sehe ich halt, na gut, es sind immer zwei Floats.

Und dann kann ich halt auch guten Maschinencode erzeugen, weil wenn ich weiß, dass es Floats sind, dann kann ich halt das Mal, also ich hatte A mal 2 plus B gesagt, dann kann ich halt das Mal 2 durch eine Maschineninstruktion darstellen, die halt Doubles auf der CPU direkt multipliziert.

Und das Plus kann ich eben auch dann durch eine Maschineninstruktion abbilden, die halt Doubles addiert.

Und dieser Maschinencode, der funktioniert halt dann genau nur für den Spezialfall, dass A und B halt wirklich auch float sind.

Und wenn dann irgendwann später im Verlauf des Programms halt diese Funktion jemand mit zwei Ints aufruft, dann ist das kein Problem, weil der Code wurde ja sowieso zur Laufzeit erzeugt und dann kann ich halt quasi auch neuen Code für diese sich ändernde Situation erzeugen.

Und diese Flexibilität, die mir die Tatsache, dass ich den Maschinencode eben erst zur Laufzeit erzeugt, dadurch kriege ich halt sehr viel Flexibilität und kann halt die extra Informationen, die ich zur Laufzeit habe, auch benutzen, um quasi die ganze Dynamizität, die man in Python halt theoretisch verwenden kann, aber in der Praxis nicht unbedingt verwendet.

Die kann ich dann halt auch quasi wieder wegoptimieren.

Aber das kann ich eben nur, weil ich eben das zur Laufzeit mache und mir die Typen anschauen kann und halt auch reagieren kann, wenn sich dann die Umstände ändern.

Das ist halt auch so ein bisschen die andere Eigenschaft des Time-Compilers.

Der kann halt dann auch darauf reagieren, dass du nach einer halben Stunde Programmlaufzeit plötzlich den Debugger anmachen willst.

Dann muss man nämlich anfangen, quasi wieder alles zurückzupacken und das nennt man wirklich Deoptimierung.

Da muss man wirklich quasi wieder die Frame-Objekte erzeugen, die man halt braucht, um dann, dass der Debugger funktioniert.

Also der Debugger, der introspiziert ja diese Frame-Objekte, die es in Python gibt.

Und die würde der JIT-Compiler natürlich gar nicht benutzen, weil die braucht er nicht.

Aber wenn man die Debugger anschaltet, dann muss man die halt jederzeit wieder herzaubern können.

Okay, also das ist die Idee des Jits.

Das ist quasi in gewisser Weise heutzutage relativ akzeptiert, weil jeder Browser das halt macht.

Also Java macht das und insbesondere machen das halt die Browser für JavaScript.

Und die Browser Wars haben halt dazu geführt, dass quasi alle großen Browser sehr, sehr, sehr, sehr, sehr viel Geld da reingesteckt haben, halt Justin-Time-Compiler für JavaScript zu schreiben, die halt wirklich extrem aggressiv zur Laufzeit den JavaScript-Code optimieren und zur Laufzeit nach Maschinencode übersetzen können.

Und deswegen ist JavaScript halt inzwischen, jetzt sag ich mal, nicht ganz so schnell wie C, aber halt irgendwie vielleicht nur zwei oder dreimal langsamer als C.

Und einfach, weil da halt einfach viele Millionen Dollar in jede von dieser Implementierung reingesteckt wurde.

So, deswegen inzwischen weiß halt jeder so ein bisschen, was ein JIT ist.

Das war aber halt, als das Projekt anfing, nicht ganz so sehr so.

Es gab halt damals, ich weiß nicht, sagt euch, Psycho was.

Ja, klar.

Und das ist so ein bisschen, jetzt sind wir stark in der Ancient Python History drin.

Also das war so ein Extension-Module für Python 2.2.

Jetzt kommt raus, dass ich alt bin.

Und das war quasi ein sehr, sehr schlauer, promovierter Mathematiker, der hat dieses Extension-Module geschrieben.

Und das war quasi ein DID für C Python.

Wenn man das Extension-Module geladen hat, dann hat halt Psycho angefangen, zur Laufzeit aus den Python-Funktionen halt irgendwie Maschinencode zu erzeugen.

Und das hat gut funktioniert, an vielen Stellen.

Und das große Problem von Psycho war jetzt aber, dass jede neue Python-Version, die rauskam, hat das komplett kaputt gemacht.

Also weil wenn es halt, sobald es ein neues Sprachfeature dazu kam, musste der Armin, Armin Rigo heißt das, musste dieses Extension-Modul halt wieder im Wesentlichen jetzt nicht von Null schreiben, aber halt quasi jede Zeile nochmal neu überdenken.

Weil es halt quasi immer so Interaktionen zwischen den neuen Sprachfeatern und den alten Sprachfeatern gibt und die waren halt nicht zu übersehen.

Also da, ich weiß nicht, was war mit 2.3 dazu?

Vielleicht Generatoren oder so?

Gab es da nicht auch irgendwelche Stoping-Änderungen?

Ja, kann sein, ich weiß es nicht mehr genau, ja, aber.

Long time and sowas.

Auf jeden Fall, die haben halt dann immer nicht funktioniert in Psycho und Armin hat halt irgendwann auch aufgegeben.

Also Psycho ist, glaube ich, seit 2.4 oder 2.5 einfach auch tot.

Und er hat halt aus dieser Frustration raus dann angefangen, sich in PyPy, also war einer der Projektgründer von PiPy, und hat halt aus dieser Frustration raus, dass man den JIT aus Psycho für jede Version von Hand dann anpassen muss, sich so eine, sag ich mal, relativ gewagte akademische Idee ausgesucht, die er gerne auf PyPy anwenden wollte.

Und das ist eben die Idee, dass man den JIT überhaupt, also JIT heißt, das ist die Abkürzung Justin-Time-Compiler, dass man den überhaupt nicht von Hand schreibt.

Und statt der eben weil Python eine Sprache ist, die sich ständig ändert.

Also einmal im Jahr oder vielleicht damals war es alle anderthalb Jahre, kommt eine neue Python-Version raus, da gibt es neue Sprachfeature.

Und das Anpassen des JIT-Compilers an die neuen Sprachfeatures, das ist zu nervig.

Insbesondere wenn man halt nicht irgendwie Google-Geld hat.

Wenn man Google Geld hat, dann kann man halt einfach 20 Ingenieure auf das Problem.

Und die haben dann halt keinen Spaß, die schreiben ganz, ganz viel komplizierten C<unk>-Code und sind halt jede Woche sehr traurig.

Aber wenn man dieses Budget halt nicht hat, dann ist es einfach zu anstrengend, mit C Python mitzuhalten, also mit der Sprachenklickung mitzuhalten.

Und deswegen hatte er eben die Idee, dass es doch irgendwie möglich sein sollte, den JIT-Compiler automatisch zu generieren.

Und das ist so ein bisschen so eine alte, sehr akademische Idee.

Also da gibt es halt irgendwie in den, ich glaube in den Ende der 70er gab es so einen Aufsatz von Futamura, irgendwie, weiß nicht genau, wie der Titel ist, ein Compiler-Compiler.

Da gab es eben schon mal die Idee, dass es theoretisch eben sein sollte, möglich sein sollte, einen Compiler für eine Sprache automatisch zu erzeugen aus einem Interpreter für die Sprache.

Und das war aber halt ein sehr akademischer Anwendung.

Ich meine, ein Compiler-Compiler und so, das ist ja Jack und so.

Ja, aber da ist der Input halt kein Interpreter, sondern nein.

Nee, nee, das ist Grammatik, ja.

Aber die Idee von der Mura-Projektion ist eben wirklich, man hat einen Interpreter für eine Sprache und erzeugt mit einem komplizierten Prozess aus dem Interpreter automatisch einen Compiler.

Und das gab es quasi als akademische Idee, da gab es auch ein ganzes Forschungsfeld und ganz unglaublich viele Aufsätze zu.

Aber das hat sich halt in der Praxis nicht so richtig umgesetzt.

Und Armin hat halt die Idee gehabt, wir machen das jetzt, wir machen das jetzt einmal richtig.

Also wir machen das jetzt halt.

Also der hat sich in gewisser Weise auch sehr viel getraut.

Er hat gesagt, ich habe jetzt diese Vision, das müsste doch irgendwie gehen.

Und wir wollen das jetzt für eine echte Sprache halt auch wirklich dann mal anwenden.

Und in gewisser Weise ist das Problem natürlich auch noch erstmal schwieriger, weil er nicht nur einen Compiler wollte, er wollte halt einen JIT-Compiler.

Und er hatte da so ein paar Ideen, wie man diese alte Idee der Futamora-Projektion, wie man die halt wirklich dann mal so ganz konkret, nicht für irgendeine akademische Minisprache, sondern für so eine richtige Programmiersprache, wie Python halt dann auch anwenden kann.

Und das haben wir dann halt in den verschiedenen PyPy-Research-Projekten auch dann gemacht.

Das ging auch ganz schön lange nicht.

Also es hat halt wirklich dann auch ein paar Jahre gedauert, bis es dann wirklich auch funktioniert hat.

Also PyPy ist ein Compiler-Compiler.

Also PyPy hat PyPy hat so ein paar Komponenten, aber eine der Komponenten ist wirklich quasi ein JIT-Compiler-Generator.

Und du steckst quasi einen Interpreter in diesen JIT-Compiler-Generator raus und der Output davon ist ein JIT-Compiler für die Sprache, die von deinem Interpreter spezifiziert wird.

Und das hat Riesenvorteile, weil nämlich, wenn, also nehmen wir mal so was Konkretes wie Pattern Matching.

Pattern Matching kommt jetzt raus in 3C.

Dann implementieren wir das in unserem Interpreter.

Also Piper ist ein Interpreter für Python.

Und wir müssen das Feature halt implementieren, weil unser Interpreter, der kann das erstmal nicht.

Also ihr implementiert das aber in C?

Nein, nein, in R Python.

In R Python, genau.

Das ist alles in R Python.

Aber wir interpretieren das quasi in dem in AirPython geschriebenen Interpreter.

Und dann drücken wir auf den Knopf und dann kommt der JIT-Compiler-Generator und der nimmt den Interpreter mit dem neuen Feature und dann haben wir plötzlich einen JIT-Compiler, der quasi Patternmatching versteht und richtig guten Maschinencode für Patternmatching erzeugt.

Und der JIT-Compiler-Generator, der kennt Pattern Matching halt gar nicht.

Sondern der lernt die Semantik von Pattern Matching halt wirklich, indem man sich anschaut, was der Interpreter macht, um die Patterns auszuführen.

Aber das heißt eben, wir müssen nicht, wenn so eine neue Version rauskommt, müssen wir nicht jedes Mal den JIT-Compiler anfassen.

Weil der JIT-Compiler, der kann halt überhaupt keinen Python.

Sondern der kriegt halt die Semantik von Python ab, also indem man sich diesen Interpreter für Python anschaut.

Und wenn man den Interpreter für Python neue Features einbaut, dann hat man immer automatisch auch noch, kann man eben für diese neuen Features dann auch den JIT generieren.

Aber ein weiterer Vorteil, den man damit eventuell hätte, ist, man kann dann damit ja einen JIT-Compiler für jede Sprache erzeugen, für die man in App einen Interpreter schreiben kann.

Genau.

Das geht ja dann wahrscheinlich für viele Sprachen.

Ja, zum Beispiel, wir hatten da schon ein Beispiel vorhin für reguläre Ausdrücke.

Ach, ja.

Also wir hatten ja vorhin gesagt, dass wir halt relativ gut darin sind, reguläre Ausdrücke auszuführen.

Und das liegt halt einfach daran, dass in Python ist das auch schon so.

Reguläre Ausdrücke, die werden in so einen kleinen Bytecode erzeugt, der übersetzt.

Das ist ein anderer Bytecode als der Python-Bytecode.

Und dafür gibt es dann einen Interpreter, der Teil von C Python ist.

Also C Python hat halt den Interpreter für Python, aber eben auch noch einen anderen Interpreter für die regulären Ausdrücke Bytecodes.

Und den haben wir halt auch in AirPython geschrieben.

Und das heißt, wir können halt auch zur Laufzeit dann die regulären Ausdrücke nach Maschinencode übersetzen.

Weil wir halt quasi für diesen anderen Interpreter, der auch in AirPython geschrieben ist, auch ein JIT erzeugen.

Und tatsächlich gibt es halt so einen ganzen Haufen an Research-Quality, Sprachimplementierungen, die halt diese ganze Maschinerie auch benutzen, um alle möglichen Experimente zu machen.

Also wir haben halt auch mal eine Ruby-Implementierung geschrieben und eine PHP-Implementierung geschrieben und eine Prolog geschrieben, das war meine Bachelorarbeit.

Und die sind jetzt alle nicht so cool, ja.

Also da wurde halt einfach nicht der Aufwand reingesteckt, den man betreiben müsste, um da jetzt wirklich, sag ich mal, eine Production-Ruby-Implementierung dann rauszukriegen.

Aber also das waren halt eher so dann der Versuch zu gucken, ob das mit Ruby auch geht oder mit Prolog auch geht.

Ich habe zum Beispiel auch mal, also auch nur Research Quality, ich habe zum Beispiel auch mal eine Datenbank darin implementiert.

Also ich habe halt eine SQLite kompatible, also SQLite kompiliert halt die den SQL-Code auch in so einen Bytecode.

Dafür habe ich halt auch einen Interpreter an Appwitzen geschrieben.

Und damit kann man halt dann auch ganz interessante Performance Gewinne sich dann irgendwie abholen.

Ja, die Datenbank muss das ja auch interpretieren, was da anfährlich so kommt.

Genau.

Und das ist ja auch, ich meine, das weiß man ja auch immer so ein bisschen, dass das SQLite mit den Typen der Spalten auch nicht so ernst nimmt.

Ja, ja, da kann man, ja, oder Swing beides.

Das heißt,

es ist auch noch eine dynamische Sprache.

Dynamischierte Programmiersprache.

Also da gibt es halt dann schon ganz schön viele Ähnlichkeiten zur Ausführung von Python in gewisser Weise.

Naja, auf jeden Fall so diese Idee, dass wir halt quasi einen JIT-Generator haben und diese Architektur sorgt dafür, dass wir halt mit einem relativ kleinen Team halt mit C-Python trotzdem ganz gut mithalten können.

Weil wir die Features halt eben nicht in den JIT-Compiler einschreiben, reinprogrammieren müssen, sondern halt quasi nur in einen Interpreter und der JIT-Compiler, der kriegt die Features dann automatisch.

Das war jetzt so ein paar Verallgemeinerungen waren jetzt, also so ein paar Ungenauigkeiten waren in meiner Story jetzt noch drin.

Es gibt dann noch so extra Annotationen, die nennen wir ja irgendwie Hints.

Man kann halt quasi dem JIT-Compiler da noch so ein paar Tipps geben.

Ja, weil wahrscheinlich manchmal wird das halt dann überraschend nicht gut funktionieren.

Und man kriegt halt dann Maschinencode und der ist vielleicht noch nicht so gut, wie man den gern hätte.

Und dann fügt man halt noch so ein paar Annotationen ein und kann dann dem JIT-Compiler-Generator helfen, doch noch einen besseren JIT zu generieren.

Und das muss man dann für verschiedenen Stellen auch immer mal machen.

Also zum Beispiel, ich würde jetzt meine Hand nicht ins Feuer legen, dass Pattern Matching halt jetzt schon ultra schnell ist.

Also wir haben halt ein JIT für Pattern Matching, aber ich weiß noch nicht, ich habe es noch nicht gemessen, ob es wirklich ein ganz toller JIT ist.

Das ist eh ziemlich langsam, ne?

In T-Baden ist das nicht so toll, oder?

Ich weiß nicht, was.

Ich glaube, also habe ich gehört, dass es nicht so

schnell ist.

Ich weiß nicht.

Also ob das jetzt bei uns, also wir würden halt dann wirklich aus dem Patternmatching Maschinencode erzeugen.

Und ich weiß halt noch nicht so richtig, ob das richtig guter Maschinencode ist oder ob das halt einfach nur irgendwie so ein bisschen leicht schrottiger Maschinencode ist.

Und wenn man das verbessern will, dann würde man halt halt hergehen und sagen, na gut, was für extra Hilfen können wir dem JIT noch geben.

Das habe ich jetzt halt noch nicht gemacht, weil ich meine, das ist halt immer so ein bisschen, das kommt halt als letztes.

Du musst halt quasi aber immer den Generator anlernen.

Du kannst halt quasi nie richtig in der Hand, was wirklich da liegt an C-Code, der hinterher ausgeführt wird.

Also indirekt

Moment, warum C-Code?

Ja, weil du doch dem Generator sagst, was er tun soll, der den C-Code generiert, der dann hinterher ausgeführt wird.

Ja, der C-Code ist dir eigentlich so ein bisschen egal.

Also wichtig ist halt, du generierst einmal C-Code, aber du generierst halt auch noch einen JIT und der JIT, der übersetzt es halt den Python-Code nicht nach C-Code, sondern wirklich direkt nach Maschinencode.

Also wir erzeugen dann wirklich, wir nehmen den Python-Code, führen den aus und nach einer Weile sagen wir halt, oh, okay, diese Schleife hier, die scheint irgendwie wichtig zu sein.

Und dann nehmen wir wirklich diese Schleife und erzeugen daraus halt wirklich direkt ins RAM Maschinencode-Instruktionen.

Und das geht halt nicht mehr den Umweg über C.

Den Umweg über C brauchen wir nur, um einmal das Binary zu erzeugen.

Das machen halt wir einmal auf unserem Server und das passiert aber dann quasi nach dem Deployment auf die Produktivunktewegung nicht mehr, sondern da wird halt wirklich direkt direkt ins RAM werden halt die Maschineninstruktionen für die aktuelle CPU-Architektur emittet und dann führen wir das halt direkt aus.

Also sprich, wenn du das halt auf irgendwie so auf so einem X86-Server laufen lässt, dann schnappen wir uns halt einfach vom Betriebssystem so einen großen Buffer an RAM und da kommen halt dann irgendwelche Instruktionen rein und dann wird der Buffer als ausführbar markiert und dann springen wir da einfach hin.

Und dann von da an läuft halt wirklich der Maschinencode und der, also wenn man Glück hat, ist er halt einfach dann auch sehr, sehr schnell.

Weil der das ganze teure Zeug, was in Python halt normalerweise die ganze Zeit passieren muss, halt nicht mehr macht.

In den ganzen Overhead von den ganzen Sachen, finde ich.

Also und der Overhead, also man hat halt dann die Frame-Objekte nicht mehr, man hat die ganzen Typüberprüfungen nicht mehr, idealerweise.

Man hat, also Python alloziert ja auch die ganze Zeit Speicher.

Also jeder Integer ist ja so ein bisschen Heap-Memory.

Also jede Addition macht halt einen Merlog-Aufruf.

Und das ist ja eigentlich absurd teuer.

Also ein Mallog-Aufruf und es wird eben der Reference-Count auch noch immer manipuliert.

Vielleicht auch nochmal ganz kurz für die Leute, die ja nicht ganz so tief tun.

Ein Mallog-Aufruf, also eine Memory-Agglocation ist in C eine Funktion, die auf dem Heap, was macht?

Vielleicht nochmal ganz kurz.

Ganz tief rein, erklär mir, was Heap steckt.

Vielleicht kann man das einfach nochmal so ein bisschen den Kontrast herstellen mit, wir schreiben jetzt wirklich ein Programm in C.

Und wenn du da halt irgendwie eine Integer-Variable, also Long A und Long B hast und dann machst du A plus B, dann sind A und B halt nicht auf dem Heap, sondern irgendwie direkt in CPU-Registern.

Und die werden dann direkt von CPU-Instruktionen addiert und mit dem Ergebnis wird halt irgendwas gemacht.

Wenn du irgendwie so einen Ausdruck wie A und B in Python hinschreibst und das in C-Python ausführst, dann ist das halt nicht, also die Integer-Werte, die sind dann nicht in CPU-Registern, sondern die sind quasi im RAM.

Und um dann wirklich das Ergebnis berechnen zu können, musst du die Werte erstmal aus dem RAM, also erstmal musst du gucken, sind das überhaupt Integers, die ich da addiere?

Und dann musst du gucken, dann musst du quasi die Werte der Integer aus dem Integer-Objekt vom RAM in CPU-Register laden.

Dann machst du wirklich die Addition.

Dann musst du gucken, ob das Ergebnis immer noch klein genug ist, um in einen Maschinenwort reinzupassen.

Das könnte ja auch irgendwie einen Overflow geben und dann brauchst du irgendwie ein komplizierteres Objekt.

Und dann brauchst du Speicher für das Ergebnis-Objekt, weil das Ergebnis ist ja auch wieder ein Integer-Ojekt.

Das heißt, du rufst einmal einen Mellog auf.

Dann kriegst du ein neues Stück RAM zugewiesen von dem in C geschriebenen Allokator.

Und dann packst du den Ergebnis-Zahlenwert in dieses neue Stück RAM rein, erhöhst den Reference-Count von diesem Stück RAM und das ist dann dein Ergebnisobjekt.

Und das passiert aber halt bei jeder arithmetischen Operation.

Und deswegen ist halt Arithmetik, und wir haben auch noch so ein paar Schritte weggelassen.

Deswegen ist Arithmetik halt in Python klassischerweise wirklich sehr, sehr ineffizient.

Weil du halt wirklich ständig Mellog aufrufst und auch ständig wieder Free aufrufst.

Zum Beispiel, wenn du jetzt so einen komplizierteren Ausdruck hast, wenn du halt sowas wie A mal 2 plus B, das war ja unser standardarithmetischer Ausdruck schon in der Zeit, dann hast du halt das Zwischenergebnis A mal 2, das brauchst du ja gar nicht lang.

Das brauchst du ja quasi nur.

Das verfällt ja beim nächsten Mal.

Das heißt, beim nächsten Aufruf, wenn du dann das Plus rechnest, dann verringerst du den Reference-Count von dem Zwischenergebnis und dann sagst du, oh, das ist ja jetzt null.

Das brauche ich ja gar nicht mehr.

Und dann rufst du Free auf.

Das ist wieder quasi so ein teurer Aufruf zu dem Memory-Substant-Programm.

Schreibt der Null den Speicher oder löscht er einfach die Speicheradresse, aus dem wir benutzen das?

Genau, und dann kannst du quasi den Speicher wiederverwenden, das nächste Mal, wenn jemand Melod aufkommt.

Aber der schreibt dann nicht vorher irgendwie was rein.

Doch, der muss das dann schon halt, der muss sich schon irgendwie merken, dass der Speicher jetzt verwendet werden kann.

Also es gibt halt so ein bisschen, es gibt quasi so ein bisschen Overhead-Datenstrukturen, die verwendet werden, um sich zu merken, dass das jetzt ein Stück freier Speicher ist.

Der schreibt ja am Anfang von einem Speicherblock schreibt er irgendwie so ein.

Das ist, glaube ich, gar nicht so wichtig.

Das funktioniert auch sehr unterschiedlich, je nach Betriebsthemen und je nach verwendetem Allokator.

Also da gibt es halt auch verschiedene C-Bibliotheken, die man ja verwenden kann.

C-Python hat da auch so ein bisschen so seine eigenen Algorithmen, die für den typischen Use Case, der halt in Python besonders oft auftritt, dann optimiert ist.

Also da ist quasi dann ganz, ganz viel Engineering und es ist kompliziert und wir müssen das hoffentlich nicht verstehen.

Also das, ja, das ist quasi, da kenne ich mich dann irgendwann auch ziemlich schnell halt auch nicht aus.

Ja, aber letztlich, das Problem ist halt, dass es halt, ja, Speicheraluzin ist halt eine relativ komplexe, weil man halt auch das Betriebssystem den Kernel fragen muss, letztlich.

Also natürlich.

Am Schluss

dann, nicht jedes Mal, aber nicht.

Nichtes Mal,

aber irgendwann schon, ganz nicht.

Und dann, dass natürlich alles sauteuer ist.

Und dieser ganze Oberhead fällt halt weg, wenn du A plus B mal C mit ausführst und Dagit ging darüber, dann hast du halt wirklich auch, dann adnotizierst du dieses Zwischenergebnis auch nicht.

Sondern dann sagst du halt einfach, na gut, A kommt in ein Maschinenregister, das mal 2 ist halt irgendwie so ein Intermediate in deiner Maschinen-Instruction und dann hast du noch eine zweite Maschinen-Instruction, um die Addition zu machen.

Und das Ergebnis ist auch in einem Register, je nachdem, was mit dem Ergebnis passiert, kann es da auch bleiben.

Ja, also wenn du dann einen Return hast, dann kann das quasi im Return-Register der CPU halt auch dann einfach weiterverwendet werden vom Aufrufer.

So ein bisschen, wenn alles genau richtig ist, wenn alles genau richtig läuft.

Und dann fällt halt einfach ganz, ganz, ganz viel Overhead, den die normale Python-Implementierung halt immer machen muss, fällt halt weg.

Ja.

Und ich meine, so ein bisschen die Einsicht, warum man halt Python überhaupt optimieren kann, ist, es ist theoretisch alles sehr dynamisch, aber in der Praxis nicht.

Also die dynamischen Möglichkeiten, die werden halt.

Sehr selten genutzt tatsächlich.

Ja, jetzt nicht selten.

Aber halt nicht immer.

Also ich glaube halt, jedes Programm ist schon an irgendeiner Stelle dynamisch, aber nicht die ganze Zeit.

Es ist zum Beispiel relativ oft so, dass man beim Importen halt ganz viel Zeug macht, aber danach nicht mehr.

Das ist so ein Muster an Dynamischkeit.

Also du importierst halt eine Bibliothek, beim Importieren macht die ganz merkwürdige Sachen und macht halt so ein bisschen Metaprogrammierung und schreibt irgendwelche Sachen in das Globals Dictionary mit einem Globals Aufruf oder sowas, schreibt es da rein, aber dann ist fertig.

Und danach ist alles quasi harmloser Python-Code, wo die Typen relativ fix sind.

Also das ist so eine Sache, die wir immer wieder sehen.

Da gibt es auch Aufsätze dazu, die das studieren.

Also das findet sich halt recht häufig wieder, dass man komische, dynamische Sachen am Anfang des Programms macht, aber dann irgendwann nicht mehr.

Also so ein ORM ist halt auch so ein Beispiel.

Man generiert halt dann so ein bisschen Klassen, aber das macht man halt nicht die ganze Zeit, sondern halt.

Genau, ja.

Ja, oder halt so ein Debugger ist halt auch ein Stand.

Also ein Debugger braucht quasi ganz, ganz viele dynamische Features.

Aber der ist halt meistens nicht an.

Und du musst quasi die Möglichkeit haben, dass du den zu einem beliebigen Zeitpunkt anschalten kannst.

Aber du solltest nicht die ganze Zeit den Preis dafür bezahlen müssen.

Aber du willst dich halt auch nicht vorher entscheiden müssen.

Ja, also du willst halt quasi trotzdem immer die Möglichkeit haben zu sagen, jetzt brauche ich den

aber debuggen, weil wenn es zu unterschiedlich ist, dann kann man nicht mehr debuggen halt.

Ja, ja, genau.

Man möchte es ja dann machen können, wenn es eigentlich normal läuft.

Und selbst wenn es jetzt halt nicht um den Debugger geht, also selbst halt sowas wie schöne Tracebacks, die dir halt auch noch die Locals rausschreiben oder so.

Wenn halt dann, wenn halt dein Webserver dann wirklich crasht, dann willst du diese Information halt haben.

Und dann zu sagen, ja, hm, ups, jetzt haben wir das aber so doll optimiert, dass wir, wir wissen halt gar nicht mehr, was die Locals sind.

Also das kann dir halt passieren in so einem Compiler.

Also in C gibt es es ja immer mal.

Da musst du ja wirklich sagen, will ich jetzt die Buggy-Informationen haben oder nicht.

Und wenn du die nicht hast, dann kriegst du, dann kriegst du, dann sagt dir halt keiner mehr, was jetzt gerade in deiner Variable drin steht.

Und meiner Einsicht nach gehört das halt zur Philosophie von Python auch dazu.

Dass man halt zu jedem Zeitpunkt das auch dann machen kann, wenn man halt in einer Situation landet, wo man die Informationen braucht.

Genau.

So, jetzt haben wir glaube ich so ein bisschen alle Ideen.

Also historisch gesehen, PyPy, Python <unk> Python, also historisch gab es diese Verständlichkeitsidee, die verschwindet ein bisschen.

Also es gibt jetzt schon ganz viele Stellen, wo wir Sachen halt quasi komplizierter machen, um Performance zu kriegen.

Also es ist jetzt nicht mehr nur so ein architektonisch reines Ding, womit man halt irgendwie die Sprache ganz toll verstehen kann, sondern halt wirklich viel pragmatischer und wir wollen halt auch wirklich schnellen Code machen.

Aber stattdessen kam halt diese andere Idee dazu, wir wollen einen Just-in-Time-Compiler für die Sprache haben.

Und weil sich die Sprache eben einmal im Jahr ändert, können wir den nicht von Hand schreiben, weil wir halt nicht Google-Geld haben, sondern irgendwie ein Open-Source-Projekt sind.

Und stattdessen wurde halt dann dieser Forschungsansatz gewählt, wir erzeugen den Justin-Time-Compiler.

Und das hat geklappt.

Also das hätte auch schief gehen können, aber die Kernidee funktioniert ganz gut.

Und jetzt sind wir quasi so ein bisschen auf dem Plateau der Produktivität, dass die so die ganze Kerntechnologie, den DIT-Compiler zu erzeugen, die ist halt relativ stabil.

Es gibt jetzt schon irgendwie da noch so ein paar Features, die wir gerne irgendwie mal machen würden, wenn wir mal ganz motiviert sind oder ganz viel Zeit haben.

Aber so die ganzen Kernideen sind, die sind halt einfach jetzt inzwischen auch drin und stabil und halt über viele Jahre halt auch wirklich so ganz gut stabilisiert.

Und jetzt sind wir halt an dem Punkt, dass wir Hauptarbeit, die wir wirklich machen, ist halt zu versuchen, von C-Python nicht komplett abgehängt zu werden.

Ist R-Python hat das Type-Annotation zum Beispiel auch?

Ja, jetzt kommen wir so, jetzt kommen wir zu ein paar der dunklen Geheimnisse.

Also, PyPy ist so alt, dass es gegründet wurde, als Python 2.2, glaube ich, gerade aktuell war oder 2.3.

Das heißt, RPython ist leider tatsächlich noch komplett Python 2 basiert.

Und wir haben halt sehr leider auch sehr, sehr wenig Motivation, das zu ändern, weil wir haben halt leider sowas wie, sag ich mal, eine halbe Million Zeilen Code in dieser blöden, in diesem blöden Python 2-Dialekt.

Und wir könnten uns jetzt hinsetzen und einfach, um jetzt mal eine Schätzung abzugeben, zwei Person-Yars reinstecken, das nach Python 3 zu portieren.

Aber das wäre halt wirklich, ich denke, wirklich zwei Jahre Arbeit.

Und danach hätten wir einfach kein einziges neues Feature.

Das heißt, da hat halt einfach niemand so wirklich Lust drauf.

Und das ist natürlich, wir sind da natürlich so ein bisschen in so einer, also Falle wäre jetzt viel gesagt, aber ein bisschen in so einer blöden Situation.

Weil das ist halt nix, wofür momentan sind das halt wirklich eher so Open Source-Modell.

Da ist jetzt keiner, der dafür wirklich jetzt bezahlt wird, sag ich mal.

Und jetzt so eine Portierungsaktion zu starten, ist halt einfach nur so, also mir würde das halt nicht so viel Spaß machen.

Ja, ja, klar.

Sag ich halt mal so.

Aber das ist natürlich trotzdem in gewisser Weise auch kein Zustand, ja.

Also weil irgendwie, also man will halt auch letztlich dann irgendwie auch nicht komplett abgehängt werden.

Das wird dann wahrscheinlich irgendwann auch ein Problem, da neue Leute ranzuführen, weil man denen dann ja irgendwie erklärt.

Ja, genau,

das hast du jetzt schon vergessen.

Das Print hat keine Klammern.

Ja, okay.

Ich meine, das andere, so ein bisschen Doppelproblem, ist halt, dass so ein Interpreter, der benutzt halt an keiner Stelle Unicode.

Das heißt, so halt eines der Hauptargumente, warum, wo Python 3 halt ein paar Sachen so richtig schön gemacht hat, die fallen weg, weil wir halt einfach immer nur ByteStrings benutzen.

Und deswegen, das wäre halt, das ist halt quasi auch nochmal so ein Grund, warum Python 3 jetzt halt auch letztlich jetzt nicht so wirklich so eine Verbesserung ist, sondern halt, wir würden das wirklich machen, um halt nicht abgehängt zu werden, aber nicht, weil wir, weil wir jetzt wirklich von den Python 3-Features so mega motiviert werden.

Und das ist halt ein bisschen doof.

Also, und irgend, also.

Würde denn irgendwie diese, keine Ahnung, Type Hins oder andere Features von Python 3 jetzt für die Annotation von dem Compiler irgendwas bringen?

Nicht so richtig.

Also man könnte sich, klar, man kann dann so ein paar der APIs vielleicht ein bisschen schöner machen, aber wir haben jetzt halt Dekoratoren und die sind jetzt auch nicht so schrecklich.

Ich meine, ob du jetzt halt das dann mit Doppelpunkt direkt hinter die Argumente schreiben kannst oder in der Zeile drüber mit dem Dekorator, den wir halt uns selber ausgedacht haben.

Ja, das wäre schon ein bisschen netter, aber das wäre jetzt nicht, also das wäre jetzt halt für mich nicht so eine ganz ausreichende Motivation, um halt irgendwie so ein riesen Refactoring-Projekt zu starten.

Also ich denke halt, so ein, also das wird halt stattfinden, wenn wir irgendjemanden finden, der da mega Bock drauf hat, oder wenn wir halt Geld finden.

Und ich glaube, wenn beides nicht stattfindet, dann vielleicht bin ich dazu pessimistisch, aber dann sehe ich das im Moment halt nicht.

Ja gut, klar.

Also ja, also ich persönlich, ich kann nur über mich sprechen, ich persönlich würde es, hätte da halt keinen Spaß dran.

Ja, aber ich meine, ist es dann, wenn man tatsächlich kein Unicode hat, sondern nur bei Swings, ich meine, es gibt ja da so automatische Geschichten, könnte man das nicht eventuell auch automatisch.

Also ob man da halt einfach einmal so zwei Two to three

draußen meistens lassen und

wir müssen halt einfach, irgendwann müssen wir das mal gucken und wir haben noch nicht so ganz, wir haben noch nicht so ganz den pragmatischen Weg gefunden, den man halt gehen kann.

Weil es ist halt auch so die Frage, macht man dann einmal einen Cut und sagt, Leute, halt, niemand macht mir neue Features für sechs Monate.

Das ist halt auch doof, ne?

Also.

Ja.

Aber wir sind ja auch nicht die einzigen.

Also es gibt ja auch wirklich leider noch ganz viele Firmen, die große Mengen an Python 2 guckt haben.

Aber ja, es ist halt, also man will das jetzt halt keine zehn Jahre so weitermachen.

Das ist, ja, also.

Aber so den idealen Weg, wie wir da jetzt wieder rauskommen aus der Geschichte, den, den haben wir, den wissen wir halt im Moment halt auch nicht.

Außer wir finden jetzt jemanden, der sagt, hier habt ihr eine Million Dollar und macht doch bitte mal, dann ist sowas halt auch wieder.

Also ihr könnt hier schreien direkt.

Also das ist, das ist bei dem Django-Projekt gibt es sowas ähnliches mit dem Admin mit dem Django-Admin, das ist halt auch so ein Ding.

Das ist über Django-Projekts ja auch halt 15 Jahre oder so, das ist halt in die Zeit gewachsen.

Teilweise ist da halt auch Geld reingesteckt worden, das zu entwickeln und inzwischen ist es halt auch so, die Schätzung ist ähnlich etwa, also Leute, die sich damit auskennt, sagen halt so, ja, also das jetzt mal so richtig neu zu schreiben und natürlich, wir wissen inzwischen, was wir alles gerne lieber machen würden, würde wahrscheinlich so eine Million kosten und tja, die haben wir halt nicht.

So ist es halt so ein bisschen auch.

Und ich meine, das sieht man ja auch wirklich ganz konkret bei C-Preisen.

Also C-Preiten 3.11 und 3.10 sind halt einfach auch wirklich viel schneller geworden.

Und das ist halt einfach eine Geldfrage.

Also wenn du halt plötzlich fünf Leute hast, die einfach fulltime bezahlt werden und das sind ja auch jetzt nicht irgendwelche Leute, sondern halt auch gute Leute, dann passiert halt auch was.

Und wir können halt quasi so ein bisschen durch schlaue Architektur, die wir vor zehn Jahren halt quasi geschrieben haben, dadurch können wir halt irgendwie ziemlich gut mithalten, weil der TIT-Generator halt da ist und gut funktioniert.

Aber halt alles, was jetzt mal so irgendwie so Big, also Bonus Weights, ist schon zu negativ.

Aber alles, was jetzt halt irgendwie so eine ganz tiefgreifende Veränderung bräuchte, das kriegen wir halt mit dem jetzigen Funningstand nicht hin.

Weil das kriegst du halt nicht durch.

Also wir haben wir haben halt auch schon so ein Open Collective Dings und wir kriegen auch Donations und da wir sind da auch super dankbar dafür.

Da kommt auf jeden Fall auch irgendwie immer wieder gut was zusammen.

Aber es ist halt was anderes, wenn du plötzlich fünf Leute anstellen kannst.

Und da sind wir halt nicht.

Und da haben wir halt auch gerade nicht so richtig die Person, die da hinterher wäre, diese Gelder dann auch zu suchen.

Also wir hatten ja vorhin schon kurz drüber geredet, wir hatten halt irgendwie zweimal so wirklich große Forschungsförderungsprojekte, einmal, also beides mal EU-finanziert.

Das eine war von 2004 bis 2006, das andere von 2008 bis 2010 so ungefähr.

Und da hatten wir halt dann wirklich einige Vollzeitleute, die da einfach wirklich dann über diese Zeiträume halt auch wirklich immer nur an diesem ganzen Zeug gearbeitet haben.

Und da kam halt dann auch wirklich was raus.

Und dann danach hatten wir halt viel so immer wieder Funding auch von Firmen, die halt dann bestimmte Features gerne haben wollen.

Aber seit einer Weile gibt es halt niemanden, der jetzt Bock auf.

Es ist halt nochmal so ein ganz eigener Task, für Open Source Geld zu finden.

Und man braucht halt da so ein bisschen ganz eigene Skills auch.

Und so eine Person haben wir jetzt nicht mehr.

Und das ist in gewisser Weise nicht so ein perfekter Zustand.

Ja, und ich meine, selbst für Projekte, die halt sehr viel genutzt werden, also sowas wie Pandas, mich wundert das immer, oder es gibt ja die diverse, es gibt ja ganz viele, wo die Basis für jede Menge.

Genau, das ist Basis für Milliardenumsätze irgendwie in der Industrie, aber trotzdem gibt es da eigentlich für die Entwicklung nicht so richtig viel Geld.

Also der andere sehr aktive, momentan sehr aktive PiPi-Entwickler, der Mathi Picos, der ist tatsächlich bei einer Firma angestellt, die darauf spezialisiert ist, halt NumPy voranzubringen und halt dann da einer der Leute, die halt wirklich auch quasi finanziert, NumPy-Bugs fixt, das ist auch Teil, heißt das auch Steering Council bei NumPy?

Was hast du für dich?

Nee, keine Ahnung.

Also der ist auch quasi Teil des Komitees, das halt Numpai verwaltet und ist da sehr aktiv.

Deswegen geht Numpai auch gut auf PiPai, weil er sich halt da darum auch kümmert.

Ja, also bei Numpai passiert es langsam eben schon.

Also sowas wie Jupyter hat halt auch Funding und da gibt es halt inzwischen in den USA schon auch halt Firmen und Foundations, die halt erkannt haben, dass es einfach so ein wichtiges Stück Infrastruktur ist, dass es halt vielleicht doch auch eine gute Idee ist.

Das ganze Internet an so einem kleinen Faden aufhängt.

Ja, ja, also die Idee fand ich auch ganz, ganz charmant, dass man sagt, ja, also eigentlich müsste man das Firmen so verkaufen, dass es halt eine Versicherung ist.

Wenn sie da nichts, also sie zahlen sozusagen eine Art Versicherungspoliz dafür, dass es das halt auch in Zukunft gibt, weil wenn sie es das nicht mehr geben sollte, haben sie ein großes Problem.

Ich weiß nicht, was da die Antwort ist.

Ich finde halt auch letztlich, in gewisser Weise ist das wirklich auch was, was man über Steuern machen könnte.

Ja, natürlich.

Und passiert ja ein Stück weit auch.

Also halt sowas wie die, wie, wie, ich glaube, es ist ja.

Projektanträge schreiben, ne?

Müsste man halt Projektanträge schreiben haben.

Und da ist es halt dann so ein bisschen so, da ist halt PiPy dann letztlich auch vielleicht nicht wichtig genug.

Also bei Piper kann man halt nicht sagen, dass es jetzt eine absolut grundlegende Technologie wie NumPy.

Weil so viele Leute benutzen es halt dann irgendwie doch nicht.

Und klar, wir finden halt auch immer ganz tolle Bugs in C-Python und ich glaube schon, dass jetzt unser Wert halt jetzt auch, selbst wenn man das nicht einsetzt, ist es halt nicht null, da haben wir vorhin über ein paar Beispiele geredet.

Aber es ist halt auch nicht klar, ob wir jetzt das Projekt sind, für das irgendjemand ein paar Vollzeitentwickler dann bezahlen sollte.

Also ich meine, klar, wir könnten die, wenn wir die hätten, dann könnten wir ganz, ganz tolle Sachen machen.

Auf jeden Fall, ich habe eine ganz lange Liste.

Also schickt das gerne zu mir, aber wenn man dann so einen Antrag schreibt, ist mir halt nicht so klar, ob man sagen kann, wir sind so wichtig wie, was weiß ich, OpenSSL.

Sind wir halt nicht.

Offensichtlich nicht.

Und ja, aber das viel grundlegende Problem ist halt, wir haben im Moment keinen, der da Lust drauf hat.

Oder in dessen Expertise das halt liegt.

Und das ist nicht so gut.

Und es kann schon sein, dass ich da auch vielleicht irgendwann dann auch nochmal drin besser werden muss.

Wenn ihr Lust drauf habt, dann sagt Bescheid.

Wir nehmen gerne Freiwillige an.

Also zum Beispiel zum Beispiel Read the Docs finde ich auch einen sehr interessanten Fall, weil das ja auch letztlich halt einen sehr guten Weg gefunden hat für ein für die Community ultra wichtiges Problem, nämlich wo wird eigentlich die Dokumentation gehostet und wer bezahlt dafür, halt eine Lösung zu finden.

Und die Lösung ist halt, wir finanzieren das einmal durch akzeptable Werbung und eben durch Firmen, die dann damit selber ihre Dokumentation hosten.

Und da gibt es auch coole Podcasts, so ich muss mal gucken, ob mir die Folge einfällt, wo der Read the Docs-Gründer halt dann auch so ein bisschen über seine Philosophie von Outsource Funding redet.

Und ja, ich finde das auch einen ganz coolen Weg eigentlich.

Also, weil die haben ja wirklich jetzt auch einige Entwickler, die halt da an der Infrastruktur arbeiten, die Sphinx vor allem sind, die Dock-Hit Hills-Patches schicken und da ist ja wirklich, also da sind wir ja, da ist die Python-Community ja auch wirklich ziemlich gut aufgestellt.

Also ich finde es auch sehr interessant.

Es gibt wirklich auch an einigen Stellen halt dann Projekte in ganz anderen Sprachen, die halt dann trotzdem Read the Docs nehmen, weil es halt einfach wirklich auch cool ist.

Wer heißt da?

Ist das Eric Holt?

Ja, genau.

Ich glaube, da gab es einen Django Chat-Episode, die gar nicht so lange her ist, vor ein paar Monaten, wo er zu Gast war und da hat er da einige.

Ich packe die auch mal in die Show Notes und nichts mich dran.

Ja.

Ja.

Und ja, ja, nee, das ist ein großartiges Beispiel da.

Naja, und ansonsten ist es halt so, ich habe jetzt halt, also wir haben halt in gewisser Weise einen ganz guten Vorteil, weil ich kann das halt als Teil meiner Arbeit machen.

Ich bin an der Uni eingestellt, ich bin für die Lehre bezahlt, aber wenn die Lehre zu Ende ist, dann darf ich quasi forschen, was ich will.

Ich bin in eine Forschungsgruppe eingebettet, die zumindest irgendwie irgendwie was mit Compilern zu tun auch hat.

Insofern bin ich da jetzt auch nicht, bin da so ein bisschen der Einzige, der ganz konkret was mit Jitcompilern macht im Moment, aber ich bin da jetzt quasi thematisch auch nicht fehl am Platz und mein Chef freut sich da auch, wenn ich da dann was dann mache.

Insofern passieren halt durch das Level, was durch meine halbe Stelle, das ist jetzt nicht, das sind jetzt nicht ultra viele Stunden, aber halt zumindest schon so ein paar Stunden, die sind halt da und die werden halt auch, solange es aus meiner Ansicht nach da halt interessante Forschungsfragen gibt, werden die halt auch für das Projekt auch weiter verwendet werden.

Und das ist halt so ein Basislevel, naja, das muss man halt auch erstmal haben, ja.

Aber das reicht halt nicht, um jetzt reicht jetzt nicht, um jetzt halt irgendwie so eine ganz krasse neue Idee für eine neue DIT-Optimierung sich auszudenken.

Also manchmal, manchmal läuft es dann über Abschlussarbeiten ganz gut.

Also ich hatte gerade eine unglaublich coole Bachelorbeit betreut, das ist jetzt noch nicht gemerkt, aber der hat echt eine sehr interessante neue Optimierung für den DIT-Compiler auch geschrieben, wie auch gerade bei Programmen, die viel mit Integer machen, wirklich nochmal ganz anders Sachen optimieren kann.

Also echt super Student.

Nico Rittinghaus heißt der.

Der hat dann auch so die Originalliteratur aus den 70ern gelesen und meinte so, hier in diesem Paper, was mit Schreibmaschine geschrieben wurde, steht das hier drin.

Da ist doch bei in eurem Code ist das doch ganz anders.

Sag doch mal.

Genau, so, ja.

Und ja, er hat dann, aber er hat auch immer recht.

Also das war sehr, sehr cool mit dem.

Ich hoffe auch, dass er quasi weitermacht und vielleicht irgendwie auch noch eine Bachelorarbeit, äh, eine Masterarbeit schreibt.

Aber manchmal passieren halt dann so dann Sachen, aber bei so Abschlussarbeiten ist das halt schon so, dass die Leute halt dann tendenziell auch wieder weg sind.

Ja, und dann muss man das mal entenden, was ihr gefragt hat.

Nee, das ist eigentlich okay.

Das stimmt, wenn es

schreiben halt Tests und ich bin halt dann schon, ich gehe dann schon auf die Nerven, dass sie jetzt halt auch keinen Scheiß schreiben.

Also so qualitätsmäßig.

Macht ein bisschen Review und Kultur.

Review und Kultur und wir wollen halt schon, wir sind halt jetzt nicht so ein normales Forschungsprojekt, was halt eigentlich Code zum Wegschmeißen.

Also viele Forschungsprojekte sind halt so Code zum Wegschmeißen.

Man schreibt Code, man schreibt einen Paper und dann ist man damit mit dem Thema durch.

Sondern wir sind halt so ein bisschen, in gewisser Weise so ein bisschen ein schlechtes Forschungsprojekt, in dem Sinne, dass wir halt versuchen halt auch Code zu schreiben, wenn Leute benutzen können.

Und deswegen haben wir halt Aufwand, der sich aus Forschungssicht halt irgendwie auch nicht lohnt.

Deswegen bin ich halt vielleicht auch kein Professor.

Sondern weil mein Forschungsoutput halt auch nicht, also weil ich diesen Job auch gar nicht haben wollte, ne?

Also das, aber weil halt so der Output an Aufsätzen bei mir vielleicht halt nicht so ganz stimmt.

Also ich schreibe jetzt schon Aufsätze und die sind halt zum Teil dann auch ganz gut rezipiert und werden zitiert und so, aber vielleicht jetzt nicht mit dem Nachdruck, den man bräuchte, wenn man jetzt halt so ein reiner Akademiker sein wollte.

Naja, ja, das ist auch eine faszinierende Geschichte.

Ich meine, tatsächlich ist es ja dann doch oft so, dass dann Sachen wiederverwendet werden.

Also wenn man dann und dann, also in der Physik, so manche Leute kommen, sieht man das dann häufig, dass dann doch irgendwie so sich Sachen aufeinander türmen, die halt irgendwie man vielleicht dann doch mal, wenn man gewusst hätte, wo man Hintergrund rausgekommen hat, hätte man das doch mal hätte man das vielleicht anders bauen können.

Das ist meine absolute Lieblingsgeschichte, die werde ich jetzt hier noch anbringen.

Oh ja, sehr gerne.

Ich habe tatsächlich, also ursprünglich habe ich mal Mathe und Physik studiert und dann habe ich das abgebrochen, um bei einem der Pipei-Firmen, die halt von der EU Geld gekriegt haben, mitzuarbeiten für eine Weile.

Aber vorher habe ich quasi bei den Teilchenphysikern halt immer so semesterferien, Hiwi-Jobs gehabt.

Und die Teilchenphysiker, die haben so Zern und so, die haben halt ein ganz interessantes Stück Technologie, nämlich die haben einen C<unk> Interpreter.

Ach, weil dann muss man ja nur eine Sprache lernen.

Also wir müssen ja, die Physiker, die müssen ja eh zu C<unk> lernen, um halt schnell einen Code zu schreiben, aber die wollen ja auch Scripting machen.

Und wenn wir jetzt halt so einen C<unk>-Interpreter haben, dann können die ja mit der Sprache, die die E schon können, halt auch ihre Skripte schreiben.

Und das war halt so um 2003 rum war das halt echt noch irgendwie so ein Stück Technologie, was die halt einfach wirklich benutzt haben in der Teilchenphysik.

Und so nach und nach kam halt dann die Erkenntnis, dass das doch irgendwie vielleicht halt so ein bisschen so eine merkwürdige Idee ist.

Und inzwischen nehmen die halt auch einfach Python für Scripting, ja.

Aber das ist halt für mich immer so ein Beispiel, wenn man, also einer, eine so ein Lieblingsaufreger von mir ist, wenn Leute halt von interpretierten Sprachen reden.

Man sagt halt gerne, Python ist eine interpretierte Sprache.

Und das ist halt eigentlich eine Aussage, die meiner Ansicht nach semantisch keinen Sinn macht.

Also es ist sinnleer, weil es ist halt eine Eigenschaft einer Implementierung, ob sie interpretiert ist oder nicht.

Also C-Python ist ein Interpreter, das stimmt, und PyPy ist halt ein JIT-Compiler, das stimmt.

Aber man kann jetzt eben nicht sagen, dass C<unk> eine kompilierte Sprache ist, weil es gibt ja C-Int.

Und das ist halt eine Implementierung von C<unk>, die das interpretiert.

Und deswegen kann man halt nur sagen, na gut, wenn man halt GCC benutzt, dann hat man eine kompilierte Implementierung von C<unk>.

Das ist quasi so ein Randfall, den ich dann gerne anbringe, um zu demonstrieren, dass es halt ein Konzept ist, das keinen Sinn macht, von einer kompilierten Sprache zu sprechen.

Naja, also zum Glück ist das Ding inzwischen, glaube ich, tot.

Also ich, ja.

Ja, interessant.

Tja, ich weiß nicht, spielt eigentlich diese auch so Geschichten mit Software Transactional Memory und so.

Spielt das noch eine Rolle?

Also da gab es halt ein relativ langjähriges Forschungsprojekt, auch von dem Armin Rigo und einem Doktoranden, der in der ETH Zürich, glaube ich, promoviert hat.

Und die hatten halt diese Idee, dass man halt irgendwie Software Transactional Memory benutzen können sollte, um den Overhead von einem DIL, also Global Interpreter Log-Free Multithreading für Python sehr klein zu halten.

Und dieses Forschungsprojekt hat halt, also die haben da auch wirklich viele Jahre dran geforscht und reinzeit investiert.

Das hat halt am Schluss nicht so gut geklappt, wie sie sicherhauptplatten.

Was ist das überhaupt noch?

Vielleicht nochmal.

Also ich bin da sehr schnell raus.

Ich habe das halt immer so interessiert verfolgt und die hatten halt dann so ein Branch und haben da auch jahrelang auch wirklich sehr viel Aufwand reingesteckt.

Aber am Schluss waren sie halt irgendwie mit den Ergebnissen nicht so zufrieden.

Und halt auch, also technische Details, wie gesagt, ist nicht so mein Ding.

Was sollte das denn theoretisch sein?

Also ich habe gar nicht verstanden, was worauf es da gehen soll.

Also die Idee von Software Transactional Memory ist, dass du quasi, also du kannst halt dann mehrere Threads starten, die alle Python-Code ausführen.

Und du machst so einen optimistischen Ansatz, so einen Datenbankansatz.

Jeder Thread hat eine eigene Transaktion und der Thread, der läuft so ein bisschen und dann versucht er zu committen.

Und committen heißt, dass seine Sicht der Welt, also seine Sicht des Zustand des Programms, mit der Sicht der Welt der anderen Threads irgendwie gemerkt werden muss.

Das ist die Transaction.

Und das macht man aber nicht auf der Datenbank-Ebene, sondern wirklich auf der Sprachebene.

Also das ist die Idee von Software Transactional Memory.

Und da gibt es halt dann Techniken, um das effizient hinzukriegen.

Und wenn das alles gut geht, also wenn die verschiedenen Threads sich nicht gegenseitig auf die Füße rumtrampeln, dann führt es halt dazu, dass du wirklich sehr gut skalierenden Python-Code schreiben kannst.

Also skalierend heißt, wenn du 16 Cores hast, dann kannst du halt dann auch 16 mal schnelleren Code schreiben.

Das Problem ist jetzt, was machst du, wenn das nicht so gut klappt mit den Transaktionen?

Und du hast halt einen Thread, der versucht, seine Transaktion zu committen und einen anderen Thread und da gibt es einen Konflikt.

Dann bedeutet das immer, der eine Thread, der wirft die ganze Arbeit, die er gemacht hat, weg und fängt halt nochmal ein bisschen weiter hinten an.

Wer ist denn der eine?

Wer wirft denn weg?

Es gewinnt halt einer von den.

Zufällig.

Nee, nicht so richtig zufällig.

Du musst natürlich schon dann nach außen hin die Python-Semantik dann bewahren.

Das darf quasi nicht beobachtbar sein.

Und da wird es halt dann auch technisch sehr komplizierter, da weiß ich auch nichts zu.

Aber also so von außen ist halt die Idee, es gewinnt einer und die Semantik ist erhalten.

Das Problem ist jetzt nicht, dass sich das merkwürdig verhält.

Das Problem ist halt, wenn du Pech hast, dann ist dein, dann sind alle deine 16 Cores irgendwie busy, aber dein Programm ist nur zweimal so schnell.

Und das ist quasi so ein Performance-Bug.

Und die haben halt einfach, ich glaube letztlich war das Problem, dass sie nicht so richtig die Werkzeuge gefunden haben, um an dieser Stelle dann weiterzukommen.

Du hast halt diesen Performance-Bug, irgendwo gibt es einen Konflikt zwischen den Threads, aber was machst du jetzt als Programmierer?

Wenn du halt Performance-Probleme in Python-Code hast, dann gibt es halt Tools, so Profiler und so.

Und dann kannst du die benutzen, um rauszufinden, wo du vielleicht was optimieren könntest.

Aber für dieses, für dieses, wir haben jetzt zu viele Konflikteprobleme, da gibt es halt keine Tools.

Und da wussten die halt zum Teil dann auch selber nicht, wo jetzt die Zeit bleibt.

Und die sind halt dann, ich habe so ein bisschen das Gefühl, irgendwann ist ihnen so dann die Prüfung ausgegangen, vielleicht.

Also nach sechs, sieben Jahren.

Naja, gut, und es ist ja jetzt auch ganz interessant.

Ich finde es halt interessant, dass es jetzt diesen Prototypen von Facebook gibt, wo halt in gewisser Weise so ein ganz klassischer Ansatz, also das ist halt immer Armin's idee.

Arins Ansatz war ja mit dem Budget-Generator auch schon so, der hat eine Vision, die ist technisch irgendwie elegant und dann versucht er das umzusetzen und bei Budget-Generator hat es geklappt und bei Software Transactional Memory hat es halt leider nicht geklappt.

Und vielleicht, wenn er noch ein paar Jahre weiter gemacht hätte, hätte es auch irgendwann geklappt, aber momentan macht er da halt, da wird er arbeitet halt nicht mehr daran weiter.

Aber jetzt der Facebook-Code, der ist ja quasi in gewisser Weise ganz klassisches Engineering.

Also, die haben halt quasi wirklich ganz klassisch, so wie man halt irgendwie Shared Memory Multiprocessing macht, das implementiert mit einer sehr coolen neuen Einsicht.

Da haben wir vorhin auch schon ganz kurz drüber gesprochen.

Nämlich, also wie gesagt, this is überhaupt nicht mein Gebiet, ich kann mich da nur sehr schlecht aus.

Aber die Idee ist, glaube ich, dieses Biased Locking, oder?

Genau, Biased Reference Counting.

Genau, also die Idee ist quasi, dass ein Objekt meistens in dem Thread benutzt wird, in dem es auch erzeugt wurde.

Und es gibt halt dann so ein Fast Path, solange das Objekt nur in diesem Thread benutzt wird, sind die Zugriffe auf dieses Objekt sehr schnell.

Also da ist die Synchronisierung zwischen den Threads quasi umsonst.

Und erst wenn man das wirklich dann in einen anderen Thread auch benutzen will, wird es halt dann performancemäßig teurer.

Und das ist quasi eine neue Einsicht.

Die kommt jetzt in diesen klassischen Ansatz, Shared Memory Multi-Processing mit Logs und so zu machen, kommt das dazu.

Und es hat sich halt herausgestellt, dass das quasi der richtige ist, um den Overhead für Single-Threaded Code klein zu kriegen.

Es gibt auch so ein paar Tricks, also ein interessanter Trick ist, weil es gibt dann ja durchaus so viele Sachen, die halt schon in allen Threads verwendet werden, also alles, was irgendwie globale Supports und so Zeugs.

None zum Beispiel True, False, sowas.

Genau, und die erklärt man dann einfach zu unsterblichen Objekten sozusagen, macht kein Reference-Counting, weil man sagt, das wird sowieso nie differenziert.

Also was mir zum Beispiel noch nicht so ganz klar ist, man hat ja dann eigentlich oft auch an irgendeiner Stelle doch eine gescherte Datenstruktur.

Also wenn du halt zum Beispiel irgendwie so ein Work-Stealing implementieren willst und du nimmst halt einfach eine Liste, geht das dann noch?

Oder ist halt diese ist dann zu viel Contention auf dieser Liste?

Oder diese Feinheiten, also wie da dann wirklich sich die Performance sich dann in der Praxis wirklich verhält,

was ist ein Work-Sealing.

Ich glaube, das weiß halt keiner.

Sorry?

Was ist ein Work-Stealing?

Also bei Work-Stealing ist halt quasi, du hast irgendwie verschiedene Arbeitspakete und verschiedene Threads, die die abarbeiten, und du koordinierst diese Threads halt über irgendeinen so eine Que.

Und die Frage ist jetzt, welche Datenstruktur benutzt du, um diese Queue zu repräsentieren?

Und Workseating ist Einsatz, dass da hat jeder Thread seinen eigenen Queue, glaube ich, und wenn ein Thread nichts mehr in seiner eigenen Queue hat, dann klaut er was aus den Ques.

Also ich stelle mir das immer so ein bisschen vor, wie so eine Bank, wo irgendwelche Leute am Schalter stehen und warten, bis sie dran können.

Und dann sind bestimmte Schalter halt auf, ein bestimmter Schalter halt nicht.

Und dann kann halt irgendwie sich Leute anstellen an verschiedenen Schaltern und wenn irgendwie eine gerade keine Kunde hat.

Dann geht halt jemand mal so schnell jemand drüber.

Aber ich glaube, also wie da halt so, ich habe da kein gutes Mentales.

Also ich bin wirklich ein sehr single-threaded Mensch.

Ich kann das auch nicht.

Aber ich habe halt mein mentales Modell, das existiert einfach noch nicht.

Ich weiß halt nicht, was passiert mit der Performance, wenn man halt irgendwie 17 Threads hat, die auf 17 Cores laufen und die wollen alle auf eine Liste zugreifen.

Also das ist auch etwas, was irgendwie sehr schlecht ist.

Also immer wenn ich mit sowas zu tun hatte, musste ich feststellen, wenn ich vorher nicht schon auch das Gefühl hatte, ich kann das gar nicht, dass ich es dann, wenn, dachte ich, ich kann es theoretisch und dann praktisch aber feststellen muss, ich kann es nicht, weil es ist, es ist wirklich, und das map halt nicht auf die Art, wie Menschen denken gut.

Und es ist auch ganz interessant, also es gibt ja zwei, mindestens zwei Implementierungen von Python, die halt auch keinen Dill haben, nämlich Jitan.

Jitan ist, soweit ich das sehen kann, relativ tot, aber so in der 2.7 ist ein sehr guter 2-7-Interpreter, der halt Implementierung, der halt keinen Jill hat, der halt wirklich Multithreading kann.

Das ist auch eine ganz, ganz, das war etwas, was ich jetzt bei dem Durchhören da folgenden, eine der Neuigkeiten, die ich da mitgenommen habe, die ich vorher echt gar nicht wusste und mich frage, wie mir das entgegen konnte, aber dass halt, wohl wenn man einen JIT-Compiler hat, das viel besser geht mit dem Fine-Grained Blocking, also sozusagen, dass man gar nicht unbedingt einen Jill braucht, dass es halt mit einem Interpreter, der NC geschrieben ist und der statisch kompiliert ist, geht das gar nicht, richtig.

Aber Java, da das von einem JIT-Compiler verwandelt wird, ist das kein Problem sozusagen.

Und da kann man das dann ohne Jill mit Fine-Graned Locking machen, es wird halt nicht langsam dadurch.

Da gibt es halt, also das ist nicht so leicht, aber der JIT kann halt dann quasi, der JIT macht dann so Reasoning über darüber, ob man gerade von einem Objekt den Log schon hat.

Und dann muss man halt nicht bei jeder Operation versuchen, sich das Log zu holen, sondern macht das nur einmal in der Funktion oder nur an bestimmten Punkten.

Und man macht halt dann nicht bei jedem Field-Read muss man dann irgendwie das Lok holen, sondern kann sagen, wir lesen hier 17 verschiedene Felder und wir holen uns das nur einmal.

Und das kann der Jill halt machen, das kann der Interpreter nicht machen.

Aber ja, also da sind wir noch nicht in Python.

Aber Jython konnte das halt.

Und da hat sich aber interessanterweise halt dann rausgestellt, dass es halt unglaublich viele Bibliotheken gibt in Python, die halt einfach natürlich überhaupt nicht Thread-Safe sind.

Natürlich nicht.

Weil wie soll denn die Bugs gefunden werden, wenn halt die Standardimplementierung halt einfach immer single-threaded ist?

Und selbst in der Standardbibliothek hat halt Jython damals quasi einiges an Bugs gefunden, wo es halt Deadlocks und alles Mögliche gab.

Weil der Code in der Standardbibliothek von C Python halt einfach den Gill präsuponiert.

Und ich denke, das wird halt schon dann auch nochmal für die Community auch einen ganz schön langwierigen Prozess, bis man halt wirklich an den Punkt ist, dass alle Bibliotheken dann auch gehen.

Ich wollte noch eine Sache erwähnen, das kam noch gar nicht vor in unserer Geschichte.

Es gibt tatsächlich noch einen Bereich, wo sehr, sehr viel Aktivität gerade noch stattfindet im so weiteren PiPi-Umfeld.

Und da bin ich auch nicht so ganz direkt beteiligt, aber das ist meiner Ansicht nach auch schon sehr interessant.

Und das ist nämlich genau die Frage nach in C geschriebenen Bibliotheken.

Und das Projekt heißt HPy.

Und das ist ein relativ gut finanziertes, eigenes Open Source-Projekt, was quasi als Idee hat, dass sie eine Next Generation C-API für Python entwickeln.

Und die C-API, die es eben jetzt bisher gibt, die ist halt in gewisser Weise so organisch gewachsen aus C-Python raus.

Weil das ist ja einfach, wenn man die CAPI benutzt, dann greift man einfach direkt auf die Datenstrukturen zu, die C-Python halt einfach zufällig hat.

Und wenn man eine andere Implementierung schreiben will und die ist anders, dann hat man ein Problem, weil dann passt es halt nicht zusammen.

Und HPA ist halt die Idee, wir fangen einfach so einem nicht ganz auf dem Reißfall, aber wir machen einfach nochmal drei Schritte zurück und wir überlegen uns, wie würde denn eine API in C aussehen, wenn man sie jetzt nochmal neu machen würde.

Und da gibt es schon auch dann, also das ist jetzt, das ist quasi noch in der Mache.

Es gibt quasi, es ist irgendwie Version 0,04 raus oder so oder die wollen jetzt irgendwann bald mal zu M1.0 kommen.

Aber da ist halt wirklich die Idee, wie würde man eine API designen, die für alle Implementierungen für Python gleichermaßen funktioniert.

Und die hat ein paar sehr interessante Eigenschaften.

Zum Beispiel, die ist halt absolut ABI-kompatibel.

Du musst vorwärts kompatibel.

Du musst niemals neue Share-Libraries kompilieren.

Du kannst die, die Idee ist, dass man quasi so ein bisschen Windows-mäßig unendlich lange in die Zukunft alle alten Share-Libraries weiterbenutzen kann.

Das ist eines der Design-Ziele.

Ein anderes Design-Ziel ist, dass man den Debugging-Mode anschalten kann für den C-Code, ohne dass man neu kompilieren muss.

Sondern quasi zur Import-Zeit kannst du sagen, hier ist irgendein komischer Crash, mach mal bitte den Debugging-Mode an.

Und dann findet er zum Beispiel ein Reference-Counting-Probleme in der C-Bibliothek, ohne dass man die neu kompilieren muss.

Das ist ein anderes, finde ich, sehr interessante Eigenschaft.

Und also die, das Coole ist, dass Oracle hat auch eine Python-Implementierung, die heißt GralPy.

Und die haben jetzt quasi zwei ihrer Entwickler oder zweieinhalb ihrer Entwickler dafür angestellt, sich eben zu überlegen, wie man dieses HPy-Ding designt.

Und da passiert also quasi so richtig was.

Und ich habe halt die Hoffnung, dass es jetzt irgendwann in diesem 2023 da die ersten Releases gibt.

Und das ist schon auch so, dass es quasi jetzt das Portieren von der existierenden API auf HPI nicht ganz automatisiert werden kann, aber vielleicht so ein bisschen.

Also das ist jetzt auch an allen Stellen, wo man quasi an der alten API dranbleiben kann, haben sie versucht, sich an der existierenden API zu orientieren, um das Portieren eben möglich zu machen.

Und nur an den Stellen, wo das eben nicht ging, ohne die Ziele zu gefährden, haben sie dann eben sich in Team davon abzuweichen.

Naja, also auf jeden Fall, wie gesagt, ich bin da nicht mit involviert.

Ich rede manchmal mit denen.

Einer der GalPi-Tech-Lead ist ein guter Freund von mir, wir telefonieren dann ab und zu.

Aber ich bin halt sehr hoffnungsvoll, dass das bald mal ein Release gibt und vielleicht auch vielleicht in Scythe Supporter eingebaut wird.

Das wäre sehr, sehr cool.

Und das würde eben dazu führen, dass in Zukunft Extensions, die HPI benutzen, halt auch wirklich schnell auf PyPy sind.

Und dann hätten wir unser, also es gibt dann ganz, ganz viele Fliegen, die mit einer Klappe geschlagen würden.

Unter anderem eben möglicherweise, dass es effizient in PiPy ist, dass es effizient in GradPy ist, trotzdem nicht langsamer ist auf C-Python.

Und der Übergang zum vorigen Thema ist jetzt, dass ich gerade auch, soweit ich das verstehen kann, so ein bisschen anfangen darüber nachzudenken, ob man denn da auch die Jill-Änderungen, die nötig würden für die C-Extensions, auch noch mit unterbringen könnte.

Und das wäre halt sehr, sehr cool.

Weil das würde dann direkt funktionieren, ohne dass man da nochmal was ändern müsste.

Ganz genau.

Und dann, wenn dann eine Extension quasi in der Situation kommt, dass sie jetzt ganz viel anpassen müsste, um mit dem Jill zu funktionieren, dann könnte die halt sagen, na gut, dann gehen wir halt vielleicht gleich zu dieser neuen API, nehmen noch einen ganzen Haufen andere Benefits mit und sind aber trotzdem auch kompatibel zu den neuen Jill-Features.

Also das, ich bin mir nicht sicher, ob die das schaffen und ich weiß auch nicht, also bei so Funding durch Firmen, da kann halt auch mal passieren, dass ein Manager sagt, so brauchen wir nicht mehr.

So genau.

Aber das wäre halt cool.

Also das ist ein Projekt, was ich sehr exciting finde und wo ich hoffe, dass da in diesem Jahr halt noch viel passieren wird.

Wir haben leider, also wir haben kein offizielles Buy-In von C-Python.

Also es gibt einige C-Python-Entwickler, die quasi sehr wohlwollend sind, aber wir haben quasi kein offizielles Endorsement.

Sind immer mal ein bisschen am überlegen, ob es ein sinnvolles PEP gibt, also ich habe jetzt wie gesagt, ich bin ich als interessierter Beobachter bin nicht wirklich, also ich schreibe kein Counter für, aber ja.

Also die AP-Leute denken auch immer mal darüber nach, was man für ein PEP schreiben könnte und was da.

Es ist halt gar nicht so ganz klar, was man von C-Python wollen würde.

Weil es ist jetzt, die wollen halt nicht sagen, die wollen nicht die Designverantwortung wieder an C-Python zurückgeben.

Also eines der Vorteile ist eben gerade, dass es ein externes Team ist, was das komplett unabhängig von C-Python macht.

Und deswegen, das soll jetzt nicht irgendwie wieder C-Python untergeordnet werden, so als Projekt.

Aber deswegen ist halt auch gar nicht so klar, was ist das Ergebnis dieses PEPs.

Ist das irgendwie ein reines, also dieses hypothetisch noch nicht geschriebene Pap, ist es ein reines Informations-PEP hier?

Wir arbeiten daran, nehmt uns wahr und also ja, da denken wir halt wissen.

Also es gibt den Wukash Langer, der auch von Vollzeit an über die PSF an TWAS arbeitet.

Der war auch bei dem HP Sprint im September hier in Düsseldorf.

Also der ist auch ein Core Dev, der informiert und involviert und wohlwollend ist.

Aber so von den Hardcore-Performance-Leuten gibt es jetzt quasi keine offizielle Aussage, dass sie das irgendwie toll finden wollen.

Aber ja, also.

Na genau.

Aber ich hoffe halt, dass da jetzt in diesem Jahr halt noch ein paar interessante Sachen passieren.

Oh, interessant, ja.

Ja, ich meine, gerade mir sagt das gar nicht so viel.

Ich weiß nicht, ob ich, ich glaube, ich habe es nicht mal gehört, dass es da noch einen Interpreter für Python gibt.

So viele sind ja auch nicht mehr übrig.

Joton, Iron Python ist alles nicht mehr so nicht mehr so richtig da.

An Laden Swallow gab es auch besonders.

Ah, das ist lange tot.

Ja, äh, PiPi ist so eine der ganz wenigen, die überleben kriegt.

Ja, genau.

Also CalPy halt auch.

Also Cradfy hat halt wirklich ein Team, die sind auch bezahlt und die haben da von der Funding-Situation sind die ziemlich gut.

Die haben so ein paar, deren JIT ist auch ziemlich gut, die können wirklich schnell einen Python-Code ausführen.

Die haben so ein bisschen das Problem, dass es nur, also dass ihre Warm-up-Zeit sehr lange dauert.

Also der Code wird halt erst nach vielen Minuten schnell.

Und das heißt, du brauchst halt die richtige Art von Anwendung.

Also so Longrunning Server Processes funktionieren super.

Aber wenn du alle fünf Minuten deployst, dann halt nicht mehr.

Aber da kommen die auch noch hin.

Also die haben halt Geld.

Das im Moment.

Das ist halt für eine Implementierung eine sehr angenehme Situation.

Und der Tim weiß auch, was er tut.

Er ist sehr, sehr gut.

Also Tim Felgengraff heißt der Tech-Lied.

Und die sind, glaube ich, auch 31 kompatibel und supporten C-Extensions und also das ist schon eine sehr ernstzunehmende Implementierung.

Ja, cool.

Warum schreibt man sich sowas dann direkt in Rust E, statt in C

neu zu schreiben?

Die schreiben das in Java neu.

Also gerade, wir wollen da, ich glaube, da steigen wir jetzt nicht ein, aber gerade ist so ein bisschen die Piper-Idee nochmal in mit Geld.

Also halt von Oracle, deswegen haben die, die haben einen R-Java, also die können quasi ihren Java-Code nach C übersetzen und haben den JIT-Compiler in C geschrieben und die haben auch diesen selben, technisch funktioniert das ein bisschen anders, aber die haben ja auch so eine ähnliche Motivation, die haben so einen Meta-JIT-Ansatz, dass sie quasi kein JIT schreiben, sondern den JIT auch generieren aus einem Interpreter mit einer anderen Technik, aber halt so von der Motivation her ist das recht ähnlich.

Und die benutzen das halt, also die haben halt irgendwie einen schnellen JavaScript-Implementierung und ein schnelles Python und natürlich irgendwie auch ein schnelles Java und ja, und das ist ein riesen Team, das muss man halt auch.

Also die haben halt eine zweistellige Anzahl an Leuten, die halt an diesem Zeug arbeiten.

Und ist in gewisser Weise auch irgendwie sehr forschungslastig, das Projekt.

Das ist auch eine große, also ich würde sagen, es ist von Oracle eine große Wette.

Also mir ist nicht so, also ich glaube, im Moment verdient das Team halt kein Geld.

Also das ist halt die Hoffnung, dass es irgendwann mal dann vielleicht doch Geld verdient, aber ich glaube, im Moment ist das halt wirklich eine Wette.

Und auch, die läuft auch schon lang.

Also das Projekt ist irgendwie zehn Jahre alt oder so.

Also so irgendwie 30 Leute über zehn Jahre anzustellen, das ist halt, das ist halt richtig teuer.

Naja, aber also da weiß ich, also was da die Motivationen von so einer Firma sind, das weiß man halt immer nicht.

Kann man halt dann munter spekulieren.

Das mache ich natürlich auch immer gern, aber ja, also ja.

Also das ist quasi so ein bisschen friendly competition, aber also mit Betonung auf friendly.

Aber nochmal die Frage, warum sowas nicht in Rust irgendwie geschrieben wird, jetzt so ein neuer Link?

Mir ist noch nicht so ganz klar, also es ist so ein bisschen so eine grundsätzliche Frage, in welcher Sprache implementiert man seinen Jit?

Und die klassische Antwort ist halt C oder C<unk>.

Und es gibt jetzt verschiedene so forschungsaffine Projekte, wie Squeak, ganz klassischerweise, oder eben PyPy oder GralPy, die halt sagen, es ist doch eigentlich viel cooler, wenn man eine Sprache, eine Implementierungssprache nimmt, die halt irgendwie ein höheres Abstraktionslevel hat als C.

Weil C ist halt doof und nicht Memory-Safe und stürzt die ganze Zeit ab und man kann auch nicht schön abstrahieren und deswegen ist C halt keine schöne Sprache.

Und genau, das sind dann die genannten Projekte.

Und jetzt ist so ein bisschen die Frage, ob Rust eine gut geeignete Sprache ist, um JIT-Compiler zu schreiben.

Und ich glaube, das weiß einfach noch keiner.

Also es gibt genau ein großes JIT-Projekt, was Rust benutzt.

Das ist, habt ihr auch, glaube ich, in einer Folge darüber geredet, das ist dieses der neue JIT für Ruby, der von Shopify finanziert ist.

Es gibt übrigens auch ein großes Gral Ruby-Projekt, also das heißt Truffle Ruby, das auch von Shopify zum Teil finanziert wird.

Also die leisten sich mehrere eigene Ruby-Information.

Und das eben, heißt es YJIT?

Ja, ich

bin der ist eben in Rust geschrieben und ich glaube, die Jury ist halt noch so ein bisschen out, ob das wirklich die richtige Sprache für den JIT ist.

Und mit der, also die Maxim Chevalier Vois, die das gestartet hat, Wiget bei Shopify, mit der zoome ich auch auf und zu.

Die ist auch extrem gut.

Aber was da, also was da ihre Conclusion wäre, ist Rust die richtige Sprache, um so einen JIT-Compiler zu schreiben, das weiß ich jetzt.

Also das weiß ich noch nicht.

Ich glaube, das weiß halt, das weiß man dann, das kann man erst so ein bisschen abschließen, beurteilen nach dem dritten JIT vielleicht.

Oder ja, also das.

Also wenn man halt dann Rust nimmt, dann muss man sich halt klar machen, dass man sich da auf noch nicht ganz verstandenes Terrain bewegt.

Also ich meine, C<unk> ist halt so die akzeptierteste Sprache, um virtuelle Maschinen zu schreiben.

Und das muss man jetzt nicht gut finden.

Also ich persönlich finde es halt vielleicht nicht so gut.

Aber das ist halt die Sprache, ich meine, das ist auch die Sprache, in der man halt in der Regel einen Compiler schreibt.

Und wenn man irgendwas anderes nimmt, dann muss man sich halt klar machen, dass man, dann ist man plötzlich für sich selbst verantwortlich.

Also da muss man mit seinen eigenen Konsequenzen leben.

Also ja, ich weiß es nicht.

Ich habe keine, ich ist halt so ein bisschen die Frage, an welcher Stelle, an welcher Stelle würde die extra Safety von Rust, wäre die gewinnbringend im Compiler.

Weil das, was halt an einem so einem Divid Compiler dangerous und scary ist, ist halt nicht, dass der selber in einer Unsafe-Sprache geschrieben ist.

Das ist natürlich auch ein Problem.

Das ist nicht das primäre Problem.

Das primäre Problem ist, dass man selber Maschinencode erzeugt.

Und der darf halt nicht falsch sein.

Der darf halt nicht falsch sein.

Aber bei diesem Problem nützt, bringt einmal Rust auch nichts.

Ja, weil Rust dann ist der Compiler, dann ist der Ding, in dem man den JIT-Compiler schreibt, ist dann halt, das geht halt nicht kaputt.

Genau, die beim Interpretieren deines Interpreters ja irgendwas anderem geschrieben ist, aber wenn der falschen Code erzeugt, dann ist er immer noch schlecht.

Das ist halt gewisserweise ein Logik-Bug und kein Memory Safety-Bug.

Ja.

Testen.

Genau.

Es gibt, also irgendwann werde ich den Teil 2-Blogpost zu How is Panfi-Testet schreiben.

Der ist auch deutlich länger.

How is the Jit Tested?

Das ist nämlich wirklich auch nochmal so ein bisschen so ein richtig eigenes Forschungsfeld.

Und ich lerne da auch immer mal wieder was dazu.

Also gerade so im LFVM-Bereich, da wird ja auch dann unglaublich viel Fuzzing gemacht und da werden auf interessante Art und Weise Theorienbeweise eingesetzt.

Und da gibt es halt wirklich dann Forschungsgruppen, die nichts anderes machen, als sich darüber Gedanken zu machen, wie man so einen Compiler testet.

Und im Herbst habe ich halt dann wirklich so eine neue Technik dann mal ausprobiert, wie man mit so einem Theorienbeweiser halt Bugs findet.

Und ja, da haben wir halt auch dann drei Jitbugs gefunden.

Also das war echt ganz interessant.

Und da gibt es halt so einen Prof in Utah, John Drigger heißt er, der schreibt da Paper drüber.

Und nachdem ich genügend Paper von dem gelesen und mit ihm lang genug auf Twitter geschrieben hatte, habe ich dann halt mal das auch selber ausprobiert und das hat halt wirklich dann Bugs gefunden.

Cool.

Interessant.

Jo.

Pi Pi.

Ja, sorry.

Das texte euch zu.

Nee, das ist voll, das ist, genau, deswegen sind wir ja da.

Können wir jetzt bitte endlich schlafen gehen.

Nein, so stimmt es noch.

Naja, reden ist halt auch Teil meines Jobs.

Ja, ja, nee.

Also ich finde das total interessant.

Ja, ich überlege nur gerade, ob wir noch irgendwo ein großes Thema vergessen haben, aber ich glaube nicht.

Ich glaube, wir haben tatsächlich das meiste so durch.