Ja, hallo liebe Hörerinnen und Hörer, willkommen bei einem Python-Podcast, Episode 48, heute geht es um PyPy.
Hallo Jochen.
Ja, hallo Dominik.
Hallo Karl.
Herzlich Willkommen.
Hallo Karl.
Ja, wir wollen wie immer erstmal News machen. Was hast du denn da, Jochen?
Oh, oh, oh, jetzt muss ich mal, wir müssen hochscrollen.
Ja, also es gab jetzt ein 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.
Das war so 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.
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 einem das halt Ärger machen kann. Also mein
Beispiel war, ich hatte ja mal gefragt, ob jemand ein anderes
Beispiel hatte, 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? Ne, 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,
das halt quasi
3,15.
Ja, ich weiß jetzt gar nicht mehr,
in welcher Relation es war, so 13, 14, 15,
dann irgendwann umzusteigen
auf per Default ist der
Global Interpreter locker aus und dann
irgendwann es zu deprecaten
und dann bis irgendwann 2030 oder so wegfallen
zu lassen, aber das ist dann halt sehr weit in der Zukunft.
Kleine Ahnung.
Und der Plan ist aber erstmal, das quasi hinter einer
Interpreter
Compile-Time-Flag zu verstecken.
Ja, okay, alles klar.
Jetzt haben wir ja direkt am Anfang so was Schwieriges
gemacht. Können wir vielleicht
nochmal ganz kurz erklären, was nochmal ein
Gehör ist?
Ja, soll ich?
Ja, 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,
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ühren kann.
Und dazu, das hat halt die Auswirkung,
es war lange kein Problem,
weil halt keiner irgendwie ein Multi-Prozessor-System hatte.
Aber jetzt, wo es halt Multi-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 Multi-Thread-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 den 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.
Ja, weil es gab ja schon mal von Larry Hastings oder so, das ist jetzt auch fast zehn Jahre her oder so, dass er hatte dieses Gilectomy-Projekt, wo er 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 der Gill das halt schneller macht, als wenn man es halt einzeln locken würde.
Und ja, das war halt immer so, die erste naive Implementation war irgendwie so 40 Mal langsamer als mit Git 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 verwenden kann.
Und jetzt die aktuelle Geschichte hat angeblich irgendwie so, wie es dann implementiert werden soll in dem PEP, 10% Kosten in Single-Thread-Performance, was ja so, und es gibt halt schon ein Ding, das kann man auch über PyInf 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 auch noch ein paar Sachen da drin,
die jetzt in dem aktuellen Pep nicht drin sind.
Daher wäre das ein bisschen
langsamer. Aber ja, also
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
der Garbage Collector zwar nur innerhalb der
von einem Thread erzeugten Sachen aufräumt,
oder Reference-Counting macht und dann muss man
das 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, das ist gar nicht mehr genau,
das sind insgesamt drei Pointer, die jedes Objekt mehr
kriegt, drei 64-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, so
Es sind halt nur Trade-Offs.
Wenn man es gebrauchen kann, ist es vielleicht gut, aber
wenn man es halt irgendwie nicht braucht,
dann kann es auch sehr nervig sein.
Ja, und deswegen
und die C,
dieses Application
Binary Interface
ist halt auch nicht mehr kompatibel,
sodass halt man im Grunde
halt die C-Extensions,
also für jedes
Paket, das halt eine
C-Extension ist,
muss man halt die entsprechend richtige
Version installieren für den Infrared-Richter, 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.
Ja, ja.
Also wenn man, okay, also das wird dann tatsächlich ein
Breaking-Change sein, dann, wenn die C-Extensions
dann nicht mehr gehen.
Das ist dann eigentlich Python 4?
Nee, also sag mal so, du kannst es ja parallel
verwenden, also wenn du das nicht benutzen willst.
Wenn der Default sich ändert.
Ja, aber das ist dann irgendwann, das ist in der weiten
Zukunft, also das ist halt noch Jahre heran.
Ja, aber wenn das Python 3.5 ist, dann ist es 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. Aber, ja.
Ich glaube, wir müssen 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
da bei Facebook noch mal mit dabei? War das Sam Gross?
Sam Gross, genau.
Du hattest vielleicht den Vortrag auf der Eurofight
letztes Jahr gesehen. Ja, ja.
Ich habe nicht so viel verstanden, aber ich habe ihn mir angeguckt.
Okay, ja.
Ja, ja, ist auch ein schwieriges Thema, glaube ich.
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 darin stecken, in einen Pointer
reingefriemelt irgendwie,
reinkodiert und das war den Leuten
aber dann jetzt zu heiß und dann haben sie gesagt,
nee, wir nehmen lieber drei, das ist zu gefährlich,
was können da alles für Overflows passieren?
Und also daran sieht man
schon, dass es halt, dass sie sich das nicht getraut haben,
das einfach so zu übernehmen, es ist kompliziert.
Würdest du das Paper bitte auch verlinken?
Das klingt eigentlich spannend. Ja, kann ich machen.
Mach auch den Talk von
der Europython rein, wenn es den irgendwo schon gibt.
Ich füge das mal hinzu.
Alles klar.
Er hat das nämlich genau erklärt, wie er das so vorhat.
Und das war schon...
Er hat einige clevere Ideen dabei gehabt, fand ich.
Auch ein spannender Typ, ja.
Ja.
Okay.
Habt ihr noch nichts? Du hast gesagt Packaging.
Ja, Packaging.
Das war ein anderes großes Thema.
Auch vor zwei Wochen oder so gestartet.
Oder noch ein bisschen länger.
Und das kann ich halt immer noch so versichern.
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 DiscussPython.org.
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 darü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ß, was man denn jetzt
nehmen soll für welche Tools und
wie man die dann jetzt am besten, wie rum man die hält
und dann wird es nicht irgendwie
keine furchtbaren Sachen passieren und
ja, das ist ein Problem und
aber es gibt auch keine so richtig einfache
Lösung
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 eigenes 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 es ist auch erst wenige Wochen alt, von
Nathaniel Smith, ein
neuer Paketsprachler, Posey heißt er,
oder Posey, ich weiß nicht genau, wie man das ausspricht,
der ist das eine, ein Rust-Binary,
die quasi das ganze Zeugs von
Python übernehmen soll, also den Interpreter mit ausliefern
und Pakete bauen und
Dependencies bauen und
deren Grafen bauen und so. Und das
sah, fand ich, relativ interessant aus, weil genau
das auch eines der Pages ist, die allen Leuten, mit denen ich
irgendwas mit Paisen machen will, erstmal
erklären muss, hä, wie geht denn das? Oh, das ist aber kompliziert und warum
ist das denn so? Und ja,
sobald dann halt, also wenn die einen Paisen machen, okay, aber wenn die
nochmal eine andere Paisenversion, irgendwann habe ich es ja später so,
geht alles kaputt und Fahrt anpassen und dies, 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. Ja.
Ja, ja, 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 einen sehr
tollen Artikel geschrieben, irgendwie
für Structured Concurrency,
den verlinke ich auch mal gerne
oder sage Leuten, dass sie sich das mal durchlesen sollen.
Ja, insofern,
ja genau, das habe ich auch da direkt aufhorchen
lassen, als ich gehört habe, 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 von Rust machen.
Ich weiß nicht genau, wo man das unbedingt, also alle Leute
machen und haben 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, aber immerhin hast du eine vorkompilierte Binary,
die du irgendwie ausliefern kannst. Und in Rust ist das
vielleicht so ein Typensicher und irgendwie ordentlich
schnell. Und ich glaube, man kann
die halt auch relativ leicht dann so statisch
verlinken und hat halt wirklich 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
das Poetry hat mit dem
curl und get Poetry
schrecklich Schell-Skript irgendwie von
einer Webseite ausführen. Ja. Ja.
Ja, okay. Gut, das löst es. Das stimmt.
Ja. Das sind so ein paar Sachen,
die glaube ich gar nicht schlecht sind. Also ja, aber Rastor ist cool.
Ich habe es auch mal ein bisschen ausprobiert in Advent of Cody.
Aber
die Weihnachtszeit ist ja jetzt schon wieder vorbei.
Ich weiß nicht, was ich finde.
Also 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. Pip-Tools fand ich
ja fürchterlich, aber du findest Poetry fürchterlich.
Ich habe Poetry lange verwendet.
Also fürchterlich ist...
Ja, wir hatten uns ja, glaube ich, das war schon ein, zwei
Folgen her, über dieses
Problem mit den Dependencies irgendwie schon
auseinandergesetzt noch.
Warum das vielleicht
blöd ist, aber ich sage mal so, theoretisch kann man
die ja trotzdem einfach dann selber
einstellen in der PyProject-Hummel.
Ja, ja, das
Problem ist, dass Poetry
implizit halt,
wenn man sagt Poetry add irgendein Paket,
irgendwie ein
Upper Bound auf die
Version macht, was
Wenn man eine Library schreibt, wo andere halt sehr blöd
ist, weil die dann sofort in Dependency-Problemen
laufen, Konflikte laufen.
Man muss ja manuell quasi tatsächlich dann
die Funktion wegnennen.
Naja, gut.
Das ist, glaube ich, eine gute Idee.
Ich habe letztens gesehen, PipTools
in PyProject Hummel irgendwie rein
gemeldet.
Letzte Woche war
PyGDF-Treffen und
Jens hat mir das mal
erzählt, dass er das jetzt macht.
Er benutzt PipTools. Ist auch nicht so super
nicht hundertprozentig zufrieden, aber
irgendwie
benutzt man das auch häufiger
und hat einen Weg gefunden, wie man das
relativ einfach, die Abhängigkeiten auch in
der PyProject-Tunnel da reinschreiben
kann und hat mir mal gezeigt, wie man das macht.
Das könnte ich auch verlinken, stimmt.
Ist natürlich auch nicht so schlecht.
Weil dann hat man alles wieder, weil das ist natürlich
im Moment ist das ganze Packaging und
Dependency-Management-Zeugs irgendwie relativ
furchtbar. Das funktioniert
auch nicht US-übergreifend gut und
das ist
ziemlich ein Mist. Ich hoffe ja wirklich, dass dieses
RAS-Paket da einiges
ändert, weil das
will man so alles nicht haben.
Ja.
Wird uns noch eine Zeit lang begleiten, das sehen wir, glaube ich.
Ja.
Okay.
Kommen wir zu erfreulicheren Dingen.
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.
Genau, wobei das nicht so eine
große Rolle spielt. Die offizielle Empfehlung an der Stelle ist
immer, 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 den LTS-Version zu bleiben.
Dafür verändert 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, PsychoPG3
Support, das heißt Async
Datenbank-Unterstützung
kommt damit halt so, rückt näher.
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
zurückkommen, dass es einfach so,
dass man einfach so davon profitiert und dass man selber
nochmal was ändern muss. Das muss ich auch mal irgendwann
verstehen, wie das mit der Datenbank funktionieren soll?
Naja, du kannst, also im Grunde
der OEM weiß ja, was er an Queries an die Datenbank
schickt und der schickt dann, 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 Queries 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 an die Datenbank schicken
und dann hat man
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.
Aber es ist natürlich eine sehr komplizierte Änderung.
Aber da muss die Datenbank ja natürlich schon parallel auch rechnen können.
Ja, das können die. Das können die alle.
Und wie stellt die Datenbank
sicher, dass sich jetzt keine
Probleme
hab, festzustellen, dass Dinge auf die
gleichen Stellen zugreifen.
Das ist ja so
die Kernkompetenz eines Datenbankmanagements
Systems sozusagen.
Wie soll das denn gehen?
Das Problem hast du jetzt ja auch schon, wenn du mehrere Frontends hast
oder mehrere Prozesse auf deinem Frontend, die gleichzeitig
alle irgendwie...
Man muss ja gucken, dass sie einen Lock setzt dann irgendwie und dann muss sie
gucken, ist das Lock auch da oder muss halt
eins setzen, wenn sie da irgendwie dran rumfuchtelt und dann
muss sie es wieder... Du meinst jetzt so Richtung
Right zu Griff oder was? Ja. Ja, aber ich meine,
dann schaust du halt eine Transaktion und
siehst, dass dann, hast du eine
konsistente Sicht der Dinge
innerhalb der Transaktion oder die wird halt
dann committed oder aborted und das
ist, also ich glaube, ich stimme
dir zu, dass, Jochen, 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?
Ja, natürlich macht das alles, das macht alles viel langsamer,
wenn man Transaktionen ausschaltet und F-Sync
ausschaltet, dann wird das, wird 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 Schritt auf den Haken.
Also, aber 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 Rechner-Ebene, die da auf die gleiche Datenbank zugreifen.
Also das sollte eine Datenbank schon können?
Ja, gut, man hat nochmal ein bisschen Probleme, weil zum Beispiel Postgres kann halt nur, oder es kommt darauf an, welches Protokoll man verwendet, aber das Textprotokoll von Postgres kann halt nur eine Querie gleichzeitig beantworten.
Das heißt, bisher war das kein Problem,
weil man kann sowieso immer nur
im Code 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 halt intern poolen
oder muss irgendwie
außen poolen.
Es ist sowieso alles sehr kompliziert. Auch die ganze
Geschichte im OEM, was man dann umstellen muss,
das wird noch lange dauern, bis das alles
richtig funktioniert. Aber wenn es denn mal
irgendwann funktioniert, das ist ja cool.
Und das ist jetzt ein Schritt,
weiterer Schritt dahin. Also wir haben jetzt Async-URM,
Async-Views, Async-Tests.
Ja, ja, Async-URM 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 du nimmst, ist Async-URM.
Genau, das
ist halt auch noch das komplizierteste
Stück Arbeit, was noch da bevorsteht.
Genau.
Dann, es 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 wir haben irgendwie den Weg gefunden, wie sie das so
hinkriegen, dass es kein Problem mehr ist.
Und das, was ganz nett ist,
dann
früher, oder ab dann wird man halt
eventuell, es gibt so
Django in Memory Storage, ich weiß
nicht genau, gibt es ein externes
Paket nicht mehr brauchen, das ist dann auch in Django
selber drin. Das heißt, man hat jetzt einen
in Memory-Storage-Backend
für Django mit dabei,
dass 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-Iteraturen
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 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
surfen 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 Async-Iterator. Das heißt,
es müsste eigentlich Files surfen, müsste jetzt einfach so gehen.
Ja, das ist natürlich auch sehr cool. Wir haben noch ein paar Konferenzen von zweien. 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 uns auf?
Ja, okay. Tja. Und PyCon.de oder PyData ist in Berlin 17. bis 19. April, da gehe ich wahrscheinlich auch hin.
Euro-Pricen ist vom 17. bis zum 23. Juli.
Okay, ein bisschen später.
Aber ich weiß nicht wo.
Okay.
Das ist noch 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.
Ja.
Ich glaube gerade das Management-Team hat da gewechselt.
Ja.
Ja, also die letzte
hat noch Marc-André mit organisiert
und jetzt machen das irgendwie andere Menschen.
Die haben so eine
neue Art und Weise wollen die machen mit
wer das wie veranstaltet und sich was neues Konzept
da überlegt. Mal gucken, ich bin gespannt.
Jojo.
Okay, ja, nee, dann
das wäre ja nach nur fast
20 Minuten mit den News durch,
das ist mal relativ flott, dann
kommen wir zum Hauptthema.
Eine ganz schnelle Folge. Das glaube ich nicht.
Pai Pai? Ja.
Warum macht man 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, ich gebe jetzt schon die ganze Zeit so meinen Senf dazu.
Aber ja, also ich bin Karl Friedrich Bolz-Tereik.
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 halten jedes Semester für Leute,
die nicht Informatik studieren.
Also das ist so Studium Universale mäßig.
Und wenn ich die 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 PiPi-Projekts,
über das wir jetzt auch dann gleich noch mehr reden wollen.
Also ich habe da halt irgendwie am Anfang von 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 dran beteiligt.
Also an dem Open-Source-Funded-Ding,
was dann PiPi direkt entwickelt.
Genau.
Also ich bin jetzt quasi einfach erst mal 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 viel, recht viel machen.
Genau, aber
das Projekt hatte über seine Lebenszeit
halt immer wieder auch Phasen, wo das wirklich
auch viel Geld hatte.
Also 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 musst du auch mal direkt erzählen, was PyPy überhaupt ist.
Ja, genau. Das ist 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
oder vielleicht kriegt man das auch irgendwann das 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 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 Terminologie-Trick,
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 CPython 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
PYC-Dateien irgendwo
auf der Festplatte auch noch so ein bisschen
zwischengespeichert, damit man das nicht jedes Mal machen muss.
Aber dieser White-Code, der wird halt
dann jedes Mal von einem Interpreter ausgeführt.
Und
was
Piper 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ädt, 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 P-Y-P-Y. Das ist so ein bisschen doof, dass die so ähnlich sind.
Ja, weil man von PyPI ja auch viel runterlädt.
Genau, ja, ja, absolut. Aber PyPI lädt man quasi in Python geschriebene Bibliotheken runter, die dann auf der Python-Implementierung laufen, aber PyPi ist eben wirklich das Binary, also die Exit-Datei sozusagen.
Du hast nicht mehr 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-Branding, 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.
Genau, da geht halt der Kunde dann so ganz viel 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.
Ja, okay, verstehe.
Und deswegen gibt es Reels 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 Draftname für unseren Podcast war
Ministry of Silly Talk. Ah ja, alles klar, nicht schlecht.
Und also
irgendwann wurde halt Pipe.pi dann ein bisschen
ernsthafter und hat halt angefangen, dann
sich nicht mehr das Cheese Shop zu nennen.
Und dann wurde halt die Verwechslungsgefahr plötzlich
dann auch akuter. Aber weil halt
PyPI und PyPi ziemlich
genau gleich alt sind, also PyPI ist ein kleines
bisschen älter, so ein paar Monate oder so,
haben halt beide Projekte
nicht so richtig eingesehen, sich jetzt umzubenennen.
Und deswegen müssen wir
jetzt halt mit dieser
Verwirrung leben. Genau, also wir waren
an dem Punkt, man kann von PyPi.org sich
ein Binary unterladen, das heißt PyPi.exe
oder halt einfach nur PyPi.
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 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
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
C-Python 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, naja, wir sind aber viel konsistenter
und das macht ja so viel mehr Sinn, nee.
Das ist halt doof. Für so eine Bibliothek ist das 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 Fehlermeldung in irgendeinem Fall oder so.
So was kommt halt schon vor.
Aber so, also 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 PyPy 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 CPython 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, jetzt sage ich mal,
irgendwie technische Verbesserungen
an der Implementierung gemacht werden.
Das kommt natürlich auch mal vor.
Also jetzt sind 3F zum Beispiel ganz toll.
Aber insbesondere gibt es halt auch bei jeder Version
irgendwelche neuen Sprachfeatures.
Das heißt, python.org, diese Community,
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 PEP nehmen wir an, welches neue
Language-Feature wollen wir haben, welche neue
Standard-Bibliothek,
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 offizielle Release und dann
das darf ein CPython und baut das dann eure
Änderung ein. Ganz genau. Und es ist schon
dann mal so, dass wir bei den CPython-
Diskussionen dann auch mitreden und sagen, ja, aus unserer
Sicht hat das die und die,
also gibt es jetzt hier diese Trade-offs oder so,
aber wir versuchen uns halt
so erstmal aus Sprach
Design-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 Featuren 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 Pai-Pai-Hut aufhabe,
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
Dein-Python-Programmierer, hast du selber gesagt.
Ja, über die Architektur reden wir gleich noch.
Also irgendwie dann schon,
aber halt auf ein bisschen indirekte Art und Weise.
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
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 drauf eingestellt
dass sie 3.10 supporten und wenn
wir dann auch mit unseren 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
wir machen alle paar Monate Release, aber das heißt nicht
unbedingt, dass dann auch die neue C-Python
Version
supported wird
und gerade sind wir so ein bisschen hinterher
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.11, also das ist ein quasi
ein Nachteil, warum man Piper 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.
Und 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 Piper 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 geschriebener Erweiterung
halt quasi, die funktionieren,
die können aber halt oft
einfach langsamer sein.
Und das ist natürlich doof, weil
Ein Massenpaket, das schneller sein will,
aber die Sachen sind langsamer, als wenn du die eigentlich auf normalem
Python-Offenheitsmittel hast. Genau, ja, ja. Also ich meine,
der Grund, warum man, es gibt ja so ein bisschen
zwei Motivationen, warum man in C geschrieben die 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, wenn man irgendwas schneller machen will,
indem man es in C schreibt. Und diese
Motivation, die funktioniert halt dann
auf PyPy oft nicht. Und das
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 NC-geschriebenen Optimierungen
gemacht haben, ist das dann für uns
oft auch halt eine Verschlechterung.
Also, ja.
Könnte man da nicht vielleicht einfach auch
den C aus PyPy heraus
irgendwie einfach den C-Python-Interpreter
wieder aufrufen und den 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. Ja, 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?
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
Bibliotheksseite.
Die andere Fußnote ist, dass es manchmal nicht
klappt. Also es gibt halt,
manchmal hat man wirklich in Python geschrieben
Code und
der wird nicht schneller.
Also man muss halt einfach
messen. 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
in C geschrieben ist und das
ist alles jetzt, sag ich mal, sehr numerisch. Also 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 CPython kriegen. Also das ist halt, das ist
schon, also alle Leute, die halt so was
wie Advent of Code machen, ja,
Advent of Code ist eigentlich so,
ich scherze, aber ist irgendwie auch was
Wahres dran. Advent of Code ist halt irgendwie einer der
Haupt-coolen Use Cases
für PyPy. 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 PyPy einfach
mega gut dafür.
Genau, und weil, also 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 Speed-Up 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 da irgendwie ein Referenzsystem
oder macht ihr das einfach immer so objektiv von dem über den Rechner?
Du meinst jetzt quasi,
inwiefern das von der darunterliegenden Hardware abhängt?
Ja, zum Beispiel, ja.
Das ist, glaube ich, nicht so ein Problem.
Wir unterstützen so einen Haufen CPU-Architekturen,
aber 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 Abschätzung, also im besten Fall
so 30-40x, ich antworte gleich
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 Zweifelns, ich
verbringe seit 18 Jahren
ein Teil meiner
Freizeit und irgendwie
ein Teil meines Berufs damit, an diesem Projekt zu basteln
und
so richtig,
also, was weiß ich,
99% von allen Deployments sind halt
dem C-Python. 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 gerne dran rum, aber
es ist natürlich auch schön, dann so ein bisschen so
quasi externe Motivationen 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,
so Rück,
politische Rückauswirkungen auf
C-Python haben. Und das ist quasi
meiner Ansicht nach auch so ein bisschen so
ein, so ein, der 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,
Also 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, das war 3.10?
Ja, 3.10 und 3.11.
Ja, da bleibt das Verbesserung.
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 Batoan Toskaya und sowas,
was die da an Aufwand reingesteckt haben,
unglaublich nervig
und auch wirklich
sehr, sehr cool. Ich bin sehr zufrieden
mit einer Verbesserung. Wie gesagt, ich unterrichte Anfänger.
Ich kriege das quasi immer mit, wenn das
halt mal schief geht mit den Fehlermeldungen.
Aber so ein bisschen
so der ursprüngliche Drive
kam halt so ein bisschen von Piper. Also zum Beispiel dieses
mit den nicht gematchten
Klammern. Das ist ja so einer der neuen Fehlermeldungen,
dass es halt steht, die öffnende
Klammer, die öffnende Ecke Klammer auf
Zeile 5 wird mit einer runden schließenden Klammer
auf Zeile 9 geschlossen. Da stimmt
das nicht. Das war halt
einfach, das habe ich einfach vor ein paar Jahren mal
implementiert. Und irgendwann hat es halt
in Zepa hätten 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
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's
halt immer noch ein paar, wo ich
mit unseren dann zufrieden bin. Zum Beispiel
so ein absoluter Standard
Anfängerfehler, 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
versucht man, die Methode aufzurufen.
Erstes 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 hab ja doch
drei Argumente, warum beschwerst du dich denn,
dass ich da nur zwei reinreiche?
Oder, ja, so,
das stimmt ja dann immer nicht.
Und da
mache ich in PyPy einfach nur,
wenn es quasi einen
off-by-one-error bei einem Methodenaufruf
gibt, genau in diese Richtung,
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 wäre 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
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, also das
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 und
aber ich, also ich bin
halt, ich habe so ein bisschen
wie gesagt, ich will keinen
Credit klauen, 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 in den Zielpreisen ein, da bin ich
einfach mega glücklich drüber.
Das ist der Forscherdrang, der so ein bisschen auch
in die richtige Richtung geht. Der was?
Der Forscherdrang. Ja,
keine Ahnung, das ist jetzt nicht mein
Forschungsgebiet. 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-Fehlermeldung,
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,
die, 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.
Ein Teil ist runter oder sowas auch noch gezeigt.
Genau, ganz genau.
Und das haben sie jetzt gefixt, das heißt jetzt 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.
Und das ist jetzt wirklich schöner und das ist
Zum Beispiel in Triple Quoted String sagt er dir jetzt auch
die Fehlermeldung,
wo, ähm, wo dir,
also, da war die Fehlermeldung halt
immer in der allerletzten Zeile der Datei.
Weil er sucht
ja einfach immer weiter.
Bei 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.
Und jetzt, das ist jetzt wirklich,
das wurde in 3.10 gefixt,
ist es jetzt halt so, dass er dir wirklich dann die Zeile zeigt,
wo die öffnenden Triple Quotes 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, 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 einen Screenshot gefakt,
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
Pablo
gesehen und dann super
aufwendig. Es ist ein wirklich sehr
nerviges Feature. Ja, das glaube ich.
Ich habe mich schon gefragt, wie
das implementiert wurde, weil das
ist ja 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 Informationen gar nicht. Am Anfang hatte der Syntaxbaum 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 kam gar nicht vor.
Also nochmal für alle, die das noch nicht kennen, es gibt halt Fehlermeldungen, da wird ja jetzt die Position, wo der Fehler passiert ist, mit so Dreiecken unter Kringelt quasi unterstrichen, wo das halt aufgetroffen sein könnte.
Und da hatte ich halt diesen Tweet gefakt 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 dann 3.11 unterstützen, dann muss ich das ja auch implementieren.
Also insofern habe ich jetzt mich da ein Stück weit auch selber mit reingelegt,
aber dass es jetzt halt in C-Python 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 Ordered Dictionaries.
Ach, okay. Also das ist ja
in 3.6, glaube ich.
Informell, das weiß ich nicht.
Aber 3.7 wird dann auch tatsächlich garantiert.
In 3.6 haben sie halt gesagt, ihr dürft euch nicht
darauf 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.
Man darf sich jetzt darauf verlassen, weil es halt an ganz vielen Stellen
echt auch viele Vorteile hat.
Und das ist ein Pi-Pi-Feature.
Achso, okay, das war gar nicht klar.
Da gab es halt von Raymond Pettinger, gab es mal so ein
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 drei, sechs Versionen, sondern halt für unsere zwei, sieben Versionen.
Also bei uns sind halt Dictionaries schon immer, also nicht schon immer, aber jetzt schon seit ungefähr zehn Jahren irgendwie geordnet.
Und das war auch ganz schön, also dann, das war auch dann schon noch ein ganz schwieriger Aufwand.
Also dieser Python-Code war halt so ein, jetzt Sketch wäre ein bisschen untertrieben,
hat halt 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 Fischakowski und Armin Rigo haben das vor allem gemacht und dann hatten wir das halt irgendwie und dann gab es halt einen C-Python-Entwickler, der, der Name fällt mir gleich auch wieder ein, der hat das dann quasi wieder rückportiert.
Also hat er unseren Code genommen und hat gesagt, ja cool, wir bauen das jetzt in Zebraisen ein und hat dann die nötige, ich weiß nicht, ob es da ein PEP für gab oder ob er die nötige Mailing-Listen-Diskussion geführt und dann landete das halt in 3.6 und dann wurde es halt quasi auch offiziell Teil der Semantik.
Und ich meine, das ist ja eigentlich auch ganz cool, weil es ist halt wirklich, ich meine, das ist ja ein extra Feature.
Intuitiv irgendwie.
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 durcheinandergewirbelt werden.
Das war ja früher so. Also früher war es halt irgendwie, hing es von den Hashwerten ab, das war halt komplett intransparent, warum halt dann die Sachen plötzlich ganz anders dastehen.
Ähm, und es ist halt auch gar nicht so, es ist halt auch a priori gar nicht so klar, dass, dass das wirklich effizient geht. Weil man könnte ja halt auch denken.
Wie macht man das jetzt? Macht man quasi so ein extra dazu, das immer noch von den Hashwerten abhängt? Oder, äh.
Das ist gar nicht so einfach. Also so, da gibt es halt so eine, so eine komische Indirektion jetzt drin, dass man quasi einmal die Hashmap 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
sich halt ausgedacht haben, der Trick ist jetzt
die Hashmap, die darf ja nicht voll sein
weil du sonst Collisions kriegst
also wenn du quasi
wenn deine
Hashmap irgendwie zu voll wird, dann musst du halt irgendwie
die verdoppeln, um sie
herzustellen, dass...
Und nächstes Mal speicherfrei ist, wo du 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 Indirektion einbaust,
dann ist quasi ein Eintrag nur noch
ein Index in den
dichten, in den dichtgespeicherten
Insertion Order
Speicher.
So, jetzt sind wir an dem Punkt, wo wir eigentlich gerne ein Bild
malen würden.
Und 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.
Echt, genau.
Dann hat man quasi dann
für drüber iterieren, muss man dann einfach nur noch
durch die echte Liste gehen und es gar nichts mehr 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 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.
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.
Also werden
alle Sachen schneller?
Was mit anderen Sprachen, also kann da C++
irgendwie, wenn das irgendwie angebunden ist, ein Problem?
Also es wird
halt erstmal vor allem
Python schneller. Also wirklich, wenn du Python-Code
ausfüllst, wird das 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
es gibt halt dann 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, das ist ja
quasi so eine kleine DSL
in Python,
also du sollst ja DSL nochmal beschreiben, weil ich so
Language gemeint habe. 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 schnell ist.
Normalerweise kann ich die per PyEnv einfach
installieren, dann mein
PyPy auch? Ich glaube, PyEnv
unterstützt auch PyPy, ja. Also
Tox hat eigentlich zum Beispiel PyPy-Support, wenn du das testen willst.
Das ist schon an vielen
Stellen quasi so ganz
gut in die
in die
Infrastruktur.
Nach dem Semester-Fan
kriegen wir hoffentlich einen Alpha-Release.
Also 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.
Also die großen Features sind halt fast
fertig. Also Pattern-Matching
ist da und
3.10 hatte, also außer Pattern-Matching
halt auch viele so mittelgroße Sachen.
aber Pattern Matching, das war wirklich
auch, kann ich mir vorstellen, das macht
ja 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 Pypi, äh Pypi, äh Pypi
ist eigentlich reingefallen.
Da ist ja, da
weiß ich gar nicht, was da verwendet wird, aber das
könnte ja dann auch auswirken. Da hatte ich zum Glück sehr gut,
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.
Wir haben auch einen Packparser,
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 Grammatik-Datei reingeschaut hast?
Nee, nicht wirklich. Also das ist halt im Prinzip
so ein bisschen so eine kontextfreie Grammatik,
wie man das halt irgendwie
aus irgendeiner Informatik-Vorlesung
vielleicht mal gesehen hat, aber
im Unterschied zur alten Grammatik ist das so,
dass jetzt 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 ins Ziel 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 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 Pattern Matching
dann in den Parser zumindest einfach einzufügen
ist. Aber es ist
halt nicht nur ein Parser, es ist ganz viel
neues 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.
Da fehlt mir noch so ein Randfall,
den muss ich jetzt irgendwann noch fixen, der
hat mich bisher noch zu sehr genervt, aber
also 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
da 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.
Ich mag das total gerne.
Statt if, elif irgendwie einfach schöne Cases zu machen.
Gerade für so API-Parsing.
Also ich finde, man muss sich ganz,
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 Toy-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.
Ich glaube, wenn man dann da
so mal gedanklich drin ist, ist das glaube ich wirklich auch
sehr, sehr cool, aber man braucht so ein bisschen.
Oder ich habe das Gefühl, dass ich es noch so ein bisschen brauche.
Man kann irgendwie so direkte Kommandos geben und
man kann da direkt sagen, was das ist.
Und im Zusammenhang mit den Typen, finde ich, ist das sehr schön.
Weil 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.
Ja, das ist jetzt ziemlich schwammig, da würde ich, also ja.
Genau,
aber auf jeden Fall, also man hat da so ein
großes Feature, sowas wie Pattern Matching,
das ist halt schön, da kann man, weiß man,
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 Featuren fertig
und dann gibt es so ein bisschen,
zusätzlich zu den fünf großen Featuren gibt es halt
vielleicht 30
kleinere und mittlere Feature,
das ist halt so ein bisschen Fleißarbeit
und dann gibt es aber halt einfach
tausend 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
Testsuite, die
Teil der C-Python-Standard-Bibliothek
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 super.
Aber dann ist halt in allen anderen Dateien
gibt es halt dann so einen fehlschlagenden
Test und jeder von diesen fehlschlagenden
Tests dauert halt zwei Stunden
und das ist halt einfach das, was einfach ganz
ganz, also da
gibt es halt quasi dann so einen long tail an irgendwelchen
Details. Und der
quasi
Fortschritt, den man dadurch erzielt, dass man das
fix, ist halt auch irgendwann dann nicht mehr
so groß, dass man sich, wahrscheinlich denkt man sich dann irgendwann
so, das lohnt sich halt nicht mehr.
Wer das so irgendwann mal benutzt. Genau.
Okay, aber das ist tatsächlich dann TDD auch,
was ihr da macht. Ja, also
Piper ist von, also so 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
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 Programming Kontext auf der Entwicklungsphilosophie Seite. Also so mit Test Development und Agile, bevor das kommerzialisiert wurde, so von der Idee her.
Und es ist wirklich so, dass diese Implementierung von vornherein komplett testdriven entwickelt wurde. Das ist halt an vielen Stellen auch wirklich ganz tief drin in der Philosophie des Projekts. Und es ist auch so, dass PyTest aus PyPy hervorgegangen ist.
Also der Holger Kregel, über den haben wir, bevor wir anfangen aufzunehmen, kurz schon geredet, 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.
JUnit, aber ich glaube JUnit
ist irgendwie SUnit von
Smarttalk. 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 Teil
Projekt von PyPy halt angefangen
PyTest zu entwickeln
und
das ging dann quasi
aus dem PyPy-Projekt irgendwie so ein Stück
weit hervor und ist jetzt natürlich
eine Million Mal erfolgreicher
als alles, was PyPy irgendwie jemals sonst
so gemacht hat. PyPy-Spannende, also am Anfang
habe ich es gehasst und jetzt finde ich es richtig gut, weil es halt echt
total gut ist und ich finde es sehr PySonic
und wenn man einmal so ein bisschen vielleicht verstanden hat, wie das
funktioniert, das ist sehr, sehr, sehr schön
zu nutzen auch, ja. Also ich meine halt einfach so
dieses, dass man davon wegkommt, dass man diese
97 self-assert
irgendwas
Funktionen braucht, um gute Fehlermeldungen
zu kriegen. Das ist halt schon
self-assert, equal, irgendwie CamelCase und sowas.
Equal oder Equals?
Genau, ja, ja, genau.
Du machst bloß nichts Falsches.
Ja, und CamelCase 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
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?
Und
Ich weiß PyPy noch nicht ganz.
Ja.
Nein, Entschuldigung.
Also das Projekt ist halt entstanden
aus Diskussionen auf
erst der deutschen Python-Mailing-Liste
und dann irgendwie auch Complying Python
von halt
Python-Fans, also halt so ein paar
Leute, 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 die,
der Interpreter für Python, dass der ja
in C geschrieben ist.
Und Piper 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 ja 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 erst mal
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,
die 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 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 viel Aufwand,
also welchen Aufwand, da sage ich 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.
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 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 Experimente durchführen.
Aber das ist jetzt nichts, was man irgendwie
im Produktiv-Einsatz 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, ja, genau. Aber halt vielmehr
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 wir 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
Interpreter-Turm
problemlos. Also dann kann man quasi
den Python-Interpreter nehmen,
der ist nicht mehr in Python geschrieben, sondern in
ich sag jetzt gleich den Namen, in
R-Python. Das ist eine
Teilmenge der Sprache und die ist so
gewählt, dass man sie nach C übersetzen kann.
Und R-Python 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 gilt ja alle möglichen komischen Sachen. Man kann halt ja auch
bei einer Instanz
dann der Class zuweisen und so.
So dieses ganze ganz dynamische
Metaprogrammierungszeug, das ist halt einfach verboten,
weil da ist halt
nicht so klar, wie der C-Code dann aussähe,
den man da generieren würde. Also das ist der
erster Schritt. Der erste Schritt ist,
das ist nicht mehr Python
in beliebigem Python-Code, sondern das ist
eine Implementierung für die
Sprache Python in einer Teilmenge 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 Teilmenge
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 PiPi 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 das halt wirklich, das ist nur
ein Spielzeug. Und wenn man dann
diesen Bootstrapping-Trick macht,
dass man eben wieder C-Code 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 1000 Mal langsamer.
Nee, nee, nur zweimal langsamer.
Also Faktor 1000 kriegt man wieder.
Aber Faktor 2 hat man halt immer noch.
Und das ist natürlich immer noch nicht gut.
Also warum sollte man das machen?
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 eigentlich wirklich die Speed her?
Und da wird es halt dann so ein bisschen akademisch.
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 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 JIT-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 Just-in-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 Typ-Annotationen heutzutage so ein bisschen anders, aber die Typ-Annotationen, die sind ja auch so ein bisschen so eine Fiktion.
Also die dürfen ja auch falsch sein.
Also vergessen wir die erst mal.
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 diese Funktion nicht nach Maschinen-Code ü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
ein unterstrich unterstrich add Methode hat und
eine unterstrich unterstrich mul Methode und
die halt irgendwas super weirdes macht.
Das muss quasi die Anwendungsfälle
kennen, in denen das aufgerufen wird
irgendwann in diesem Programmablauf und dann
daraus jeweils unterschiedliche Implementierungen
im Machine Code zu schreiben, die man dann
verabschiedet. Ja, 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 hier immer ins, weil es kann ja sein, dass es halt an sieben verschiedenen Stellen wird die Funktion jetzt aufgerufen und an zwei davon sieht es so aus, als könnten es ins sein, aber an den anderen drei weiß ich nicht so genau und das ist überhaupt in der 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 Just-In-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 Just-In-Time-Compiler eben funktioniert, ist, weil er einen ganz krassen Informationsvorteil hat. Der Just-In-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 dann irgendwann sehe ich halt, na gut, das 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 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 Ins 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 erzeuge, 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 weg optimieren.
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 Dustin-Time-Copilers, der kann halt dann auch darauf reagieren, dass du nach einer halben Stunde Programmlaufzeit plötzlich den Debugger anmachen willst.
Also, dann muss man nämlich anfangen, quasi wieder alles zurückzupacken und das nennt man wirklich Deoptimierung, dann muss man wirklich quasi wieder die Frame-Objekte erzeugen, die man halt braucht, um dann, dass der Debugger auch funktioniert, also der Debugger, der introspeziert 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 Bagger anschaltet,
dann muss man die halt jederzeit wieder herzaubern können.
Okay, 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 Just-in-Time-Compiler für JavaScript zu schreiben,
die halt wirklich extrem aggressiv zur Laufzeit
den JavaScript-Code optimieren
und zur Laufzeit nach Machine-Code übersetzen können.
Und deswegen ist JavaScript halt inzwischen,
jetzt sage 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 jeder von diesen Implementierungen 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-Modul geschrieben
und das war quasi ein JIT für
CPython.
Wenn man das Extension-Modul
geladen hat, dann hat halt
Zyko angefangen, zur Laufzeit aus
den Python-Funktionen halt irgendwie Maschinencode zu erzeugen.
Und das hat halt auch gut
funktioniert an vielen Stellen.
Und das große Problem von Zyko war jetzt aber,
dass jede neue Python-Version, die rauskam,
hat das komplett kaputt gemacht.
Also weil, sobald ein neues Sprachfeature dazukam,
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 Sprachfeaturen und den alten Sprachfeaturen gibt.
Und die waren halt nicht zu übersehen.
Also da, ich weiß nicht, was kam in 2.3
dazu? Vielleicht Generatoren
oder so?
Gab es da nicht auch irgendwelche Scoping-Änderungen?
Weiß es nicht, ja kann sein, ich weiß es
nicht mehr genau, ja, aber...
Ja, krass, ne, also krass.
Auf jeden Fall, die haben
halt dann immer nicht funktioniert in Psycho
und Armin hat halt irgendwann dann 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 PyPy
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
über, also JIT heißt,
das ist die Abkürzung Justin Timecubiler,
dass man den überhaupt nicht von Hand schreibt.
Und 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 reißen und
die haben dann halt keinen Spaß, die schreiben ganz, ganz
viel komplizierten C++-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
Sprachentwicklung 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, 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 Ansatz.
Ich meine, ein Compiler-Compiler und so, das ist ja Jack und so.
Ja, aber da ist der Input halt kein Interpreter.
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
das war, der hat sich in gewisser Weise auch sehr viel
getraut. Er hat gesagt, ich hab 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
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 PyPi-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 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 riesen Vorteile, weil nämlich,
Wenn, also nehmen wir mal sowas Konkretes wie Pattern Matching.
Pattern Matching kommt jetzt raus in 3.10.
Dann implementieren wir das in unserem Interpreter.
Also PyPy 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?
Nee.
In R-Python.
In R-Python, genau.
Das ist alles in R-Python.
Aber wir interpretieren das quasi in dem in R-Python 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 Pattern-Matching versteht und richtig guten Maschinen-Code für Pattern-Matching erzeugt.
Und der JIT-Compiler-Generator, der kennt Pattern-Matching halt gar nicht, sondern der lernt die Semantik von Pattern-Matching halt wirklich, indem er 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 kein Python, sondern der kriegt halt die Semantik von Python ab, indem er sich diesen Interpreter für Python anschaut.
Und wenn man in 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 dann eventuell
hätte, ist, man kann dann damit ja
einen JIT-Compiler für jede Sprache
erzeugen, für die man
in R-Prize einen Interpreter schreiben kann.
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.
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,
ü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 R-Python geschrieben.
Und das heißt, wir können halt auch zur Laufzeit
dann die regulären Ausdrücke nach Machine Code
übersetzen. Weil
wir halt quasi für diesen
anderen Interpreter, der auch in R-Python
geschrieben ist, auch ein JIT erzeugen.
Und tatsächlich gibt es halt so einen ganzen Haufen an Research-Quality-Sprachimplementierung, 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, ja, aber also das war 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 den SQL-Code auch in so ein Bytecode. Dafür habe ich halt auch einen Interpreter in Erpreisen 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 an Queries so kommt.
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, da kann man ja, oder
String beides. Das heißt, es ist auch noch eine dynamische
Sprache, eine dynamisch zivilisierte 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
diese Idee, dass wir halt quasi ein
JIT-Generator haben
und diese
Architektur sorgt dafür, dass wir halt
mit einem relativ kleinen
Team halt
mit CPython trotzdem ganz gut mithalten
können, weil wir die Features halt
eben nicht in den JIT-Compiler
reinschreiben, 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 dann noch so ein paar Tipps geben.
Ja, weil wahrscheinlich manchmal wird das halt dann
überraschend nicht gut funktionieren.
Ganz genau. Und man
kriegt halt dann einen Maschinencode und der ist
vielleicht noch nicht so gut, wie man den gerne 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
an 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. Ja, das ist eh ziemlich
langsam, ne?
In Zebraten ist es nicht so toll, oder?
Ich weiß nicht, was... Ich glaube, also habe ich gehört, dass es nicht so
schnell ist. Ich weiß es nicht, ja.
Also ob das jetzt bei uns...
Wir würden halt dann wirklich aus
dem Pattern Matching 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
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 ja quasi aber immer den
Generator anlehnen, 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 den Python-Code nicht
nach C-Code, sondern wirklich direkt nach Machine-Code.
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
Maschinen-Code-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 Produktivumgebung nicht mehr.
Sondern da wird halt wirklich direkt
ins RAM werden halt
die Maschinen-Instruktionen für
die aktuelle CPU-Architektur
emittet
und dann führen wir das halt direkt raus.
Also sprich, wenn du das halt
auf irgendwie 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 einfach hin.
Und dann von da an läuft halt wirklich der Machine Code und der, also wenn man Glück hat, ist der 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.
Und den ganzen Overhead von den ganzen Sachen.
Ja, also man hat halt dann die Frame-Objekte nicht mehr, man hat die ganzen Typ-Überprüfungen nicht mehr, idealerweise. 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 Merlock-Aufruf. Und das ist ja eigentlich absurd teuer.
also ein malloc-Aufruf und
es wird eben
der Reference-Count auch noch immer manipuliert
also
vielleicht auch nochmal ganz kurz für die Leute, die ja nicht ganz so tief sind
ein malloc-Aufruf, also eine Memory-Location ist
ein C, eine Funktion, die auf dem
Heap was macht, vielleicht nochmal ganz kurz
ganz tief rein erklären wir was Heap steckt
vielleicht kann man
das einfach nochmal so ein bisschen den Kontrast herstellen
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 den gleichen, wenn du irgendwie
so ein 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 ins CPU-Register laden.
Dann machst du wirklich die
Addition. Dann musst du gucken,
ob das Ergebnis immer noch
klein genug ist, um in einen
Maschinenwert reinzupassen. Das könnte ja auch
irgendwie ein Overflow geben und dann brauchst du irgendwie
ein komplizierteres Objekt.
Und dann brauchst du Speicher
für das Ergebnisobjekt, weil das Ergebnis ist
ja auch wieder ein Integerobjekt. Das heißt, du rufst einmal
Malog 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, also deswegen ist Arithmetik
halt in Python klassischerweise
wirklich sehr, sehr ineffizient.
Weil du halt wirklich
ständig malloc 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 Standard
unser Standard
arithmetischer Ausdruck schon die ganze 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 Aufruf.
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 0. Das brauche ich ja gar nicht mehr.
Und dann rufst du Free auf.
Das ist wieder quasi so ein teurer
Aufruf zu dem
Memory-Subsystem.
Wie genau schreibt der Null den Speicher oder löscht der einfach
die Speicheradresse aus, dem wir
benutzen das? Genau, und dann kannst du
quasi den Speicher wiederverwenden, das nächste Mal,
wenn jemand mehr drauf hat. 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
ja, um sich zu merken, dass
dass das jetzt ein Stück freier Speicher ist.
Am Anfang von einem Speicherblock schreibt der irgendwie
so ein... Das ist
glaube ich gar nicht so wichtig. Das funktioniert
auch sehr unterschiedlich, je nach Betriebsstil und
je nach
verwendetem
Allokator. Also da gibt es halt auch
verschiedene C-Bibliotheken, die man da verwenden kann.
C-Python
hat da auch so ein bisschen 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
das ist kompliziert und wir müssen
das hoffentlich nicht verstehen.
Also das ist quasi,
da kenne ich mich dann irgendwann
ziemlich schnell halt auch nicht aus.
Ja, aber letztlich,
das Problem ist halt, dass es halt,
Speicheralluzien
ist halt eine relativ komplexe,
weil man halt auch das Betriebssystem, den Kernel,
fragen muss letztlich.
Nicht jedes Mal, aber irgendwann schon.
Letztlich. Und dann, das ist natürlich alles sauteuer.
Ja. Und dieser ganze
Overhead fällt halt weg, wenn du A plus B
mal C mit ins ausführst
und der JIT ging da drüber,
dann hast du halt wirklich auch,
dann allozierst du dieses Zwischenergebnis auch nicht.
Sondern dann sagst du halt einfach
na gut, A
kommt in den Maschinenregister,
das mal zwei, zwei ist halt irgendwie
so ein Intermediate in deiner
Maschineninstruction
und dann hast du noch eine zweite Maschineninstruction,
um die Addition zu machen
und das Ergebnis ist auch in dem Register, je nachdem
was mit dem Ergebnis passiert,
kann es da auch bleiben.
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,
die normale
Python-Implementierung halt immer machen
muss, fällt halt weg.
Ja.
Und ich meine, so ein bisschen die
Einsicht, also 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, sehr eng 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 machst du die ganz
merkwürdige Sachen und machst halt so ein bisschen
Metaprogrammierung und schreibst irgendwelche Sachen
in das Globals-Dictionary
mit einem Globals-Aufruf
oder sowas, schreibst 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 ein
Eine Sache, die wir immer wieder sehen, da gibt es auch
Aussätze zu, die das studieren.
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...
Ja, oder halt so ein Debugger
ist halt auch ein... 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.
Wenn es zu unterschiedlich ist, dann
kann man nicht mehr debuggen.
Du möchtest 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
dein Web-Server dann wirklich crasht, dann
willst du diese Information halt haben.
Und dann zu sagen, ja,
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
das ja immer mal. Da musst du ja wirklich sagen, will ich
jetzt Debugge-Informationen haben oder nicht.
Und wenn du die nicht hast, dann kriegst du,
dann sagt dir halt keiner mehr,
was jetzt gerade in deiner Variable drinsteht.
Und
das, also
meiner Ansicht 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.
Ja.
Genau.
So, jetzt haben wir glaube ich so ein bisschen alle Ideen. Also historisch gesehen, Python in Python, also historisch gab es diese Verständigkeitsidee, 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 schnell einen Code machen.
Aber stattdessen kam halt diese andere Idee dazu.
Wir wollen einen Just-in-Time-Copiler 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 Just-in-Time-Copiler.
Und das hat geklappt.
Also das hätte auch schiefgehen können,
aber die Kernidee funktioniert ganz gut.
Und jetzt sind wir quasi so ein bisschen auf dem Plateau der Produktivität,
dass 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 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,
dass die Hauptarbeit, die wir
wirklich machen, ist halt zu versuchen,
von C-Python nicht komplett abgehängt zu werden.
Ist A-Python,
hat das Type Annotations 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, R-Python ist leider tatsächlich noch komplett Python 2 basiert.
Und wir haben halt leider auch sehr, sehr wenig Motivation, das zu ändern, weil wir haben halt leider sowas wie, sage ich mal, eine halbe Million Zeilen Code in diesem blöden Python 2 Dialekt.
Und wir könnten uns jetzt hinsetzen und
einfach so, um jetzt mal eine Schätzung
abzugeben, zwei
Person-Years 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 Portierungs
Aktion zu starten,
ist halt
einfach nur so,
also mir würde das halt nicht so viel Spaß machen.
Ja, klar.
Aber das ist natürlich trotzdem in gewisser Weise auch kein Zustand.
Also weil irgendwie,
also
man will halt auch
letztlich dann irgendwie auch nicht komplett abgehängt
werden. Also ich meine,
das wird dann wahrscheinlich irgendwann auch ein Problem,
da neue Leute
ranzuführen, weil man denen dann ja irgendwie
ein 2 beibringen muss.
Das hattest du jetzt schon vergessen.
Aber das Print hat keine Klappern.
So genau.
Ich meine, das andere, so ein bisschen
doofe Problem 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 Byte-Strings
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 so ein bisschen doof.
Würde denn irgendwie diese
keine Ahnung, TypePins oder andere Features
von Python 3
jetzt für die
Annotation von dem Compiler irgendwas bringen?
Nicht so richtig.
Also man könnte ja 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 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.
Ich denke halt so ein
also
das wird halt stattfinden,
wenn wir irgendjemand
finden, der da mega Bock drauf hat oder
wenn wir halt Geld finden.
Und ich glaube, wenn beides nicht stattfindet,
dann
vielleicht bin ich
da zu pessimistisch, aber dann sehe ich das
im Moment halt nicht.
Ja gut, klar.
Also ich persönlich,
ich kann nur über mich sprechen, ich persönlich
hätte da halt keinen Spaß dran.
Ja, aber ich meine,
ist es dann, wenn man tatsächlich keinen Unicode hat,
sondern nur ByteStrings?
Ich meine, es gibt ja da so automatische
Geschichten. Könnte man das nicht eventuell auch automatisch
irgendwie?
Und man da halt einfach
einmal so zwei, two to three
draufschmeißt.
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.
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 gut haben.
Aber ja, es ist halt,
also man will das jetzt halt keine 10 Jahre so
weitermachen.
Aber so den idealen Weg,
wie wir da jetzt wieder rauskommen aus der Geschichte,
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.
Ja, also das ist,
bei Django-Projekten gibt es sowas ähnliches
mit dem Admin,
mit dem Django-Admin,
das ist halt auch so ein Ding,
das ist über Django-Projekte auch halt 15 Jahre,
das ist halt über 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 Leute, die sich damit auskennen,
sagen halt so, ja, 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.
Naja, so ist es halt ein bisschen auch.
Und ich meine, das sieht man ja auch wirklich
ganz konkret bei C-Python. Also C-Python
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 DIT-Generator halt da ist und gut funktioniert.
Aber halt alles, was
jetzt mal so irgendwie so
in Anführungszeichen, also Bonus-Values 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 Funding-Stand
nicht hin.
Weil das kriegst du halt nicht durch,
also 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
hatten wir ja vorhin schon kurz drüber geredet,
wir hatten halt irgendwie zweimal so
wirklich große Forschungsförderungsprojekte,
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
so
und dann danach hatten wir halt viel so
immer wieder Funding auch von Firmen, die halt
dann bestimmte Features gerne haben wollten
aber
seit
einer Weile gibt es halt niemand,
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,
es gibt ja diverse, es gibt ja ganz viele,
wo die Basis für
die Menge...
Genau, das ist die 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
momentan sehr aktive PiPi-Entwickler
der Matipikus, 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 fix,
das ist auch Teil, heißt das auch Steering Council
bei NumPy, weißt du das zufällig?
Nee, keine Ahnung. Also der ist auch quasi Teil
des Komitees, das halt NumPy
verwaltet und ist da
sehr aktiv. Deswegen geht NumPy auch
gut auf PyPy, weil er sich halt da drauf auch kümmert.
Achso.
Ja, also
Also bei NumPy passiert es langsam eben schon. Also sowas wie Jupiter 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.
Wenn du das ganze Internet an so einem kleinen Faden aufhängst.
Ja, ich habe gehört, also die Idee fand ich auch 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 Versicherungspolizei dafür, dass es das halt auch in Zukunft gibt, weil wenn 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. Und passiert ja ein Stück weit auch. Also halt sowas wie, ich glaube es ist ja.
Man muss halt Projektanträge schreiben, ne?
Müsste man halt Projektanträge schreiben, ja.
Und da ist es halt dann so ein bisschen so,
da ist halt PyPy dann letztlich
auch vielleicht nicht wichtig genug, ne?
Also bei PyPy kann man halt nicht sagen,
das ist jetzt eine absolut die
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 CPython und ich glaube
schon, dass jetzt unser Wert
halt jetzt auch, selbst wenn man das nicht
einsetze, es ist 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
Geld 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.
Aber wenn ihr Lust drauf habt, dann
sagt Bescheid.
Wir nehmen gerne
Freiwillige an. Also ich finde es zum Beispiel
Read the Rocks 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, ich muss mal gucken, ob mir die
Folge einfällt, wo der
Read-the-Docs-Gründer halt auch
so ein bisschen über seine Philosophie von
Open-Software-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 voranbringen,
die Docutales-Patches
schicken und
da ist ja wirklich, also
da sind wir ja, da ist die Python-Community ja auch
wirklich ziemlich gut aufgestellt.
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.
Wie heißt das, ist das Eric Holscher?
Ja. Genau, ich glaube,
da gab es ein Django-Chat-Episode, die gar nicht so
sagen, er ist vor ein paar Monaten zu Gast war
und da hat er da einiges. Ich packe die auch mal
in die Schotter und zwar nichts, wenn ich mich daran erinnere.
Ja.
Und ja, das ist ein großartiges Beispiel.
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
angestellt, 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 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 Compilern 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, sind jetzt nicht ultra viele Stunden, aber halt zumindest schon so ein paar Stunden, die sind halt da und die werden halt auch, solange aus meiner Ansicht nach da halt es 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 irgendwie so eine ganz krasse neue Idee für eine neue DIT-Optimierung sich auszudenken.
Also manchmal läuft es dann über Abschlussarbeiten ganz gut.
Also ich hatte gerade eine unglaublich coole Bachelorarbeit betreut, das ist jetzt noch nicht gemerged,
Aber der hat echt eine sehr interessante neue Optimierung
für den JIT-Compiler auch geschrieben,
die auch gerade bei Programmen, die viel mit Integern machen,
wirklich nochmal ganz anders Sachen optimieren kann.
Also echt ein 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.
In eurem Code ist das doch ganz anders,
sag doch mal.
Genau so, ja.
Und
er hat dann dabei halt
auch immer recht, also das war
sehr, sehr cool mit dem.
Ich hoffe auch, dass er quasi weitermacht
und vielleicht irgendwie auch noch
eine Masterarbeit schreibt, aber
manchmal passieren halt dann so 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 entdecken. Nee, das ist eigentlich okay.
Ja stimmt, wir schreiben ja dann auch
Wir 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
Ja, also wir stecken schon auch
ich meine
Wir machen 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 Weg, also viele Forschungsprojekte sind halt so
Code zum Wegschmeißen. Man schreibt Code
man schreibt ein Paper und dann ist man
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, den 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,
also das, aber weil
halt so der Output an Pippen aufsetzen
bei mir vielleicht halt nicht so ganz
stimmt. Also
ich schreibe 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
und dann, also in der Physik
manche Leute kommen, sieht man das dann häufig,
dass dann doch irgendwie so
sich Sachen aufeinandertürmen, die halt
irgendwie man vielleicht dann doch mal, wenn man gewusst hätte,
wo man hinterher rauskommt,
hätte man das auch 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 an, um bei einem
der PiPi-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 CERN und so, die haben halt
ein ganz interessantes Stück Technologie,
nämlich die haben einen C++-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++ zu lernen, um halt schnell
einen Code zu schreiben, aber die wollen ja auch Skripting
machen. Und wenn wir jetzt halt so
einen C++-Interpreter haben,
dann können die ja mit der Sprache, die die eh
schon können, halt auch ihre Skripte
schreiben.
Und das war halt so
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 Skipping, ja.
Aber das ist halt für mich immer so
ein Beispiel, wenn man, also
einer, 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
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 Dit-Compiler, das stimmt. Aber man kann jetzt eben nicht sagen, dass C++ eine kompilierte Sprache ist, weil es gibt ja Cint und das ist halt eine Implementierung von C++, 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++. 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.
Ja, ne, interessant.
Ja.
Ja, ich weiß nicht,
spielt eigentlich diese,
da gab es ja 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
Jill, 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 rein
Zeit investiert. Das hat halt
am Schluss nicht so gut geklappt, wie sie sich
erhofft hatten. Was ist das überhaupt?
Vielleicht nochmal. Also ich bin
da sehr schnell raus.
Ich habe das halt immer so interessiert verfolgt
und die hatten halt dann so einen 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 soll das denn theoretisch
sein? Also ich habe gar nicht verstanden,
gehen soll? Also die Idee
von Source Transaction 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 Datenbank-Ansatz.
Jeder Thread hat eine
eigene Transaktion und
der Thread, der läuft
so ein bisschen und dann versucht er zu committen.
Committen heißt, dass seine
Sicht der Welt, also seine Sicht
des Zustands des Programms,
mit der Sicht der Welt der anderen Threads
irgendwie gemerged 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 Transaction 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 das 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 schneller einen 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 den weg?
Es gewinnt halt einer von denen.
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 kompliziert.
Da weiß ich auch nichts zu.
Aber 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 sind alle deine 16 Cores irgendwie busy,
aber dein Programm ist nur zweimal so schnell.
Und das ist quasi so ein Performance-Bug.
Und 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,
wir haben jetzt zu viele Konflikte-Probleme,
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üste ausgegangen,
vielleicht, also nach
sechs, sieben Jahren.
Ja.
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 Amins Idee.
Amins Ansatz war ja mit dem Budgetgenerator auch schon so, der hat eine Vision, die ist technisch irgendwie elegant und dann versucht er das umzusetzen und bei Budgetgenerator hat es geklappt und bei Software Transactional Memory hat es halt leider nicht geklappt.
Und vielleicht, wenn er noch ein paar Jahre weitergemacht hätte,
hätte es auch irgendwann geklappt, aber
momentan arbeitet er da 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, das ist überhaupt nicht mein
Gebiet, ich kenne 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 einem anderen Thread auch benutzen will,
wird es halt dann
performance-mäßig teurer.
Und das ist quasi
eine neue Einsicht. Die kommt jetzt in
diesen klassischen Ansatz,
Shared-Memory-Multiprocessing 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
Es gibt auch so ein paar Tricks, also ein interessanter Trick ist, weil es gibt dann ja deutlich mehr so viele Sachen, die halt schon in allen Threads verwendet werden, also alles was irgendwie globale Ports und so Zeug.
Also None zum Beispiel.
Ja, None, 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.
Ja, aber was mir zum Beispiel noch nicht so ganz klar ist,
man hat ja dann eigentlich
oft auch an irgendeiner Stelle
doch eine gesharete Datenstruktur. Also wenn du halt zum Beispiel
irgendwie so ein Workstealing 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
das, also diese Feinheiten,
also wie da dann wirklich die Performance
sich dann in der Praxis wirklich verhält.
Was ist ein Workstealing? Ich glaube, das weiß halt keiner.
Was ist ein Workstealing?
Also bei Workstealing ist halt quasi, du hast
verschiedene Arbeitspakete
und verschiedene Threads, die die abarbeiten
und
du koordinierst
diese Threads halt über irgendeinen
Q. Und die Frage ist
jetzt, welche Datenstruktur benutzt du, um
diese Q
zu
repräsentieren?
Und Workstealing ist einerseits, da hat
jeder Thread seinen eigenen Q,
glaube ich, und wenn ein Thread
nichts mehr in seiner eigenen Q hat, dann klaut er was
aus den Queues. 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, bestimmte Schalter halt nicht.
Und da kann halt irgendwie sich Leute anstellen
an verschiedenen Schaltern und wenn irgendwie
eine gerade keine
Kundin mehr vor sich hat, dann geht halt jemand drüber.
Aber ich glaube, also wie da
so, ich habe da kein gutes Modell.
Also ich bin wirklich ein sehr
single-threaded Mensch.
Ich kann das auch nicht, aber
ich habe 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 Kurs laufen und die wollen alle auf eine
Liste zugreifen. Also das ist auch etwas, was irgendwie
sehr schlecht, 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 ganz nicht, weil
es ist wirklich
und es mefft 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 Jython.
Jython ist, soweit ich
das sehen kann, relativ tot, aber
so in der 2.7 ist es ein sehr guter
2.7 Interpreter, der halt
Implementierung, der halt
keinen Dill hat, der halt wirklich Multithreading kann.
Das ist auch eine ganz, ganz
fast, das war etwas, was ich jetzt bei dem
Durchhören der Folgen, eine der Neuigkeiten,
die ich da mitgenommen habe, die ich vorher echt gar nicht wusste
und mich fragen, wie mir das entgegen konnte, aber
dass halt, wohl wenn man einen JIT-Compiler
hat, dass es viel besser geht mit dem
Fine-Grain-Blocking, sozusagen, dass man
gar nicht unbedingt ein JIT braucht, dass es
halt mit einem
Interpreter, der in C geschrieben ist und der statisch
kompiliert ist, geht das gar nicht richtig.
Aber Java, wenn er
das von einem JIT-Compiler
verwandelt, ist das kein Problem
sozusagen und da kann man das dann ohne
JIT mit Fine-Grain-Blocking machen und es wird halt nicht langsam
dadurch. Ja, 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 oder also
und man macht halt dann nicht bei jedem
Field Read muss man sich das Log holen,
sondern kann sagen, wir lesen hier 17
verschiedene Felder und wir holen uns das nur einmal.
Und das kann der JIT halt machen, das kann der Interpreter
nicht machen.
aber ja, also da sind wir noch nicht
in Python, ja, genau, 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 Threadsafe
sind, natürlich nicht, weil
wie soll denn die
Bugs gefunden werden, wenn halt die Standard-Immunisierung
halt einfach immer
Single-Threaded ist und
selbst in der Standard-Bibliothek hat halt
Jython damals quasi
einiges an Wachs gefunden,
wo es halt Deadlocks und alles mögliche gab,
weil der Code
in der Standardbibliothek von
Jython halt einfach
den Gil präsent
poniert. Und ich denke,
das wird halt schon dann auch nochmal
für die Community auch ein ganz schön
langwieriger Prozess, bis man
halt wirklich an dem 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 PyPy-Umfeld
und da bin ich
auch nicht ganz direkt beteiligt, aber der ist meiner Ansicht nach
auch schon sehr interessant und das ist nämlich genau
die Frage nach NC-geschriebenen
Bibliotheken
und das Projekt heißt
H-Py 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 heraus.
Weil das ist ja einfach,
wenn man die C-API 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 das halt nicht zusammen.
Und HPAI ist halt die Idee,
wir fangen einfach so
nicht ganz auf dem Reißpfeil, 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 ist irgendwie
Version 0,04 raus oder so
oder die wollen jetzt irgendwann bald mal
zu einem 1.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ärtskompatibel,
du musst niemals neue
Shared 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
weiter benutzen kann. Das ist
eines der Designziele. Ein anderes
Designziel ist, dass man
den Debugging-Mode anschalten
kann für den C-Code,
ohne dass man
neu kopieren muss. Sondern quasi
zur Importzeit kannst du sagen,
hier ist irgendein komischer Crash,
mach mal bitte den Debugging-Mode an
und dann findet er zum Beispiel
Reference-Counting-Probleme
in der CPU-Bibliothek,
ohne dass man die neu kompilieren muss.
Das ist ein anderes, finde ich, sehr interessanter Eigenschaft.
Und also das Coole ist,
dass Oracle
hat auch eine Python-Implementierung, die heißt
GraalPy. Und die haben jetzt
quasi zwei ihrer Entwickler oder
zweieinhalb ihrer Entwickler dafür angestellt,
sich eben zu überlegen, wie man
dieses H-Py-Ding designt. Und da
passiert also quasi so richtig was.
Und ich habe halt die Hoffnung, dass jetzt irgendwann
in diesem 2023
es da die ersten Releases gibt.
Und das ist schon auch so, dass es quasi jetzt das Portieren von der existierenden API auf HBi 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 entschieden, davon abzuweichen.
Naja, also auf jeden Fall,
wie gesagt, ich bin da nicht mit involviert.
Ich rede manchmal mit denen.
Das ist einer der GraalPi.
Der GraalPi-Tag-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
in Zeiten Supporter für eingebaut wird.
Das wäre sehr, sehr cool.
Und das würde eben dazu führen, dass in Zukunft Extensions, die H-Pi benutzen, halt auch wirklich schnell auf Pi-Pi 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 Pi-Pi ist, dass es effizient in Graal-Pi ist, trotzdem nicht langsamer ist auf C-Python.
Und der Übergang zum vorigen Thema ist jetzt, dass sie 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 wenn dann eine Extension quasi in der Situation kommt,
dass sie jetzt ganz viel anpassen müsste,
um mit dem Jail 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 Jail-Features.
Also 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,
brauchen wir nicht mehr.
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
wir haben kein offizielles
Buy-in von CPython.
Also es gibt einige CPython-Entwickler, die
quasi sehr
wohlwollend sind, aber
wir haben quasi kein offizielles
Endorsement.
Wir sind immer mal
ein bisschen am überlegen, ob es
ein sinnvolles PEP, also ich habe jetzt
wie gesagt, ich bin dann
ich als interessierter Beobachter bin nicht
wirklich, also ich schreibe keinen Code dafür, aber
die HP-Leute denken auch immer mal darüber
nach, was man für ein PEP
schreiben könnte und was da
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 hypothetische
noch nicht geschriebene Peps, ist das ein reines
Informationspapier, wir arbeiten daran,
nehmt uns wahr und
also ja, da denken wir halt
bis zur Tour nach. Also es gibt den
Lukasz Langer, der
auch von
Vollzeit an über die PSF
an den Teamweizen arbeitet.
Der war auch bei dem
8-Pile-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.
Aber ich hoffe halt, dass da
in diesem Jahr noch ein paar interessante Sachen
passieren.
Interessant, ja.
Ja, ich meine,
mir sagt das gar nicht so viel.
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.
Jyton, Iron Python,
das ist alles nicht mehr so
richtig da. Unladen Swallow
gab es auch. Ja, das ist lange tot.
Ja, PyPy
ist so eine der ganz
wenigen, die
überlebend sind. Ja, genau. Also GraalPy
halt auch. Also GraalPy hat halt wirklich ein Team,
die sind auch bezahlt und 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 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 Long-Running-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 im Moment.
Das ist halt für eine Implementierung
eine sehr angenehme Situation.
Und der Tim weiß auch, was er tut.
Ist sehr, sehr gut.
Also Tim Felgenkopf
heißt der Taglet.
Und
die sind glaube ich auch 3.10
kompatibel und
supporten C-Extensions
und also das ist schon eine sehr ernstzunehmende
Infektion.
Ja, cool.
Warum schreibt man sich sowas dann direkt
in Rust, wenn man das eh statt in C neu zu schreiben?
Die schreiben das in Java neu.
Also Graal,
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 auch so eine ähnliche Motivation,
die haben so einen Meta-JIT-Ansatz,
dass sie quasi keinen JIT schreiben, sondern
den JIT auch generieren
aus einem Interpreter
mit einer anderen Technik, aber
aber halt so von der Motivation her ist das
recht ähnlich und
die benutzen das, 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, und 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, also 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 es ist halt die Hoffnung, dass es irgendwann mal
dann
vielleicht doch Geld verdient, aber ich glaube im Moment
ist es halt wirklich eine Wette.
Und die läuft auch schon lang, also das Projekt ist
irgendwie zehn Jahre alt oder so.
So irgendwie 30 Leute über zehn Jahre
anzustellen, 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 mach ich
natürlich auch immer gern, aber ja.
Also das ist quasi so ein bisschen Friendly-Competition,
aber 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
sein JIT?
Und die
klassische Antwort ist halt C oder C++.
Und
es gibt jetzt
verschiedene so
forschungsaffine Projekte wie
Squeak, ganz klassischerweise,
oder eben PyPy oder
GraalPy, die halt sagen,
es ist doch eigentlich viel cooler,
wenn man 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 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
Graal
Ruby-Projekt, also
das heißt TruffleRuby, das auch
von Shopify zum Teil finanziert wird.
Also die leisten sich mehrere
eigene Ruby-Impositionen.
Und
das eben, heißt das
YJIT? YJIT heißt es, ne?
Ja. Genau. Und 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
Maxime Chevalier-Boisvert,
die das gestartet hat,
YJIT bei Shopify,
mit der zoome ich auch auf und zu.
Die ist auch extrem gut.
Aber 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ß man dann,
das kann man erst so ein bisschen abschließen,
beurteilen nach dem dritten Jet vielleicht.
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.
Ich meine,
C++ 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.
Es ist halt so ein bisschen die Frage,
an welcher Stelle würde die Extra-Safety von Rust
die gewinnbringend im Compiler?
Weil das, was an einem Diff-Compiler dangerous und scary ist,
ist halt nicht, dass der selber in der unsafe Sprache geschrieben ist.
Das ist natürlich auch ein Problem.
Und das ist nicht das primäre Problem.
Das primäre Problem ist, dass man selber Maschinencode
erzeugt. Und der darf halt nicht falsch sein.
Aber bei diesem Problem
bringt einmal Rust auch nichts.
Weil Rust, dann ist der Compiler,
dann ist der
das Ding, in dem man den JIT-Compiler
schreibt, das geht halt nicht kaputt.
Beim Interpretieren deines Interpreters,
der was anderes 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 Pinefly Tested schreiben.
Der ist auch deutlich länger.
How is Digit Tested? Das ist
nämlich wirklich auch nochmal
so ein bisschen so ein, das ist ein richtig eigenes
Forschungsfeld. Und ich lerne auch immer mal
wieder was dazu. Also gerade
so im LFM-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
JIT-Bugs gefunden. Also das war echt ganz
interessant. Und da gibt es halt so
einen Prof in Utah, John Regge heißt der, 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.
Ja, cool.
Interessant.
Ja, Pai Pai.
Ja, sorry, da texte ich euch zu.
Nee, das ist genau,
deswegen sind wir ja da.
Können wir jetzt bitte endlich
schlafen gehen?
Nein, ist auch nicht der Messer.
Naja, Reden ist halt auch Teil
meines Jobs und das...
Ja, ich finde das total interessant.
Ja, ich auch.
Ja, ich überlege nur gerade, ob wir noch
irgendwo ein großes Thema vergessen haben,
aber ich glaube, wir haben tatsächlich das meiste
so durch. Ich habe auch das Gefühl,
wir haben einen guten Rundumschlag gemacht.
Ja, vielen Dank, Karl, dass du da warst.
Es macht mir natürlich auch wirklich
Spaß.
Merkt man auch. Merkt man sofort,
dass das da ganz viel
Also, falls ihr mitmachen wollt,
wie gesagt.
Ich mache jetzt hier mal so einen allgemeinen
Aufruf. Es ist
Also, es gibt natürlich schon so
ein paar, ich will es jetzt nicht zu schlecht
reden, es gibt schon ein paar Hürden. Wir haben Python 2,
wir sind in Mercurial, wir sind nicht auf GitHub,
wir sind am Fork von GitLab,
der auch mit Mercurial geht.
Also es gibt so ein paar Nervigkeiten
beim Einstieg, aber
es ist in gewisser Weise
halt so ein bisschen auch
die netteste Python-Implementierung, bei der man
einsteigen kann, weil man halt Python schreibt.
Und man nimmt halt PyTest
und man schreibt PyTest und man kann halt
irgendwie seinen Debugger nehmen
und man kann halt die ganzen Tools, die man
kennt, Python 2 ist da so ein bisschen
doof, aber also die ganze
Arbeitsweise, die man halt kennt, wenn man sowieso schon Python kann,
die kann man benutzen, um
da drin rumzuhacken.
Und das macht halt auch ein Stück weit einfach
Spaß. Also man ist halt nicht
in GDB
und man hat halt kein SecFault, sondern man kriegt halt
erstmal einfach einen ganz normalen Python
Stacktrace, der einem sagt, in deinem Interpreter
hast du jetzt hier einen Fehler gemacht.
Und man schreibt halt einen Unit-Test einfach in Python,
der die Datenstrukturen des Interpreters halt auch
einfach testen kann. Und das ist halt
auch, also ich finde das
immer noch auch sehr, sehr cool.
Und deswegen, ich glaube so, wenn man sich halt
für das Gebiet überhaupt
so ein bisschen grob interessiert, wie
funktioniert eine Programmiersprache oder
wie funktioniert so ein Bytecode-Interpreter oder
irgendwann dann auch, wie
funktioniert so ein JIT, ist das schon auch
ein Projekt, wo man halt
im Vergleich zu, ich lerne jetzt erstmal
C++ für ein Jahr und
es ist ja dann auch vielleicht in so einer
virtuellen Maschine auch komisches C++,
wo man dann doch auch recht leicht irgendwie
reinkommen kann und
ich
also ich sage das auch
immer mal wieder, wenn sich da halt jemand für interessiert
und dann da gerne was
machen möchte, ich mache da auch gerne
immer Mentoring, das ist halt auch
Teil meines Jobs, ich betreue halt irgendwie
Studenten, die da dann auch
drin arbeiten, als Teil ihrer Arbeiten, also
insofern weiß ich halt dann
also habe ich quasi viel Übung in Onboarding
und das ist auch was,
was mir Spaß macht, also wenn sich jemand jetzt für irgendwas
konkret interessiert, also es gibt
Themen verschiedenster Art,
dann
kann man sich immer gerne
bei uns melden und ich
zoome dann immer gerne auch mit Leuten
und mache so ein bisschen Pair-Programming
beim Einstieg, damit man halt einfach so ein bisschen
also
die erste Stunde in einem neuen Projekt
ist ja immer die schlimmste. Also man weiß halt nicht,
man findet halt nichts.
Wo ist man da jetzt gelandet? Ja genau, was ist denn das
hier für ein Ordner und wie startet das
eigentlich? Wo kriege ich eigentlich das Python 2 her,
was ich brauche. Und wo geht es mit deinem Essen?
Genau, ja. Und das ist halt, also da
versuche ich halt dann immer auf jeden Fall
deutlich den Leuten halt auch zu helfen.
Und das ist auch was, was mir wirklich
Spaß macht. Also meldet euch
und
ja.
Ja, klingt auf jeden Fall sehr gut. Ja, vielen Dank.
Ja, wollen wir vielleicht noch
Pics machen? Möchtest du Pics machen? Ich hatte
jetzt nur einen kleinen,
der gar nichts mit sonst wie
Dingen zu tun hat, über die wir gerade geredet haben.
Dann lassen wir es weiter. Dann lassen wir es weg.
Okay, alles klar. Gut. Ja, dann vielen Dank,
dass ihr eingeschaltet habt. Ja.
Schaltet wieder ein. Sehr interessant diesmal.
Danke, dass ihr dabei wart. Vielen Dank für die Einladung.
Ja, danke. Bye. Okay.
Bis zum nächsten Mal. Tschüss, bis dann.