Ja, hallo liebe Hörer und Hörer, willkommen beim 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 ein bisschen 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
einen Compiler-Flag
einführen soll, das den Global Interpreter
Log optional macht.
Also die letzten Woche große Neuigkeit,
also ich glaube, 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
nur so ein Riesenthema ist, weil, ehrlich gesagt,
betrifft es mich meistens nicht, weil ich bin eigentlich bisher kaum je in die Situation gekommen,
dass dieser Global Interpreter-Log für mich jetzt ein großes Problem gewesen wäre.
Aber ich habe mir den jetzt nochmal angeguckt und tatsächlich, also es gibt da schon viele Situationen,
wo einen das halt Ärger machen kann. Also mein Beispiel war, ich hatte ja mal gefragt,
ob jemand ein anderes Beispiel hatte, also wenn ich 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 Probleme 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 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 2025,
26 dann halt irgendwann dazu überzugehen,
dass halt quasi...
Ich weiß jetzt gar nicht mehr, welche 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.
Keine Ahnung.
Und der Plan ist aber erstmal, das quasi hinter einer
Interpreter-Compile-Time-Flag
zu verstecken.
Ja, okay.
Jetzt haben wir ja direkt am Anfang
sowas 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 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 Multiprozessor-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 Multithread-Algorithmen in Python schreiben kann.
Ist das brauchbar zusammengefasst?
Ja, doch, 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, Larry Hastings oder so
hatte das, das ist jetzt auch fast 10 Jahre her oder so,
hatte dieses
Gilectomy-Projekt, wo
eben halt auch versucht hat, das loszuwerden
über so Fine-Grained Locking, weil
normalerweise ist halt
also für den Garbage-Collector braucht man
das ganze Reference-Counting
ist halt hinter dem Gil oder ist halt
der Grund dafür, warum der Gil
und Jochen unterhalten sich über die Programmiersprache Python
und es gibt halt schon ein Ding, das kann man auch über Python installieren, ich habe das mal ausprobiert,
das nennt sich irgendwie Python Nogil oder so, das macht nur 5% 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 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, wenn man gar nicht kritisiert hat, zwar kann man nur
innerhalb von einem Thread erzeugten Sachen aufräumen,
oder Reference-Counting macht,
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,
und das sind halt
24 Byte
mehr pro Objekt, das ist schon nicht so ohne.
Also Speichermess ist auch ganz schön.
ja,
ja, also
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.
Und deswegen,
und die C,
dass 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 Interpreter, den man verwendet.
Also man muss quasi jede C-Extensions
einmal anfassen und zum Teil die
C-API
Usage irgendwie dann
korrekt machen und die Logs einführen,
wenn das nicht 3D-safe ist.
Also das ist halt möglicherweise schon auch Aufwand.
Ja, ja.
Ja.
Also das wird dann tatsächlich ein Breaking Change
sein, wenn die CX-Expansions
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 nutzen willst...
Ja, aber wenn der Default sich ändert...
Ja, aber das ist dann irgendwann, das ist dann in der
weiteren Zukunft. Also das ist dann 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 deflocated
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, das finden wir.
Ja.
Wer war denn da bei Facebook nochmal mit dabei?
War das Sam Gross?
auch. Genau.
Du hattest vielleicht den Vortrag auf der Europe
halt den letzten Tag gesehen. Ja, ja.
Ich habe nicht so viel verstanden, aber ich habe mir
angefühlt. Okay, ja.
Ja, ja, ist auch ein schwieriges Thema,
glaube ich. 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 diese Informationen,
die darin stecken, in einen Pointer
reingefiemelt irgendwie, reinkodiert
und das war den Leuten aber dann
jetzt zu heiß.
Das ist zu gefährlich.
Was kann da alles bei Overflows passieren?
Daran sieht man schon,
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.
Okay, ich füge es mal hinzu.
Alles klar.
Er hat das nämlich genau erklärt, wie er das so vorhat.
Und das ist schon...
Er hat einige clevere Ideen dabei gehabt.
auch ein spannender Typ, ja
ja
okay, habt ihr noch nichts
du hast gesagt Packaging, ja ich hab noch
ja Packaging
ja das war ein anderes großes Thema, auch
vor zwei Wochen oder so gestartet
oder noch ein bisschen länger und das
könnte halt immer noch so passieren, es gibt einen sehr sehr langen
Thread
ich weiß gar nicht genau wo war das denn
das Ding heißt irgendwie
Packaging Strategy Discussion Teil 1
das ist auf DiscussPython.org
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 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
eins 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 denn jetzt, am besten wie rum man die
hält, damit es nicht irgendwie
keine furchtbaren Sachen passieren und
ja, das ist ein Problem und
aber es gibt auch keine so richtig einfache
Lösung.
Ja, und ich weiß es nicht so genau. Ich glaube, das
Fazit war mehr so, ja, es liegt halt
vor allen Dingen daran, dass halt auch Python einfach sehr alt ist
und Leute das auf sehr unterschiedliche Art verwenden und
man kann es nicht gut lösen, weil
man kann nicht allen gerecht werden,
weil manche Leute brauchen halt sehr feingranulare
Geschichten und andere lieber
ein Einfaches 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 das war auch erst wenige Wochen alt, von
Nathaniel Smith, ein
neuer Paketspracher, 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 Graphen bauen und so, und das
sah, fand ich, relativ interessant aus, weil genau
das auch eines der Pages, die allen Leuten, mit denen ich
irgendwas mit Python machen will, erstmal
erklären muss, hä, wie geht denn das? Oh, das ist aber kompliziert
und warum ist das denn so?
Ja, also bald dann halt, also wenn die einen Python machen,
okay, aber wenn die nochmal eine andere Python-Version, irgendwann habe ich es ja später
so, geht alles kaputt und Python-Python
und dies, das ist für einige Menschen gar nicht so einfach
zu handeln. Ja, und Natalia ist auch jemand,
der man quasi dem Geschmack zutraut,
das richtig gut zu machen.
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, hat auch einen sehr
tollen Artikel geschrieben
irgendwie für Structured Concurrency,
den verlinke ich auch mal gerne
oder sage Leuten, dass sie das mal durchlesen sollen.
Ja, insofern,
ja genau, das habe ich auch direkt
aufforschen lassen und nicht gehört, wer das gemacht hat.
Ja,
auf der anderen Seite weiß ich jetzt nicht so genau,
also er schreibt, gut, er macht das jetzt in Rust, weil
er wollte schon immer mal was für Rust machen.
Ich weiß nicht genau, wo man das unbedingt, also alle
Leute machen momentan irgendwie Dinge, Tooling in Rust.
Bei JavaScript verstehe ich das so ein bisschen, weil
die haben da, also jede Änderung
im Code führt halt dazu, dass irgendwie so 20
Transpiler, irgendwelche
Linter, sonst was irgendwie loslaufen und Dinge machen
und
wenn dann jedes Mal so ein fetter Node.js-Prozess
gestartet wird, dann
dauert das, dann addiert sich das
natürlich irgendwie auf in der Latenz, aber
Python hat man das ja so eigentlich auch nicht
Ja, aber immerhin hast du eine vorkompilierte Binary
die du irgendwie ausliefern kannst und in Rust ist das
vielleicht so einen Typen sicher 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 Shell-Skript irgendwie von
einer Webseite ausführen, ja.
Ja, okay. Gut, das löst es. Das stimmt.
Ja. Das sind so ein paar Sachen,
die glaube ich echt gar nicht schlecht sind. Also ja, aber was das
Cool, also ich hab's 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 ich meine,
das, was ich meistens verwende, ist halt für Pakete
bauen, Flit, das macht
eigentlich nur das, ansonsten verwende ich für Abhängigkeit
PipTools
und, ja.
Ja, PipTools fand ich ja fürchterlich, aber du findest Poetry
fürchterlich und was Poetry ist auch... Ich hab Poetry lange
verwendet, also fürchterlich ist...
Ja, wir hatten uns ja, glaube ich, das war schon
ein, zwei Folgen her, mal über dieses
Problem mit den Dependencies
irgendwie schon auseinandergesetzt.
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.
Das Problem ist, dass
Poetry implizit halt,
wenn man sagt Poetry
add irgendein Paket,
irgendwie ein Upper Bound auf die
Version macht,
was für, wenn man eine Library schreibt,
für andere halt sehr blöd ist, weil die dann sofort
und Dependency-Problemen laufen, Konflikte laufen.
Man muss ja manuell quasi tatsächlich dann...
Ja, aber...
Naja, gut.
Ach ja, genau.
Das ist, glaube ich, eine gute Idee.
Keine Lösung.
Ich habe letztens gesehen,
PipTools in PyProject Hummel irgendwie reingemeldet.
Ja, 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 er 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
im Moment ist das ganze Packaging und
Dependency-Management-Zeugs irgendwie relativ
furchtbar
das funktioniert auch nicht US-übergreifend gut
und das ist
ziemlich amiss. 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.
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,
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 verlangt 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ücknä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
wieder zurückkommen, dass es einfach so,
und Jochen unterhalten sich über die Programmiersprache Python
Und wie stellt die Datenbank sicher, dass ich jetzt keine Probleme habe festzustellen, dass Dinge auf die gleichen Stellen zugreifen?
Ja, das ist ja das, was die Datenbank eigentlich...
Das ist ja so die Kernkompetenz eines Datenbankmanagementsystems sozusagen.
Ja, aber...
Wie soll das hängen?
Ja, aber das Problem hast du jetzt ja auch schon, wenn du mehrere Frontends hast oder mehrere Prozesse auf deinem Frontend, die gleichzeitig alle irgendwie...
Ja, aber die Datenbank muss ja gucken, dass sie einen Log setzt dann irgendwie und dann muss sie halt irgendwie gucken, ist das Log auch da oder muss halt eins setzen, wenn sie da irgendwie dran rumfuchtelt.
und dann muss ich es wieder machen.
Du meinst jetzt so Richtung Right-Zugriff oder was?
Ja, aber ich meine, dann schaust du an eine Transaktion
und siehst, dass dann
eine konsistente Sicht der Dinge
innerhalb der Transaktion
oder die wird halt dann committed oder aborted
und ich glaube,
ich stimme dir zu,
Jochen, zu, dass das halt genau das ist, was die Datenbank
im Prinzip richtig gut können sollte.
Aber das macht ihr doch eigentlich dann langsam, oder?
Ja, natürlich macht das alles
viel langsamer, wenn man Transaktionen ausschaltet
und F-Sync ausschaltet, dann wird das
mit der Datenbank viel schneller.
Aber das Problem ist halt, dann sind deine Daten eventuell auch weg.
Das ist ja doof.
Das ist doch wieder doof.
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 sollten die Daten
schon können
ja
gut, man hat nochmal ein bisschen Probleme
weil
zum Beispiel Postgres kann halt nur
es kommt darauf an, welches Protokoll man verwendet
aber das Textprotokoll
von Postgres kann halt nur
eine Query gleichzeitig
beantworten, das heißt
bisher war das kein Problem, weil man kann sowieso immer nur
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
intern poolen oder muss irgendwie
aus dem Pool
fallen. Das ist sowieso alles sehr kompliziert.
Auch die ganze Geschichte im ORM, was man dann umstellen muss,
das wird noch lange dauern, bis das alles
richtig funktioniert. Aber wenn es dann mal
irgendwann funktioniert, ist das ja cool.
Und das ist jetzt ein Schritt, ein weiterer
Schritt dahin. Also wir haben jetzt async ORM,
async Views, async Tests.
Ja, ja, also ORM haben wir noch nicht
Wir haben nur die Interfaces
Jetzt auch den Support für eine Library, die wir dafür brauchen
um das überhaupt machen zu können
Das heißt, das letzte was wir anstellen ist ORM
Genau, das ist halt
auch noch das komplizierteste Stück Arbeit
was noch da bevorsteht, genau
Ja, 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 sie haben irgendwie
einen Weg gefunden, wie sie das so hinkriegen, dass es kein Problem mehr ist.
Und das
ganz nett ist,
ab dann
wird man halt eventuell,
es gibt so Django
in-memory-storage, ich weiß nicht genau,
gibt es ein externes Paket, das sie nicht mehr brauchen,
das ist dann auch in Django selber drin. Das heißt,
man hat jetzt ein
in-memory-storage-backend für
Django mit dabei, das man einfach so verwenden kann
für Tests zum Beispiel.
und macht halt Tests einfach schneller.
Und, das freut mich
besonders, es gibt jetzt
eine Streaming-HTTP-Response
mit Async-Iteratoren
dran. Das ist im Grunde,
wenn man jetzt
zum Beispiel Files ausliefern will,
ist das halt
ein Problem. Das ging bisher nicht so gut,
einfach deswegen, weil man
da halt über die Blocks
eines Files, die man rausschicken wollte,
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
serven, gehalten, da habe ich das halt, dieses Ding rausgepatcht, irgendwie so per Monkey Patching
und es gibt auch ein Paket Django File Response, wo ich das so mache, das ist dann nicht mehr nötig,
weil das macht jetzt also ein Iterator, das heißt, es müsste eigentlich Files serven, 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?
Edinburgh.
Okay. Tja. Und PyCon.de oder PyData ist in Berlin 17. bis 19. April. Da gehe ich wahrscheinlich auch hin.
Europice ist vom 17. bis zum 23. Juli.
Okay.
Aber ich weiß nicht wo.
Okay.
Damit auch ja keiner
einen guten Flug buchen kann.
Das wird auch in Europa passieren wahrscheinlich.
Oder das ins Budget fürs Jahr einplanen kann.
Für was auch immer.
Ich glaube gerade das Management-Team hat da gewechselt.
Ja.
Also die letzte hat noch
Mark and Re mit organisiert und jetzt machen das
irgendwie andere Menschen.
Okay.
Die haben so eine neue Art und Weise wollen die machen mit
und wer das wie veranstaltet und sich was Neues Konzepte überlegt.
Mal gucken, ich bin gespannt.
Jojo.
Okay, ja, nee, dann, das wäre ja nach nur fast 20 Minuten mit den News durch,
diesmal relativ flott, dann kommen wir zum Hauptthema.
Dann eine ganz schnelle Folge.
Das glaube ich nicht.
Wie bei PyPy?
Ja.
Warum mal, ja, die Folge ist ja PyPy.
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.
Hallo.
Ich gehe hier 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 2005
ungefähr einer der Kernentwickler des
PyPy-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
fandet Ding, was dann PyPy
direkt entwickelt.
Genau, also ich bin jetzt quasi einfach
erstmal nur so quasi
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.
so EU-Förderung,
Forschungsförderung,
immer mal wieder auch Geld von Firmen und
bei einigen von diesen
Forschungs-
oder Förderungsprojekten war ich halt auch dann
quasi aktiv dabei.
Da musst du auch mal direkt erzählen, was PyPy
überhaupt ist. Ja, genau.
Also 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 angeben 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 Kernentwicklungen
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.
Es ist ja immer so ein bisschen
so ein Meme, dass Python halt irgendwie besonders
langsam sein soll und Piper 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 Py, Py,
über die, also
das ist so ein bisschen doof, dass die
so ähnlich sind, aber
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
PyPy 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?
Ne.
Naja, im Cheese-Shop gibt es halt Käseräder.
Ja. Und die Wheels
sind halt Käse.
Okay, ah. Also, ja.
Das heißt, im Käseshop gibt es so Wheels.
Ja, okay, verstehe. Und deswegen gibt es Reels
auf PyPI.
Genau, und irgendwann haben die halt dann aufgehört mit diesem,
weil Cheese Shop ist halt doch sehr
idiosynkratisch
oder verspielt.
Der erste Draftnamen
von unserem Podcast war so Ministry of Silly Talk.
Ja, ist gar nicht schlecht.
Und also irgendwann wurde halt PyPI
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.excel unterbinden oder halt einfach nur
PyPi und das verhält sich eigentlich
idealerweise ganz
genauso 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.
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 ab und zu Bugs 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 da 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.
Es gibt eigentlich keinen
Randfall, der so merkwürdig ist,
dass es nicht eine Bibliothek gibt,
eine kleine vielleicht,
die sich dann beschwert, wenn man das kaputt macht.
Selbst wenn man halt dann sagt,
Wir sind aber viel konsistenter und das macht ja so viel mehr Sinn.
Das ist halt doof.
Für so eine Bibliothek ist das doof, wenn sie
dann so unterscheiden muss,
auf welcher Python-Implementierung
sie jetzt gerade laufen.
Deswegen versuchen wir da auch nichts mehr
zu verbessern.
Es gibt natürlich trotzdem Stellen.
Wir haben halt dann, was weiß ich, mal eine leicht andere Fehlermeldung.
So etwas kommt da schon vor.
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 C-Python hat
halt so eine Doppelfunktion, dass es
einmal
ist das 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 in 3F zum Beispiel ganz doll.
Aber insbesondere gibt es halt
auch bei jeder Version irgendwelche neuen Sprachfeatures.
Das heißt,
Python.org, diese Community, die ist halt
für zwei Sachen zuständig. Einmal
dafür, dass das alles funktioniert, aber auf der anderen Seite
eben auch für so Fragen wie,
welches Pad 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
letzte offizielle Release und dann
das Prinzip heißt und baut das dann eure Änderungen.
und es ist schon dann mal so, dass wir bei den
C-Python-Diskussionen dann auch mitreden und
sagen, ja aus unserer Sicht hat das 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
Pipeline-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 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
eigentlich haben wir immer 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 darauf 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, also 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, also 3.9
ist jetzt eigentlich sehr, sehr stabil
und 3.10
ist in der Mache, aber noch nicht released.
und danach kommt halt dann 3.11.
Also das ist quasi ein Nachteil,
warum man PyPy halt nicht nehmen sollte.
Ist ein bisschen hinterher.
Und dann
habe ich vorhin gesagt, naja, jedes Python-Programm
sollte halt gehen und idealerweise schneller sein.
Da gibt es jetzt zwei
Fußnoten an dieser Aussage.
Die eine Fußnote ist halt C-Extensions.
Aber Lampai ist kaputt?
Nee, kaputt halt nicht.
Also inzwischen ist das so, dass wir so eine
komplette Kompatibilitätsschicht
haben, mit der
80% aller
in C geschriebenen
Bibliotheken in PyPy 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 einen 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 kostet halt so ein bisschen
Performance. Das heißt, bei uns sind in C-geschriebenen Erweiterungen halt
quasi, die funktionieren, die können aber halt oft einfach
langsamer sein. Und das ist natürlich doof, weil...
Du machst einen Paket, der schneller sein will, aber die Sachen wird langsamer, als wenn du die eigentlich auf normalem Python-Offenheitsfeld
hast. Genau. 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 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 es wäre dann
zum Teil einfach auch echt besser, wenn man halt einfach
Python-Code nehmen würde.
Aber weil halt für C-Python alle jetzt schon
ihre tollen NC-geschriebenen Optimierungen gemacht haben,
ist das dann für uns oft
auch halt eine Verschlechterung.
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 das Problem ist, du willst ja halt beide Seiten auch miteinander reden lassen.
Wenn du halt nur C-Code hast, dann ist halt eh die Frage, was hast du da noch mit Python
zu tun.
Spannend wird es halt dann, wenn dein Programm 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 einen Python geschriebenen Code
und
der wird nicht schneller, also man muss
halt einfach messen
und um mal so ein bisschen so eine
Größenordnung zu nennen, wir haben halt
so Speedups
zwischen, so im allerbesten
Fall, wenn halt alles ganz toll ist und du
Pure Python Code hast, gar keine Bibliothek, die ins hier 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 in Python kriegen. Also das ist schon, also alle Leute, die halt sowas wie
Advent of Code machen. 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 Performance ist irgendwie auch
wichtig und da ist halt PyPy einfach
mega gut dafür.
Genau, also bei Performance
ist es halt so, man muss halt einfach messen.
Du kannst halt nicht
quasi so a priori entscheiden,
dass es immer jetzt
Speedup X
bringt, sondern es führt
quasi keinen Weg darum, dass du deine konkrete
Anwendung halt ausprobierst und schaust,
bringt es was oder halt nicht.
Habt ihr da irgendwie ein Referenzsystem oder macht ihr das einfach mal
so objektiv von dem überliegenden 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.
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 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ß.
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, 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 der 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 mal so ein bisschen von PyPy.
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 C-Python dann doch
jemand mal gesehen und fand es cool genug,
um es halt dann doch
halt auch dann mal quasi nachzuimplementieren.
Und jetzt ist es
so ein bisschen, fast so ein bisschen so ein Race manchmal,
also gerade sind die,
haben die ganz schön auch vorgelegt, also
so ein paar der Fehlermeldungen haben wir
jetzt noch nicht wieder übernommen,
aber an ein paar Stellen gibt es halt
immer noch ein paar, wo ich mit unserem
dann zufrieden hat. Zum Beispiel so ein absoluter Standard-Anfängerfehler,
wo man halt echt Riesenprobleme hat, wenn man in Python
einsteigt, wenn man so Objektorientierung lernt. 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
mit der Funktionsdefinition
und sagt, was ist denn eigentlich dein Problem?
Ich habe ja doch drei Argumente, warum
beschwerst du dich denn, dass ich da nur
zwei reinreiche?
Oder ja, 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 schaue ich,
dann schaut der Interpreter nach, ob das erste
Argument self heißt.
Und wenn nicht, steht einfach nur
noch da, did you forget self
in the method definition?
Ja, 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 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.
Aber das ist halt eine,
wo ich mal dann so einen Tag
dran Spaß hatte, mir zu überlegen, wie man das halt vielleicht
verbessern kann.
Aber ich bin halt,
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 Inzial-Push. Wir hatten halt an
vielen Stellen
da so ein paar Sachen dann zuerst implementiert
und das fließt jetzt
ganz stark in den T-Preisen an, 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,
eigentlich ist das 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.
Das wurde jetzt auch
abgeschafft.
Ich glaube jetzt auch in 3.11.
Oder in 3.10, ich weiß nicht so.
Zum Teil gab es diese
Synthex-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 Quotes vergessen hat beim
String. Du hast einfach nur
x gleich A, B, C und dann
hast du hinten die Quotes vergessen. Da war früher
die Fehlermeldung
irgendwie EOL
while scanning string literal.
Endpalette runter oder sowas auch noch verteilt.
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,
sagte dir jetzt auch die Fehlermeldung,
wo
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, der darin liegt.
Und am Schluss fehlt was dann.
und das wurde in 3.10
gefixt, ist es jetzt halt so, dass er dir
wirklich dann die Zeile zeigt, wo die öffnenden
Glöckelbots sind und das ist natürlich viel schöner
und die andere
Zeilennummer kommt aber auch vor in der
Fehlermeldung, das heißt, du hast dann wirklich beides
und
ja, also das ist alles schon
sehr, sehr cool und ich meine, die
in 3.11, die Position Informations
die sind halt auch so ein bisschen
das war quasi noch ein bisschen
FISA von mir. Das hatte ich noch nicht mal implementiert.
Da habe ich nur so ein 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
ein Screenshot davon getwittert und
das hat
Pablo gesehen und dann
super auffällig. Es war ja
ein wirklich sehr nerviges Feature.
Ja, das glaube ich. Ich habe mich schon gefragt,
wie das implementiert wurde,
weil das war ja sehr cool, aber
Oh mein Gott, wie ist das denn implementiert?
Wie kriegt man das denn alles raus an den Stellen?
Man muss halt wirklich einfach die gesamte Information
durch den gesamten
Stack so durchfädeln.
Und das ist an jeder Stelle, da muss man das weiterreichen
und an jeder Stelle hat man halt
am Anfang hatten die
Syntaxbäume halt auch die 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, es gibt halt
Fehlermeldungen, da wird ja jetzt die Position, wo das
der Fehler passiert ist, mit so
Dreiecken unterkringelt, quasi unterstrichen
wo das halt aufgetroffen wird
Und da hatte ich halt diesen Tweet gefakt und jetzt gibt's das
Also das ist mega geil, das sollte ich einfach
öfter machen
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-Weiten drin ist
finde ich einfach mega cool
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
Also das ist ja in 3.6 glaube ich
Informell, 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
und man darf sich jetzt darauf verlassen, weil es halt an ganz vielen
Stellen echt auch viel Vorteil hat.
Und das ist ein Pi-Pi-Feature.
Achso, okay, das war gar nicht klar.
Da gab es halt von Raymond Hettinger, 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 in
Engineering, was man halt braucht, um
das dann wirklich quasi in Produktiveinsatz
in die Implementierung einzubauen.
Das haben wir halt einfach dann irgendwann mal gemacht.
Und zwar noch nicht mal
für unsere 3.6-Version, sondern halt für
unsere 2.7-Version.
Also bei uns sind halt Dictionaries schon immer,
also nicht schon immer, aber jetzt schon seit ungefähr 10 Jahren
irgendwie geordnet. Und das war auch
ganz schön, also das war auch dann schon
nochmal ganz schwierig der 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 hat das dann quasi wieder
rückportiert, also hat halt unseren Code genommen
und hat gesagt, ja cool, wir
bauen das jetzt in C-Python 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.
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.
und Jochen unterhalten sich über die Programmiersprache Python
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
dein HashMap irgendwie zu voll wird,
dann musst du halt irgendwie die verdoppeln,
um sicherzustellen, dass
du beim nächsten Mal speicherfrei bist, 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
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
dichtgespeicherten
Insertion Order
Speicher.
Jetzt sind wir an dem Punkt, wo wir eigentlich gerne ein Bild
malen würden.
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 das wirklich
eine gute Idee ist.
Ist es aber. Also Schnelligkeit
raus, es ist es.
Ja, cool.
Echt interessant.
und 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 hat dann quasi,
verliert auch ein If in jedem
Next-Aufruf.
Also vorher war es so, dass man quasi in einem
Next aufrufen 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, schick.
Ja, genau.
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,
jetzt müssen wir vielleicht so ein bisschen anfangen,
darüber zu reden, wie das eigentlich geht.
Also die Kern...
Vielleicht, ich hätte noch ein, zwei Fragen.
Ja, absolut.
Werden alle Sachen schneller?
Was mit anderen Sprachen?
Also kann da C++ irgendwie, wenn das angebunden ist,
ein Problem?
Es wird halt erstmal vor allem
Python schneller.
Also wirklich, wenn du Python-Code auswählst, 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
und dann gibt es halt
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 extra
Optimierung dafür. Das ist ja quasi
so eine kleine DSL
in Python.
Kannst du die DSL nochmal beschreiben,
weil ich so ein Längenwissen weiß?
Genau, eine Domain-Specific-Language
für String-Matching.
Ich meine, das ist eine sehr häufige, die halt quasi überall
eingebaut ist, aber es ist ja schon eine andere
Programmiersprache als Python letztlich.
Aber wir haben halt dafür auch dann quasi
ganz viel Optimierung gemacht,
dass das halt auch schon ist.
Normalerweise kann ich die per PyEnv einfach
anzudämmen, dann mein
PyPy auch? Ich glaube, PyEnv
unterstützt auch PyPy, ja. Also Otox
hat eigentlich zum Beispiel PyPy-Support, wenn du das testen willst.
Das ist schon an vielen
Stellen quasi so ganz
gut in die
Infrastruktur.
Nach den Semesterferien
kriegen wir hoffentlich einen Alpha-Release.
Da arbeite ich gerade dran.
Heute Morgen habe ich
zwei Packs gefixt. Das ist das, was ich
jetzt gerade wirklich konkret mache.
Die großen
Features sind halt fast fertig.
Pattern-Matching ist da
und
3.10 hat außer Pattern-Matching
auch viele mittelgroße Sachen.
oder so.
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 CPython
irgendwie gemacht werden,
weil da dann der neue
Packparser irgendwie verwendet wurde und ich weiß gar nicht,
bei PyPI
ist es mir reingefallen.
Da ist ja,
da weiß ich gar nicht, was da verwendet wird, aber das
könnte ja dann auch aussehen.
Da hatte ich zum Glück sehr gut...
Vor einem Jahr hatte ich dann 3.9 implementiert
und da war 3.10 ja schon
raus und da habe ich halt 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
das File 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 Informatikvorlesung
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 wollen wir halt nicht
haben. Und wir müssen quasi
die Schnipsel an C-Code, die mussten wir halt quasi von Hand
einfach einmal überall ersetzen. Und das war
sehr, sehr nervig.
Und das ist auch so ein bisschen meine Kritik,
dass quasi
die Grammatik der Sprache
vermischt wird mit den Parsing Actions,
die in C geschrieben sind, bei C Python.
Bei uns sind die nicht in C geschrieben,
wir werden gleich noch darüber sprechen, worin
die bei uns dann geschrieben sind, aber
das war halt dann einmal sehr,
sehr nervig, da drüber zu gehen und alle
diesen C-Schnipsel dann da auszutauschen.
Und da gibt es, 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.
Also da fehlt mir noch so
einen 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
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 gefühlt ihr dir Pattern Matching?
Ich liebe es.
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.
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...
Irgendwas geschrieben, was halt
nicht einfach so ein Toy-Beispiel ist.
Aber man muss sich schon so ein bisschen reindenken.
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 es, glaube ich, wirklich auch sehr, sehr cool.
Aber man braucht so ein bisschen.
Oder ich habe das Gefühl, dass ich so noch so ein bisschen brauche.
Man kann irgendwie so direkte Kommandos geben und man kann da direkt sagen, was das ist.
Und in Zusammenhang mit den Typen, finde ich, ist das sehr schön.
Wenn man halt tatsächlich Typen definiert hat, dann kann man halt einfach diesen Typ als Case nehmen.
und das ist halt
genau das, was man wahrscheinlich irgendwie...
Aber was man dann wirklich in die Pythons 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.
Du musst vielleicht gleich nochmal so ein bisschen
ausholen darüber, was eigentlich so eine Sprache aus deiner Sicht
halt ist.
Das ist jetzt ziemlich schwammig.
Genau.
Aber auf jeden Fall, 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.
Über ein paar Tage hinweg fängt es 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
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 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 Standardbibliothek ist, ausführt
und dann halt die fehlenden Tests nach und nach fixt.
Und mit den großen Features ist man halt irgendwann durch.
Also es gibt halt Test-Pepma, das hat man halt irgendwann dann,
das passt dann, das ist 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
fixt, ist halt auch irgendwann dann nicht mehr so
groß. Wahrscheinlich denkt man sich dann irgendwann so
das lohnt sich nicht.
Wer das irgendwann mal benutzt.
Aber das ist tatsächlich dann
TDD auch, was ihr da macht.
Ja, also Python ist von
der Entwicklungsphilosophie sehr
also ich meine,
wir haben ja vorhin ganz kurz gesagt, dass es
jetzt irgendwie 20 Jahre altes Projekt ist.
Also es wurde
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
Extreme Programming
Kontext auf der Entwicklungsphilosophie
Seite, also so mit
Test Driven Development
und Agile
bevor das kommerzialisiert
wurde, so von der Idee her und
es ist wirklich so, dass
diese Implementierung von vornherein
komplett Test Driven
entwickelt wurde. Das ist halt an vielen Stellen
auch wirklich ganz tief
drin in der
Philosophie des Projekts.
und es ist auch so, dass PyTest
aus PyPy hervorgegangen ist.
Also der Holger Krickel,
über den haben wir, bevor wir
anfangen aufzunehmen, kurz schon geredet, der war
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.
Ja, JUnit, aber ich glaube
JUnit ist irgendwie SUnit
von SmartHawk.
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
jemals sonst so macht.
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
verstanden hat, wie das funktioniert, das ist sehr, sehr, sehr schön
zu nutzen.
Also ich meine halt einfach so dieses, dass man davon wegkommt,
dass man diese 97
Self-Assert irgendwas
Funktionen braucht, um
gute Fehlermeldungen zu kriegen. Das ist halt schon
SafeAssert, Equal, irgendwie CamelCase
und sowas. Equal oder Equals?
Genau, ja, ja, genau.
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 Tests heißt dahin und dann geht halt,
das ist halt schon sehr, sehr cool.
Also Test-Driven-Development
war halt einer der
Kernideen, so auf der
wie entwickeln wir dieses Projekt?
Das andere war halt,
das ist so ein bisschen verloren gegangen über die Jahre, aber
einer der Ideen am Anfang war halt wirklich,
wir wollen eine sehr
gut verständliche Implementierung der
Sprache schreiben. Und da
müssen wir irgendwann jetzt halt dann
doch mal zur Architektur kommen.
Warum heißt das Ding eigentlich PyPy?
Weil es PyPy
noch nicht gab.
Nein, Entschuldigung.
Also das Projekt ist halt entstanden,
aus Diskussionen auf erst der deutschen
Python-Mailing-Liste und dann
irgendwie auch Complaint Python
von halt
Python-Fans, also halt so ein paar Leuten, die
irgendwie Python als Programmiersprache toll fanden
und die halt gesagt haben, naja, es ist doch philosophisch
eigentlich irgendwie blöd,
dass wir alle Python so toll finden,
aber der Interpreter
für Python, dass der ja in C geschrieben ist.
Und
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 Ursprungsmodifikation, wir wollen jetzt die
Sprache nehmen, die wir cool finden, um
die Sprache selbst zu implementieren.
Und das klingt halt erstmal ganz
also nach einem sehr akademischen
Experiment und
das war es ein Stück weit, glaube ich, auch erstmal.
Also erstmal war halt so ein bisschen die Idee auch,
Wir wollen irgendwie Code schreiben, den man halt einfach erstmal schön lesen kann.
Und der soll natürlich schon auch irgendwie funktionieren,
aber insbesondere soll der halt einfach architektonisch toll sein und irgendwie elegant
und alles schön, diese Sprachsemantik soll irgendwie ganz klar ausgedrückt werden in diesem Python-Code.
Das war quasi eine der Ideen.
Und erst später kam es dann hinzu, dass quasi Performance eigentlich ein immer wichtiger Teil der,
der Projektmotivation war.
Also irgendwann hat man halt gesagt, naja,
okay, wir haben das jetzt, aber warum sollte man das machen?
Und wir machen jetzt halt auch noch ganz, ganz, ganz viel Aufwand,
um, also welchen Aufwand,
vielleicht sage ich noch ein bisschen was dazu,
wir machen halt ganz, ganz viel Aufwand,
um das dann doch irgendwie auch schnell zu kriegen.
So, und vielleicht können wir da auch einfach wirklich historisch vorgehen.
Also die erste Idee, um das jetzt schneller zu kriegen,
also man hat dann jetzt irgendwie so eine Python-Implementierung,
und 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
cooler Blogpost oder so, oder? Ein cooles Buch.
Aber halt viel mehr auch nicht.
Und die erste Idee ist quasi,
dass man jetzt sagt,
wir
machen einen Prozess, den man halt
Bootstrapping nennen kann.
Wir nehmen jetzt diesen
Python-Interpreter, der in Python geschrieben ist
und
übersetzen den, also
schreiben einen Compiler, der jetzt diesen Code
nehmen kann und den nach C übersetzen kann.
und das
geht halt nicht für allgemeinen
Python-Code, 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
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 das halt,
weil das 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 nennt keinen Typ einer Variable irgendwie on the fly. Ganz genau.
Das ist glaube ich sogar noch nicht mal ganz so schlimm.
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 da 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 erste 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
geschriebenes, aber
das verhält sich jetzt
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
um mal so eine Größenordnung zu nennen,
Wenn man dann PyPy auf
CPython ausführt, dann hat man halt irgendwie so einen Interpreter,
der vielleicht 2000 Mal langsamer ist als
CPython. Also dann ist es 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 2000 Mal langsamer? Nee, nur 2 Mal langsamer.
Also, Faktor 1000
kriegt man wieder, aber
ein 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 jetzt, wo
kommt eigentlich wirklich die Speed her?
Und da wird es halt dann so ein bisschen
akademisch, also
das ist quasi
der Forschungsanteil.
also ich habe da meine Doktorarbeit
drüber geschrieben, das ist quasi wirklich
so ein bisschen
ein, ja, also war wirklich
so ein 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.
Die dürfen ja auch falsch sein.
also vergessen wir die erstmal
also das Problem ist, wenn man einfach Python-Code
anschaut, dann kann man
den halt nicht unbedingt
jetzt kompilieren
wenn man halt eine Funktion hat, die A und B als
Argumente nimmt und die Funktion macht irgendwie
return A mal 2
plus B, dann
kann man halt diese Funktion nicht
nach Machine-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 Ads Methode
hat und eine unterstrich unterstrich Mull 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 vermittelt.
Und das kann man aber halt quasi nicht ohne
weiteres statisch machen. Also
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-Home-Compiler eben
funktioniert ist, weil der einen
ganz krassen Informationsvorteil hat.
Der Just-In-Home-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 einen
durch eine Maschinen
Instruktion
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 2ins
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 ändernden Situationen
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
Time Compilers, 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.
Da 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
der Brauch der nicht. Aber wenn man den Debugger
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 Maschinencode übersetzen können.
Und deswegen ist JavaScript halt inzwischen
jetzt,
sag ich mal, nicht ganz so schnell wie C, aber halt
irgendwie vielleicht nur zwei oder dreimal langsamer
als C. Und einfach weil
da halt einfach viele
Millionen Dollar in 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
anfingen nicht ganz so
sehr so. Es gab halt damals
ich weiß nicht, sagt euch Psycho
was? Ja.
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,
er hat dieses Extension-Modul geschrieben
und das war quasi ein
Dit 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 war halt auch
hat 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 dazu kam
musste der Armin
Armin Rego heißt das
musste dieses Excel-Modul halt wieder
im Wesentlichen
jetzt nicht von Null schreiben, aber halt
quasi jede Zeile
nochmal neu überdenken, weil das halt
quasi immer so Interaktionen zwischen den
neuen Sprachvierteln und den alten Sprachvierteln gibt
und die waren halt nicht zu übersehen
also da, ich weiß nicht, was kam
mit 2.3 dazu?
Vielleicht Generatoren oder so?
Gab es da nicht auch irgendwie
Glaubwink-Änderungen?
weil es eher kann sein, ich weiß es nicht
genau, aber
auf jeden Fall, die haben
halt immer nicht funktioniert in Psycho
und Armin hat halt irgendwann auch aufgegeben
also Psycho ist glaube ich seit 2004
oder 2005 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
relativ gewagte
akademische Idee ausgesucht,
die er gerne auf PyPy
anwenden wollte. Und das ist eben
die Idee, dass man den JIT
also JIT heißt, das ist die Abkürzung
Justin Time Cobiler, dass man den überhaupt
nicht von Hand schreibt.
Eben weil Python
eine Sprache ist, die sich ständig ändert.
Also einmal im Jahr oder vielleicht damals
alle anderthalb Jahre kommt eine neue Python-Version raus
da gibt es neue Sprachfeature
und das Anpassen des Dirt-Compilers an die neuen Sprachfeatures
das ist zu nervig
Insbesondere wenn man halt nicht
Google-Geld hat
Wenn man Google-Geld hat, dann kann man halt einfach 20 Ingenieure
auf das Problem einhalten
und die haben dann halt keinen Spaß, die schreiben ganz ganz
viel kompliziertes 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's
halt irgendwie
ich glaube in den Ende der 70er gab's 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 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... 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 die Dramatik.
Aber die
Idee von der Moira-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
einmal richtig.
Also wir machen das jetzt halt
also
da hat sich in gewisser Weise auch sehr viel
getraut. Er hat gesagt, ich habe jetzt diese Vision,
das müsste doch irgendwie gehen
und wir wollen das jetzt für eine echte Sprache halt auch
wirklich dann mal anwenden
und in gewisser Weise ist das Problem natürlich auch noch
erstmal schwieriger, weil er halt nicht nur einen Compiler
wollte, er wollte halt einen JIT Compiler
und
er hatte da so ein paar Ideen, wie man
diese alte Idee
der
Futamora Projektion, wie man die halt wirklich dann mal
so ganz konkret, nicht für irgendeine akademische
Minisprache, sondern für so eine richtige
Programmiersprache
wie Python halt dann auch anwenden kann
und das haben wir dann halt
in den
verschiedenen PyPy Research Projekten
auch dann gemacht. Das ging auch
ganz schön lange nicht. Also es hat halt
wirklich dann auch ein paar
Jahre gedauert, bis es dann wirklich auch funktioniert hat.
Also PyPy ist ein Compiler-Compiler?
Also PyPy hat
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 kriegt quasi
die, 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 man
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-Python einen Interpreter
schreiben kann. Das geht ja dann wahrscheinlich für
viele Sprachen. Ja, zum Beispiel, wir hatten da schon
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, der ist ü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 Maschinencode
ü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 Wäschearbeit.
Und die sind jetzt alle
nicht so cool.
Da wurde halt einfach nicht der Aufwand
reingesteckt, den man betreiben müsste, um
da jetzt wirklich,
sag ich mal, eine Production
Ruby-Implementierung dann rauszukriegen.
Aber das
war halt eher so 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 Python geschrieben.
Und damit kann man halt dann auch
ganz interessante Performance-Gewinne
sich dann irgendwie abholen.
Ja, die Datenbank muss das ja auch
interpretieren, was da anfällig zu kommen ist
Genau, und das ist ja auch
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
Das heißt, es ist auch noch eine dynamische
Sprache, eine dynamisch typisierte Programmiersprache
Also da gibt es halt dann schon ganz schön viele Ähnlichkeiten
zu
Ausführungen von Python, in gewisser Weise
Naja, auf jeden Fall, diese Idee
dass wir halt quasi einen JIT-Generator
haben und
diese Architektur
sorgt dafür, dass wir halt
mit einem relativ kleinen Team
halt mit C-Python
trotzdem ganz gut mithalten können.
Weil wir die Features halt eben nicht
in den JIT-Compiler
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 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 vier verschiedenen Stellen auch immer mal machen.
Also zum Beispiel, ich würde jetzt meine Hand
nicht ins Feuer legen, dass Pattern Matching halt
jetzt schon ultra schnell ist.
Also wir haben halt ein JIT für Pattern Matching,
aber ich weiß noch nicht, ich habe es noch nicht gemessen,
ob es wirklich ein ganz toller JIT ist.
Das ist eh ziemlich langsam.
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ß nicht.
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 halt 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 Ja weil du doch dem Generator sagst was er tun soll der den C generiert der dann hinterher ausgef 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,
und sagt, oh okay, diese Schleife hier, die scheint irgendwie wichtig zu sein und dann nehmen wir wirklich diese Schleife und erzeugen daraus halt wirklich direkt ins RAM Maschinencode-Instruktionen.
Und das geht halt nicht mehr den Umweg über C. Den Umweg über C brauchen wir nur, um einmal das Binary zu erzeugen.
Das machen halt wir einmal auf unserem Server und das passiert aber dann quasi nach dem Deployment auf die Produktivumgebung nicht mehr,
sondern da wird halt wirklich direkt
ins RAM, werden halt die Maschineninstruktionen
für die
aktuelle CPU-Architektur
emitted und dann führen wir das
halt direkt raus.
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
Instruktionen rein und dann wird
als ausführbar markiert
und dann springen wir einfach hin.
Und dann von da an läuft
halt wirklich der Maschinencode 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 und der Overhead,
also man hat halt
die Frame-Objekte nicht mehr, man hat die ganzen
Typ-Überprüfungen nicht mehr, idealerweise.
also Python allociert ja auch die ganze Zeit Speicher
also jeder
Integer ist ja
so ein bisschen Heap Memory
also jede Addition
macht halt einen Malloc-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
einen Malloc-Aufruf, also eine Memory-Aggregation
ist ein C, eine Funktion, die
auf dem Heap. Was macht das?
Vielleicht nochmal ganz kurz.
Ganz die freien Hektien, was die versteckt.
Vielleicht kann man das einfach nochmal so ein bisschen
den Kontrast herstellen mit
wir schreiben jetzt wirklich ein Programm in C.
Und wenn du da halt irgendwie eine Integer-Variable
also long A und long B
hast und dann machst du A plus B,
dann sind A
und B halt nicht
auf dem Heap, sondern irgendwie direkt in
CPU-Registern.
Und die werden dann direkt von CPU-
Instruktionen addiert.
und mit dem Ergebnis wird halt irgendwas gemacht.
Wenn du
so einen Ausdruck A und B
in Python hinschreibst und das
in C-Python ausführst,
dann ist das halt nicht, also die
Integer-Werte, die sind dann nicht in CPU-Registern,
sondern die sind quasi im RAM.
Und um dann wirklich
das Ergebnis berechnen zu können, musst du die
Werte erstmal aus dem RAM,
also erstmal musst du gucken,
sind das überhaupt Integers, die ich da addiere.
Und dann musst du gucken,
dann musst du quasi die Werte der Integer aus dem Integer-Objekt vom RAM in CPU-Register laden
dann machst du wirklich die Addition
dann musst du gucken, ob das Ergebnis immer noch klein genug ist, um in einen Maschinen-Wort reinzupassen
das könnte ja auch irgendwie ein Overflow geben, dann brauchst du irgendwie ein kompliziertes Objekt
und dann brauchst du Speicher für das Ergebnis-Objekt, weil das Ergebnis ist ja auch wieder ein Integer-Objekt
das heißt, du rufst einmal mal log auf
dann kriegst du ein neues Stück
RAM zugewiesen von dem
in C geschriebenen Allokator
und dann
packst du den Ergebnis
Zahlenwert in dieses neue Stück
RAM rein, erhöhst den Reference Count
von diesem Stück RAM
und das ist dann dein Ergebnisobjekt
und das passiert aber halt bei
jeder arithmetischen Operation und deswegen ist
halt Arithmetik
und wir haben auch noch so ein paar Schritte weggelassen
deswegen ist Arithmetik halt
in Python klassischerweise wirklich
sehr, sehr ineffizient.
Weil du halt wirklich ständig
Melloc 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
arithmetischer Ausdruck
schon in der Zeit, dann hast du
halt das Zwischenergebnis A mal 2.
Das brauchst du ja gar nicht lang.
Das brauchst du ja
quasi nur...
Das verfällt ja beim nächsten Aufruf.
Das heißt, beim nächsten Aufruf, wenn du dann
wenn du dann das Plus rechnest, dann
verringerst du den
Reference Count von dem Zwischenergebnis
und dann sagst du, oh, das ist ja
jetzt Null, das brauch ich ja gar nicht mehr
und dann rufst du Free auf, das ist
wieder quasi so ein teurer Aufruf
zu dem
Memory-Subsystem.
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 da braucht. Aber der schreibt dann nicht vorher irgendwie
was rein.
Doch, der muss sich
schon irgendwie merken, dass der Speicher jetzt verwendet
werden kann. Also es gibt halt so ein bisschen
es gibt quasi so ein bisschen
Overhead-Datenstrukturen, die
verwendet werden, um
sich zu merken, dass das
jetzt ein Stück freier Speicher ist.
Am Anfang von einem Speicherblock schreibt der irgendwie so
Das ist
glaube ich gar nicht so wichtig. Das funktioniert auch sehr
unterschiedlich, je nach Betriebsthemen und
je nach
verwendetem Allokator.
Also da gibt es halt auch verschiedene
C-Bibliotheken, die man da verwenden kann.
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
Speicheralluzieren ist halt eine relativ
komplexe, weil man halt auch das Betriebssystem in den Kernel fragen muss letztlich.
Am Schluss, ja nicht jedes Mal, aber irgendwann schon letztlich und dann
das natürlich alles sauteuer ist. Und dieser ganze Overhead fällt halt weg,
wenn du A plus B mal C mit ins ausführst und der
und
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 Arbeit,
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 selten genutzt
tatsächlich. Ja, jetzt nicht selten,
aber halt nicht immer.
Also ich glaube halt,
jedes Programm ist schon an irgendeiner Stelle dynamisch,
aber nicht die ganze Zeit.
Es ist zum Beispiel
relativ oft so, dass man beim Importen
halt ganz viel Zeug macht, aber
danach nicht mehr. Das ist so ein
Muster an Dynamigkeit.
Also du importierst halt eine Bibliothek, beim Importieren macht sie ganz merkwürdige Sachen und macht halt so ein bisschen Metaprogrammierung und schreibt irgendwelche Sachen in das Globals Dictionary mit einem Globals Aufruf oder sowas, schreibt es da rein, aber dann ist fertig.
und danach ist alles quasi
harmloser
Python-Code, wo die Typen relativ fix sind.
Also das ist so
eine Sache, die wir immer wieder sehen.
Da gibt es auch Aufsätze 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
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 denn aber? Debuggen, weil
wenn es zu unterschiedlich ist, dann kann man
nicht mehr debuggen.
Man möchte es ja dann machen können,
wenn es eigentlich normal läuft.
Und selbst wenn es jetzt nicht um den Debugger geht, also selbst
sowas wie schöne Tracebacks, die
halt auch noch die Locals rausschreiben oder so.
Wenn halt dein Web-Server
dann wirklich crasht, dann willst du diese
Informationen halt haben.
Und dann zu sagen, ja, ups,
jetzt haben wir das aber so doll optimiert,
dass wir wissen halt gar nicht mehr, was die
Locals sind.
also das kann dir halt passieren in so einem Compiler
also in T gibt es das ja immer mal
da musst du ja wirklich sagen, will ich jetzt
die VG-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 drin steht
und
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 Information braucht.
So, jetzt haben wir glaube ich so ein bisschen alle Ideen.
Also historisch gesehen
Python, Python, Python
also historisch
gab es diese Verständigkeitsidee, die verschwindet
ein bisschen.
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
diese andere Idee dazu, wir wollen einen
Justin-Helm-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
Justin-Tab-Compiler und das hat geklappt.
Also das hätte auch schief gehen können, aber die Kernidee
funktioniert ganz gut. Und jetzt sind wir quasi
so ein bisschen auf dem Plateau der Produktivität, dass die ganze Kerntechnologie
den JIT-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 R-Python, hat das
Type Annotations zum Beispiel auch?
Ja, 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 sehr, leider
auch sehr, sehr wenig
Motivation, das zu ändern, weil
wir haben halt leider sowas wie
eine halbe Million Zeilen
Code in diesem
blöden Python 2 Dialekt
und wir könnten uns jetzt
hinsetzen und einfach
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.
Aber das ist natürlich trotzdem in gewisser
Weise auch kein Zustand, weil irgendwie
also
man will halt auch
letztlich dann irgendwie auch nicht komplett abgehängt
werden.
Das wird dann wahrscheinlich irgendwann auch ein Problem,
da neue Leute
ranzuführen, weil man denen dann ja
irgendwie...
Das hast du jetzt schon vergessen.
in das Github.
Aber das Print hat keine Klammern.
So genau.
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, 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
jetzt wirklich von den Python 3
Features so mega motiviert wären.
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
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
so ein riesen Refactoring-Projekt
zu starten. Also 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. Also ja, 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
oder... Ich meine, es gibt ja da so
automatische Geschichten. Könnte man das nicht
eventuell auch automatisch irgendwie...
Also, aber...
Ob man da halt einfach einmal so
zwei 2-to-3 draufschmeißt...
Ja, wir müssen halt einfach...
Irgendwann müssen wir das mal gucken und wir haben
noch nicht so ganz...
Wir haben noch nicht so ganz den pragmatischen
Weg gefunden, den man halt gehen kann.
Weil es ist halt auch so die Frage,
macht man dann einmal einen Cut und sagt,
Leute, halt,
niemand macht mir neue Features für sechs Monate.
Das ist halt auch doof.
Also,
ja, aber wir sind ja auch nicht
die Einzigen. 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 zehn 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, macht doch bitte mal.
Dann ist sowas halt auch wieder...
Also ihr könnt hier schreien.
Ja.
Ja, ja.
Also,
das ist,
bei Django-Projekten gibt es so etwas ähnliches mit dem
Admin,
mit dem
Django-Admin, das ist halt auch so ein Ding,
das ist, Django-Projekte sind ja auch alt, 15 Jahre
oder so, 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ürde. Würde wahrscheinlich so eine Million
kosten und tja, die haben wir halt nicht.
So ist es halt ein bisschen auch.
Und ich meine, das sieht man ja auch wirklich
ganz konkret bei C-Präsen. Also C-Präsen
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
Bonus wäre,
ist schon zu negativ, aber alles, was
eine ganz tiefgreifende Veränderung
bräuchte.
Das kriegen wir halt
mit dem jetzigen Fundingstand
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 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.
Und dann
danach hatten wir halt viel so
immer wieder
Funding auch von Firmen, die halt dann bestimmte
Features gern 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.
Ich meine, selbst für
Projekte, die halt sehr viel
genutzt werden, also sowas wie Pandas, mich wundert das immer,
es gibt ja ganz viele,
wo die Basis für
für viel Menge.
Ja, ja, und NumPy.
Genau, das ist die Basis für Milliarden
Umsä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
PyPy-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 so richtig?
Nee, keine Ahnung. Also das 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 kümmert.
Achso, genau.
Ja, also
bei NumPy passiert
es langsam eben schon. Also sowas wie Jupyter hat
halt auch Funding und da gibt's
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.
Da würde das ganze Internet an so einem kleinen Faden aufhängen.
Ja, 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 die,
ich glaube es ist ja...
Man muss halt Projektanträge schreiben.
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.
Also bei PyPy kann man halt nicht sagen,
dass es 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 C-Python und ich glaube schon,
dass jetzt unser Wert halt jetzt
auch, selbst wenn man das nicht
einsetzt, es ist halt nicht null, da haben wir ja 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
und wenn wir die hätten, dann könnten wir ganz tolle Sachen machen.
Auf jeden Fall, ich habe eine ganz lange Liste.
Also schickt das gerne zu mir, aber wenn man dann so einen Antrag schreibt,
ist mir halt nicht so klar, ob man sagen kann, wir sind so wichtig wie OpenSSL.
Sind wir halt nicht, offensichtlich nicht.
Aber das viel grundlegende Problem ist halt, wir haben im Moment keinen, der da Lust drauf hat
oder in dessen Expertise das halt liegt.
und das ist nicht so gut.
Und es kann schon sein, dass ich da auch
vielleicht irgendwann dann auch nochmal drin besser werden muss.
Wenn ihr Lust drauf habt,
dann sagt Bescheid.
Wir nehmen gerne
Freiwillige an.
Ich finde zum Beispiel Read the Logs auch ein sehr interessanter 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
ReadTheDocs-Gründer halt auch so ein bisschen
über seine Philosophie von
Software-Funding redet.
Und ja, ich finde das auch
einen ganz coolen
Weg eigentlich, also weil
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 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.
Naja.
und
ein großartiges Beispiel.
Ansonsten ist es halt so,
ich habe jetzt halt,
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,
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. Ich bin da so ein bisschen der Einzige,
der ganz konkret was mit
JetComputer 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 von mache. Insofern passieren
halt durch das Level, was
durch meine halbe Stelle,
das sind jetzt nicht
ultra viele Stunden, aber halt zumindest schon so
ein paar Stunden, die sind halt da und
die werden halt auch
solange, aus meiner Ansicht nach,
da halt es interessante Forschungsfragen gibt,
werden die halt auch für das Projekt auch
weiterverwendet werden.
Und das ist halt so ein Basislevel.
Naja,
das muss man halt auch erstmal haben.
Aber
das reicht halt nicht, um jetzt
das reicht
jetzt nicht, um jetzt halt 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 Wettarbeit betreut
das ist jetzt noch nicht gemerged, aber der hat echt eine
eine sehr interessante
neue Optimierung für den DitCompiler auch geschrieben
wie auch gerade bei Programmen
die viel mit Integer machen, wirklich
nochmal ganz anders Sachen optimieren kann
also echt
ein super Student
Nico Rittinghaus
heißt der, der hat
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
und er hat dann
auch immer recht
das war sehr sehr cool
mit dem, ich hoffe auch, dass er quasi weitermacht
und vielleicht
auch noch eine Masterarbeit schreibt
aber manchmal passieren dann so Sachen
aber
bei so Abschlussarbeiten ist das halt
schon so, dass die Leute dann tendenziell auch wieder weg sind.
Ja, und dann muss man das maintaen, was sie gemacht haben.
Ne, das ist eigentlich okay.
Ja, stimmt.
Die schreiben ja dann auch...
Die schreiben halt Tests und ich bin halt dann schon...
Ich gehe dann 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...
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
damit mit dem Thema durch. Sondern wir sind halt so ein bisschen
in gewisser Weise so ein bisschen ein schlechtes Forschungsprojekt
in dem Sinne, dass wir halt versuchen, 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
aber weil halt so der Output
an Aufsätzen 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
so ein reiner
Akademiker sein wollte
Naja
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
also in der Physik
sieht man das dann häufig
dass dann doch irgendwie so
sich Sachen aufeinandertürmen
die halt man vielleicht dann doch mal
wenn man gewusst hätte
wo man hinterher rauskommt
hätte man das vielleicht anders bauen können
aber
meine absolute Lieblingsgeschichte
die werde ich jetzt hier noch anbringen
Oh ja, sehr gerne. Ich habe tatsächlich
also ursprünglich habe ich mal
Mathe und Physik studiert und dann habe ich das abgebrochen
um bei einem
der PyPy-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
und Jochen unterhalten sich über die Programmiersprache Python
Sprache lernen.
Die Physiker, die müssen ja eh
C++ lernen, um halt schnell einen Code zu schreiben,
aber die wollen ja auch Scripting 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 Skripting,
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 Sinn leer, weil
es ist halt eine Eigenschaft einer Implementierung, ob sie interpretiert ist oder nicht.
Also C-Python ist ein Interpreter, das stimmt, und PyPy ist halt ein
JIT-Compiler, das stimmt. Aber man kann jetzt eben nicht sagen, dass
C++ 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.
Also ich, ja.
Naja, interessant.
Ja
Tja, 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 in Zeit investiert.
Das hat halt am Schluss
nicht so gut geklappt, wie sie sich erhofft hatten.
Was ist das überhaupt?
Also ich bin da sehr schnell
raus.
Ich habe das halt immer so
interessiert verfolgt und die hatten halt dann so ein Branch
und haben da auch jahrelang auch
wirklich sehr viel Aufwand
reingesteckt, aber am Schluss
waren sie halt irgendwie mit den Ergebnissen
nicht so zufrieden und halt auch
also technische Details, wie gesagt,
ist nicht so mein Ding
Was soll das denn theoretisch sein? Also ich habe gar nicht
verstanden, wo es da gehen soll
Also die Idee von Soft Trace Action
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
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 dir gemacht 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
ist dein,
dann sind alle deine 16 Cores
irgendwie busy, aber dein
Programm ist nur zweimal so schnell.
Und das ist quasi so ein
Performance-Bug und
die haben halt einfach,
ich glaube letztlich war das Problem, dass sie
nicht so richtig die Werkzeuge gefunden
haben, um an dieser
Stelle dann weiterzukommen. Du hast halt
diesen Performance-Bug, irgendwo
gibt es einen Konflikt zwischen den Threads, aber
was machst du jetzt als Programmierer?
wenn du halt Performanceprobleme in Python
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 sie 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 6, 7 Jahren
Ja
Und es ist ja jetzt auch ganz interessant
Ich finde es halt interessant, dass es jetzt
diesen
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 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.
und 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
Bias Locking, oder?
Genau, Bias 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
herausgestellt, dass das quasi der richtige ist,
um den Overhead für
Single Threaded Code
klein zu kriegen.
Es gibt auch so ein paar Tricks also ein interessanter Trick ist weil es gibt dann ja deutlich viele Sachen die halt schon in allen Strats verwendet werden also alles was irgendwie globale Geschichten Imports und so Zeug Nun zum Beispiel Ja Nun
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
so ein Workstealing implementieren willst
und du nimmst halt einfach eine Liste,
geht das dann noch?
Oder ist dann zu viel Contention
auf dieser Liste?
Also diese Feinheiten,
wie sich die Performance dann in der Praxis
wirklich verhält.
Was ist ein Workstealing?
Ich glaube, das weiß halt keiner.
Also bei Workstealing ist halt quasi,
du hast verschiedene Arbeitspakete
und verschiedene Threads, die die abarbeiten
und
du koordinierst
diese Threads halt über irgendeine
Queue. Und die Frage ist jetzt,
welche Datenstruktur benutzt du, um diese
Queue
zu
repräsentieren?
Und Work-Sealing ist einer, da hat
jeder Thread seinen eigenen Queue, glaube ich.
Und wenn ein Thread nichts mehr
in seiner eigenen Queue hat, dann klaut er was aus den Queues.
Also ich stelle mir jetzt immer so ein bisschen vor, wie
so eine Bank, wo irgendwelche Leute am Schalter stehen und warten,
bis sie dran können. Und dann sind bestimmte Schalter
halt auf, ein bestimmter Schalter halt nicht und da kann halt
irgendwie sich Leute anstellen an verschiedenen
Schaltern und wenn irgendwie
gerade keine Kunden
mehr sind, dann geht halt jemand drüber.
Aber ich glaube, also wie da
so, ich habe da kein gutes Metall, also
ich bin wirklich ein sehr single
threaded Mensch. Ich kann
das auch nicht, aber
ich habe mein metallisches Modell,
das existiert einfach noch
nicht. Ich weiß halt nicht, was passiert
mit der Performance, wenn man halt
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
dachte, ich kann es theoretisch
und dann praktisch aber feststellen muss ich ganz nicht, weil es ist
wirklich,
es netzt 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
sehen kann, relativ tot, aber
so in der 2.7 ist es ein sehr guter
2.7 Interpreter der halt
Implementierung, der halt
keinen Jail hat, der halt wirklich Multithreading kann.
Das ist auch eine ganz, ganz
das war etwas, was ich jetzt bei dem
Durchführen 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, das viel besser geht mit dem
Fine-Grain-Blocking sozusagen,
dass man gar nicht unbedingt einen Jail braucht,
dass es halt mit einem
Interpreter, der NC 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
JIL mit Filing, Rant, Locking machen und es wird halt nicht langsam
dadurch.
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 Lock schon hat und dann
muss man halt nicht bei jeder Operation
versuchen, sich das Log zu holen, sondern macht das
nur einmal in der
Funktion oder nur an bestimmten Punkten.
Und man macht halt dann nicht
bei jedem Fieldread 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.
Aber Python konnte das halt.
Und da hat sich aber interessanterweise halt dann rausgestellt,
dass es halt
unglaublich viele Bibliotheken gibt in Python
die halt einfach natürlich
überhaupt nicht thread-safe sind
natürlich nicht, weil wie soll denn
die Bugs gefunden werden, wenn halt
die Standard-Invalidierung
halt einfach immer Single-Threaded ist
und
selbst in der Standard-Bibliothek
hat halt Jython
damals quasi einiges an Bugs gefunden
wo es halt Deadlocks
und alles mögliche gab
weil der Code in der
Standardbibliothek von C. Weitem
halt einfach
den Gill 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 übrigens 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 so 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
CLPI, 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
CLPI 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
halt nicht zusammen. Und HPA ist halt die Idee, wir fangen einfach so nicht ganz auf dem Reißfaden, 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 quasi noch in der Mache, es ist irgendwie Version 0,04 raus
oder so, 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
AVI-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
Shared 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 kompilieren 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
C-Bibliothek, ohne dass man die neu
kompilieren muss. Das ist ein anderes, finde ich
sehr interessante Eigenschaft
und 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 HPy-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 Hby
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 GraalPy der GraalPy ist ein guter Freund von mir wir telefonieren dann ab und zu aber ich bin halt sehr hoffnungsvoll dass das bald mal ein Release gibt und vielleicht auch vielleicht in Python Support reingebaut wird das w sehr cool
und das würde eben dazu führen, dass
in Zukunft Extensions,
die H-Py benutzen,
halt auch wirklich schnell auf PyPy sind.
Und dann hätten wir unser,
also da,
es gibt dann ganz, ganz viele Fliegen, die mit einer
Klappe geschlagen würden,
unter anderem eben möglicherweise,
dass es effizient in PyPy ist,
dass es effizient in GraalPy ist,
trotzdem nicht langsamer ist auf C-Python
und
der Übergang zum vorigen
Thema ist jetzt, dass
dass sie gerade auch, soweit ich das verstehen kann,
so ein bisschen anfangen darüber nachzudenken,
ob man denn da auch die Jail-Änderungen, die nötig würden für die C-Extension,
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.
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 das
ich bin mir nicht sicher, ob die das schaffen und
ich weiß auch nicht
also bei so Firmen
Funding durch Firmen, da kann halt auch mal
passieren, dass ein Manager sagt, so
brauchen wir nicht mehr, so genau
aber das wäre halt cool
also das ist ein Projekt, was ich sehr
exciting finde und wo ich hoffe, dass
dass da in diesem Jahr halt noch viel passieren wird.
Wir haben leider
kein
offizielles Buy-in von
C-Python. Also es gibt einige
C-Python-Entwickler, die quasi
sehr wohlwollend sind,
aber wir haben quasi
kein offizielles Endorsement.
Wir sind immer mal ein bisschen am überlegen,
ob es ein sinnvolles PEP
also ich habe jetzt viel gesagt, ich bin
ich als interessierter Beobachter
bin nicht wirklich, also ich schreibe keinen Code dafür,
aber ja, also die HHP-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 T-Python wollen würde.
Weil es ist jetzt,
die wollen halt nicht sagen, die wollen
nicht die Designverantwortung wieder an T-Python
zurückgeben. Also eines der
Vorteile ist eben
gerade, dass es ein externes Team ist, was
das komplett unabhängig von T-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 geschriebenes Peps, ist das ein
reines Informationspapier? Wir arbeiten daran.
Nehmt uns wahr.
Also ja,
da denken wir halt
ein bisschen drüber nach. Also es gibt den
Lukas Langer, der auch
von
Vollzeit an über die PSF
an, teilweise 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 ja.
Aber ich hoffe halt, dass da jetzt in diesem Jahr
halt noch ein paar interessante Sachen passieren.
Naja,
interessant, ja.
Ja, ich meine,
mir sagt das gar nicht so viel, ich weiß nicht,
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, ne?
Jyton, Iron Python,
sind nicht mehr so richtig da.
Unladen Swallow gab es auch.
Ja, das ist lange tot.
Ja, PyPhy
ist so eine der ganz
wenigen überleben.
Also GraalPy halt auch.
GraalPy hat halt wirklich ein Team, die sind auch bezahlt
und 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 das nur
also dass
ihre Warm-Up-Zeit sehr lange
dauert. Also der Code wird halt erst
nach vielen Minuten schnell.
Und das heißt, du brauchst halt
die richtige Art von Anwendung.
Also so 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.
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.
Tim Felgengriff 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
Empfehlung.
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 gerade, wir wollen da,
ich glaube, da steigen wir jetzt nicht ein, aber gerade
ist so ein bisschen die Piper-Idee
nochmal in
mit Geld.
Also halt von Oracle,
deswegen haben die, die haben einen R-Java,
also sie 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
von der Motivation her ist das recht ähnlich
und
die benutzen das, also die haben irgendwie einen schnellen
JavaScript-Implementierung und
ein schnelles Python und
natürlich irgendwie auch ein schnelles Java
und
ja, und das ist
ein riesen Team, das muss man halt auch, also die haben halt
eine
zweistellige Anzahl an Leuten, die halt
an diesem Zeug arbeiten und
ist in gewisser Weise auch
irgendwie
sehr erforschungslastig das Projekt, es ist auch eine
große, also ich würde sagen, es ist von Oracle eine große
Wette, also mir ist
nicht so, also ich glaube im Moment
verdient das Team halt kein Geld
ja, also das ist halt die Hoffnung, dass
das irgendwann mal
dann vielleicht doch Geld verdient, aber ich glaube
im Moment ist das halt wirklich eine Wette
und die läuft auch schon lang, also
das Projekt ist irgendwie 10 Jahre alt oder so
so irgendwie 30 Leute
über 10 Jahre anzustellen, das ist halt
das ist halt richtig teuer
naja, aber also da
weiß ich, also
was da die
Motivationen von so einer Firma sind, das weiß man
halt immer nicht
kann man halt dann
munter spekulieren, das mache ich natürlich auch immer gern
aber ja
also
das ist quasi so ein bisschen
Friendly Competition, aber
mit Betonung auf Friendly
aber nochmal die Frage
warum sowas nicht in Rust geschrieben wird
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 den Compiler zu schreiben Und ich glaube das wei einfach noch keiner Also es gibt genau ein gro JIT
was Rust benutzt.
Das habt ihr auch, glaube ich, in einer Folge
darüber geredet. Das ist 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 Roof-Inflationen
und
das eben, heißt das
YGIT? YGIT 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
ob das wirklich die richtige Sprache
für ein JIT ist und mit der
also die Maxime Chevalier
die das gestartet hat
YGIT bei Shopify
mit der zoome ich auch auf und zu.
Die ist auch extrem gut
und
aber was da
also was da ihre Conclusion wäre,
ist Rust die richtige Sprache, um so einen
JIT-Compiler zu schreiben?
Das weiß ich jetzt. Also das
weiß ich noch nicht. Ich glaube, das weiß man
dann, das kann man erst so ein bisschen
abschließen, beurteilen nach dem dritten JIT
vielleicht.
Also wenn man halt dann Rust nimmt, dann muss man
sich halt klar machen, dass man
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
dann ist man plötzlich für sich selbst
verantwortlich.
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
wäre die Gewinnbringend,
im Compiler.
Weil das, was halt an so einem
JIT-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.
Der darf halt nicht falsch sein. Aber bei diesem Problem
bringt einmal Rust auch nichts.
Ja, weil Rust, dann ist der
Compiler, dann ist der
das Ding,
indem man den JIT-Compiler schreibt, ist dann halt,
das geht halt nicht kaputt. Genau. Beim Interpretieren
deines Interpreters, wenn etwas anderes geschrieben ist,
aber wenn der falschen Code erzeugt, dann ist
er immer noch schlecht. Genau.
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 Python Fyte-Tested
schreiben. Der ist auch deutlich länger.
How is Blitztestet?
Das ist nämlich wirklich auch nochmal
so ein bisschen so ein, das ist ein richtig
und Jochen unterhalten sich über die Programmiersprache Python
und
und Jochen unterhalten sich über die Programmiersprache Python
dass das da ganz viel
Also falls ihr mitmachen wollt, wie gesagt.
Ja, also
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 so 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 keinen Stack-Fault, 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 Datenstruktur 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 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, da ich betreue halt irgendwie
Studenten, die da dann auch
drin arbeiten, als Teil ihrer Arbeiten.
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, 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.
Man weiß halt nicht, man findet halt nichts.
Wo ist man da jetzt gelandet?
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 Tech-Essen?
Da versuche ich dann immer auf jeden Fall
deutlich den Leuten zu helfen.
Und das ist auch was,
was mir wirklich Spaß macht.
Meldet euch und
Ja
Ja, klingt auf jeden Fall sehr gut
Ja, vielen Dank
Wollen wir vielleicht noch Pics machen?
Ich hatte jetzt nur einen kleinen
der gar nichts mit sonst
die Dingen zu tun hat, über die wir gerade
geredet haben
Dann lassen wir es weg
Ja, dann vielen Dank, dass ihr eingeschaltet habt
Ja, sehr interessant diesmal
Danke sehr
Danke für die Einladung
Okay, dann bis zum nächsten Mal
Tschüss, bis dann