Transcript: PyPy - Just in Time

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

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