Transcript: PyPy - Just in Time

Ja, hallo liebe Hörerinnen und Hörer, willkommen bei einem Python-Podcast, Episode 48, heute geht es um PyPy.

Hallo Jochen.

Ja, hallo Dominik.

Hallo Karl.

Herzlich Willkommen.

Hallo Karl.

Ja, wir wollen wie immer erstmal News machen. Was hast du denn da, Jochen?

Oh, oh, oh, jetzt muss ich mal, wir müssen hochscrollen.

Ja, also es gab jetzt ein Python-Enhancement-Proposal tatsächlich, der glaube ich schon, also ich meine das richtig gelesen zu haben,

dass das jetzt schon für Python 3.12

irgendwie ein

Compiler-Flag einführen soll, das den

Global Interpreter-Log optional macht.

Das war so die letzte Woche

große Neuigkeit. Also ich glaube, es gibt zwei große Themen,

Packaging und

irgendwie diesen

PEP 703.

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

Ich bin ja immer so ein bisschen der Ansicht

oder ich habe dir so ein bisschen vertreten, dass

ich das eigentlich nicht so ganz nachvollziehen kann,

warum das so ein Riesenthema ist, weil

ehrlich gesagt betrifft es mich meistens nicht.

ich bin eigentlich bisher kaum je in die Situation

gekommen, dass

dieser Global Interpreter-Log für mich jetzt ein

großes Problem gewesen wäre.

Aber ich habe mir den jetzt nochmal angeguckt und

tatsächlich, also es gibt da schon viele Situationen,

wo einem das halt Ärger machen kann. Also mein

Beispiel war, ich hatte ja mal gefragt, ob jemand ein anderes

Beispiel hatte, also wenn jetzt eine Datenbank in Python

schreiben will, dann könnte einem das Ärger machen.

Und es gibt aber noch viel mehr

Beispiele und da standen auch welche

drin, wo ich dann sagen muss, okay, doch, das hat

schon, da haben Leute schon ein Problem

dann eventuell. Gerade so im

Data-Science-Bereich, das war mir gar nicht klar, also ganz wichtig

ist da wohl, dass man halt

nicht von unterschiedlichen Prozessen aus auf

den GPU-Speicher zugreifen

kann, tatsächlich, so richtig.

Und dann kriegt man natürlich sehr schnell ein Problem,

wenn man da nicht mehrere Sets auf

unterschiedlichen CPUs laufen lassen kann.

Ja, genau.

Ja,

das war so, das ist

ganz interessant gewesen.

Aber ist noch voll auch in Diskussion, oder?

So ein richtiges, so einen klaren

Konsens gibt es da noch nicht, oder? Hast du da einen

Überblick? Ne, genau, also die Diskussion

habe ich mir teilweise angeguckt, aber auch nicht komplett und

ob es jetzt wirklich kommt oder nicht, keine Ahnung.

Es stand auch irgendwann ein Zeitplan

in dem PEP selber drin, der eher so

sagte, ja, also der Plan ist

eher, das ab 2024 einzuführen

und dann 25,

26, dann halt

irgendwann dazu überzugehen,

das halt quasi

3,15.

Ja, ich weiß jetzt gar nicht mehr,

in welcher Relation es war, so 13, 14, 15,

dann irgendwann umzusteigen

auf per Default ist der

Global Interpreter locker aus und dann

irgendwann es zu deprecaten

und dann bis irgendwann 2030 oder so wegfallen

zu lassen, aber das ist dann halt sehr weit in der Zukunft.

Kleine Ahnung.

Und der Plan ist aber erstmal, das quasi hinter einer

Interpreter

Compile-Time-Flag zu verstecken.

Ja, okay, alles klar.

Jetzt haben wir ja direkt am Anfang so was Schwieriges

gemacht. Können wir vielleicht

nochmal ganz kurz erklären, was nochmal ein

Gehör ist?

Ja, soll ich?

Ja, gerne.

Also das Problem ist einfach,

dass der Python-Interpreter selber nicht Thread-safe ist.

Dass quasi die ganzen Datenstrukturen,

die quasi der Interpreter selbst verwendet,

halt nicht mit irgendwelchen Logs versehen sind,

sondern es einfach nur davon ausgegangen wird,

in der Implementierung überall,

dass zu jedem Zeitpunkt halt nur ein Python-Thread,

ein Thread wirklich Python-Code ausführen kann.

Und das führt dazu, dass man halt quasi,

wenn man Python-Code schreibt,

nur von einem Thread aus wirklich gerade ausführen kann.

Und dazu, das hat halt die Auswirkung,

es war lange kein Problem,

weil halt keiner irgendwie ein Multi-Prozessor-System hatte.

Aber jetzt, wo es halt Multi-Core gibt seit 20 Jahren oder so,

ist es halt immer wieder ein großes Diskussionsding,

dass es halt nicht so toll ist,

dass man wirklich Multi-Thread-Algorithmen in Python schreiben kann.

Ist das brauchbar zusammengefasst?

Ja, ja, doch, nee, klingt gut.

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

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

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

Und ja, das war halt immer so, die erste naive Implementation war irgendwie so 40 Mal langsamer als mit Git und dann ist es im Verlauf der Zeit auf 20 Mal langsamer runter oder so. Aber das war halt immer noch nicht wirklich so, dass man das verwenden kann.

Und jetzt die aktuelle Geschichte hat angeblich irgendwie so, wie es dann implementiert werden soll in dem PEP, 10% Kosten in Single-Thread-Performance, was ja so, und es gibt halt schon ein Ding, das kann man auch über PyInf zum Beispiel installieren, ich habe das mal ausprobiert, das nennt sich irgendwie Python Nogil oder so, das macht nur 5% quasi Performance-Einbußen,

Aber das hat auch noch ein paar Sachen da drin,

die jetzt in dem aktuellen Pep nicht drin sind.

Daher wäre das ein bisschen

langsamer. Aber ja, also

10% ist jetzt noch nicht so allzu viel.

Es gibt auch noch so ein paar andere Sachen, wie zum Beispiel,

man muss jetzt halt da, es gibt dann so

ein paar Tricks, die da verwendet werden.

Und einer ist halt auch,

dass es jetzt halt immer

einen Pointer auf den Thread gibt, in jedem

Python-Objekt,

der das erzeugt hat, weil man

der Garbage Collector zwar nur innerhalb der

von einem Thread erzeugten Sachen aufräumt,

oder Reference-Counting macht und dann muss man

das halt vielleicht nicht mehr locken, aber dann muss man halt

sich merken, welcher Thread das war und das sind halt

ein 64-Bit-Ding und dann

hat man noch so einen

Pointer auf, das ist gar nicht mehr genau,

das sind insgesamt drei Pointer, die jedes Objekt mehr

kriegt, drei 64-Bit-Pointer und das ist natürlich schon

irgendwie, das sind halt 24 Byte

mehr pro Objekt,

das ist schon nicht so ohne, also speichermäßig

ist es auch ganz schön und

ja,

ja, so

Es sind halt nur Trade-Offs.

Wenn man es gebrauchen kann, ist es vielleicht gut, aber

wenn man es halt irgendwie nicht braucht,

dann kann es auch sehr nervig sein.

Ja, und deswegen

und die C,

dieses Application

Binary Interface

ist halt auch nicht mehr kompatibel,

sodass halt man im Grunde

halt die C-Extensions,

also für jedes

Paket, das halt eine

C-Extension ist,

muss man halt die entsprechend richtige

Version installieren für den Infrared-Richter, den man

verwendet. Also man muss quasi jede C-Extensions

einmal anfassen und halt zum Teil die

C-API

Usage irgendwie dann

korrekt machen und die Logs einführen,

wenn das nicht Thread-Safe ist.

Also das ist halt möglicherweise schon auch Aufwand.

Ja, ja.

Also wenn man, okay, also das wird dann tatsächlich ein

Breaking-Change sein, dann, wenn die C-Extensions

dann nicht mehr gehen.

Das ist dann eigentlich Python 4?

Nee, also sag mal so, du kannst es ja parallel

verwenden, also wenn du das nicht benutzen willst.

Wenn der Default sich ändert.

Ja, aber das ist dann irgendwann, das ist in der weiten

Zukunft, also das ist halt noch Jahre heran.

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

Ja gut, ich meine,

wenn niemand bis dahin umgestellt hat und es keine

Pakete gibt, dann wird man das wahrscheinlich einfach nicht machen.

Wenn es alle schon machen, alle relevanten,

dann ist es halt auch nicht mehr so schlimm, wenn man das deprecated

also, ja, keine Ahnung,

ist wahrscheinlich jetzt sehr schwer, da irgendwelche Voraussagen zu

machen. Aber, ja.

Ich glaube, wir müssen nachher einfach, aber auf jeden Fall

uns merken, dass wir noch ein bisschen über C-Extensions

reden müssen. Oh ja, ich glaube, das werden wir.

Wer war denn

da bei Facebook noch mal mit dabei? War das Sam Gross?

Sam Gross, genau.

Du hattest vielleicht den Vortrag auf der Eurofight

letztes Jahr gesehen. Ja, ja.

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

Okay, ja.

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

der, der, der, also einige der Ideen

sind auch schon, also diese Geschichte mit den

drei Pointern, die es jetzt gibt, es gab ein akademisches

Paper dazu, wie man das denn bauen kann

und da wurden die, diese

Informationen, die darin stecken, in einen Pointer

reingefriemelt irgendwie,

reinkodiert und das war den Leuten

aber dann jetzt zu heiß und dann haben sie gesagt,

nee, wir nehmen lieber drei, das ist zu gefährlich,

was können da alles für Overflows passieren?

Und also daran sieht man

schon, dass es halt, dass sie sich das nicht getraut haben,

das einfach so zu übernehmen, es ist kompliziert.

Würdest du das Paper bitte auch verlinken?

Das klingt eigentlich spannend. Ja, kann ich machen.

Mach auch den Talk von

der Europython rein, wenn es den irgendwo schon gibt.

Ich füge das mal hinzu.

Alles klar.

Er hat das nämlich genau erklärt, wie er das so vorhat.

Und das war schon...

Er hat einige clevere Ideen dabei gehabt, fand ich.

Auch ein spannender Typ, ja.

Ja.

Okay.

Habt ihr noch nichts? Du hast gesagt Packaging.

Ja, Packaging.

Das war ein anderes großes Thema.

Auch vor zwei Wochen oder so gestartet.

Oder noch ein bisschen länger.

Und das kann ich halt immer noch so versichern.

Es gibt einen sehr, sehr langen Thread.

ich weiß gar nicht genau, wo war das

denn? Das Ding heißt

irgendwie Python Packaging Strategy Discussion

Teil 1, das ist auf DiscussPython.org.

Ah, okay. Ja, und

habe ich nicht ganz gelesen, das war mir dann zu viel,

aber es gab, dann haben

auch diverse Leute da längere

Blogposts darüber geschrieben, was sie denn so denken.

Also ja, das Problem ist natürlich

irgendwie bei allen Umfragen, die man zum Thema

Python macht, dann wird

das von Leuten, die da nicht so

erfahren sind, immer als Painpoint Nummer 1

beschrieben, dass es halt so kompliziert ist

und dass man nicht weiß, was man denn jetzt

nehmen soll für welche Tools und

wie man die dann jetzt am besten, wie rum man die hält

und dann wird es nicht irgendwie

keine furchtbaren Sachen passieren und

ja, das ist ein Problem und

aber es gibt auch keine so richtig einfache

Lösung

und ich weiß es nicht so genau. Ich glaube, das Fazit

war mehr so, ja, es liegt halt vor allen Dingen

daran, dass halt auch Python einfach sehr alt ist und Leute

das auf sehr unterschiedliche Art verwenden und man

kann es nicht gut lösen, weil

man kann nicht allen gerecht werden,

weil manche Leute brauchen halt sehr feingranulare

Geschichten und andere lieber

ein eigenes Interface und das kann man,

ja, wie will man das unter einen Hut bringen?

Das ist schwierig. Also auch interessant,

fand ich genau, ich weiß nicht, ob das in dem Zusammenhang

aufgetaucht ist, aber es ist auch erst wenige Wochen alt, von

Nathaniel Smith, ein

neuer Paketsprachler, Posey heißt er,

oder Posey, ich weiß nicht genau, wie man das ausspricht,

der ist das eine, ein Rust-Binary,

die quasi das ganze Zeugs von

Python übernehmen soll, also den Interpreter mit ausliefern

und Pakete bauen und

Dependencies bauen und

deren Grafen bauen und so. Und das

sah, fand ich, relativ interessant aus, weil genau

das auch eines der Pages ist, die allen Leuten, mit denen ich

irgendwas mit Paisen machen will, erstmal

erklären muss, hä, wie geht denn das? Oh, das ist aber kompliziert und warum

ist das denn so? Und ja,

sobald dann halt, also wenn die einen Paisen machen, okay, aber wenn die

nochmal eine andere Paisenversion, irgendwann habe ich es ja später so,

geht alles kaputt und Fahrt anpassen und dies, das

ist für einige Menschen gar nicht so einfach zu handeln.

Ja, und Natalia ist auch jemand, dem man

quasi den Geschmack zutraut, das

richtig gut zu machen. Ja.

Ja, ja, ja, also bekannt

wie, er hat ja Trio

geschrieben, also eine andere Implementation

für so Async-Geschichten

und eine andere

Art, das zu machen. Er hat einen sehr

tollen Artikel geschrieben, irgendwie

für Structured Concurrency,

den verlinke ich auch mal gerne

oder sage Leuten, dass sie sich das mal durchlesen sollen.

Ja, insofern,

ja genau, das habe ich auch da direkt aufhorchen

lassen, als ich gehört habe, wer das gemacht hat.

Ja, auf der

anderen Seite weiß ich jetzt nicht so genau. Also er

schreibt, gut, er macht das jetzt in Rust, weil

er wollte schon immer mal was von Rust machen.

Ich weiß nicht genau, wo man das unbedingt, also alle Leute

machen und haben irgendwie Dinge, Tooling in Rust.

Bei

JavaScript verstehe ich das so ein bisschen, weil

die haben da, also jede Änderung

im Code führt halt dazu, dass irgendwie so 20

Transpiler, irgendwelche

Linter, sonst was irgendwie loslaufen und Dinge machen.

Und

wenn dann jedes Mal so ein fetter Node.js-Prozess

gestartet wird, dann

dauert das, dann addiert sich das natürlich

irgendwie auf in der Latenz. Aber Python

hat man das ja jetzt so eigentlich auch nicht.

Naja, aber immerhin hast du eine vorkompilierte Binary,

die du irgendwie ausliefern kannst. Und in Rust ist das

vielleicht so ein Typensicher und irgendwie ordentlich

schnell. Und ich glaube, man kann

die halt auch relativ leicht dann so statisch

verlinken und hat halt wirklich nur eine

Datei. Ja, genau. Ja, okay.

Ansonsten hat man das Bootstrapping-Problem, dass man erstmal

einen Package-Manager installieren muss, damit man sich

den richtigen Package-Manager, also das Problem

das Poetry hat mit dem

curl und get Poetry

schrecklich Schell-Skript irgendwie von

einer Webseite ausführen. Ja. Ja.

Ja, okay. Gut, das löst es. Das stimmt.

Ja. Das sind so ein paar Sachen,

die glaube ich gar nicht schlecht sind. Also ja, aber Rastor ist cool.

Ich habe es auch mal ein bisschen ausprobiert in Advent of Cody.

Aber

die Weihnachtszeit ist ja jetzt schon wieder vorbei.

Ich weiß nicht, was ich finde.

Also das, was ich meistens

verwende, ist halt für Pakete bauen

Flit. Das macht eigentlich nur das.

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

Und

ja. Pip-Tools fand ich

ja fürchterlich, aber du findest Poetry fürchterlich.

Ich habe Poetry lange verwendet.

Also fürchterlich ist...

Ja, wir hatten uns ja, glaube ich, das war schon ein, zwei

Folgen her, über dieses

Problem mit den Dependencies irgendwie schon

auseinandergesetzt noch.

Warum das vielleicht

blöd ist, aber ich sage mal so, theoretisch kann man

die ja trotzdem einfach dann selber

einstellen in der PyProject-Hummel.

Ja, ja, das

Problem ist, dass Poetry

implizit halt,

wenn man sagt Poetry add irgendein Paket,

irgendwie ein

Upper Bound auf die

Version macht, was

Wenn man eine Library schreibt, wo andere halt sehr blöd

ist, weil die dann sofort in Dependency-Problemen

laufen, Konflikte laufen.

Man muss ja manuell quasi tatsächlich dann

die Funktion wegnennen.

Naja, gut.

Das ist, glaube ich, eine gute Idee.

Ich habe letztens gesehen, PipTools

in PyProject Hummel irgendwie rein

gemeldet.

Letzte Woche war

PyGDF-Treffen und

Jens hat mir das mal

erzählt, dass er das jetzt macht.

Er benutzt PipTools. Ist auch nicht so super

nicht hundertprozentig zufrieden, aber

irgendwie

benutzt man das auch häufiger

und hat einen Weg gefunden, wie man das

relativ einfach, die Abhängigkeiten auch in

der PyProject-Tunnel da reinschreiben

kann und hat mir mal gezeigt, wie man das macht.

Das könnte ich auch verlinken, stimmt.

Ist natürlich auch nicht so schlecht.

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

im Moment ist das ganze Packaging und

Dependency-Management-Zeugs irgendwie relativ

furchtbar. Das funktioniert

auch nicht US-übergreifend gut und

das ist

ziemlich ein Mist. Ich hoffe ja wirklich, dass dieses

RAS-Paket da einiges

ändert, weil das

will man so alles nicht haben.

Ja.

Wird uns noch eine Zeit lang begleiten, das sehen wir, glaube ich.

Ja.

Okay.

Kommen wir zu erfreulicheren Dingen.

Django gibt es jetzt eine neue Alpha-Version, also die

Django 4.2 kommt

im März irgendwann, hoffentlich.

Ist das wieder die LTS?

Ja.

Genau, wobei das nicht so eine

große Rolle spielt. Die offizielle Empfehlung an der Stelle ist

immer, die letzte

Stabile zu nehmen und nicht LTS. LTS

ist mehr so, naja, es gibt halt Firmen, die das irgendwie

haben wollen oder keine Ahnung, aber das ist nicht

mehr so, wie man das machen sollte. Es wird nicht empfohlen,

immer auf den LTS-Version zu bleiben.

Dafür verändert sich auch einfach zu wenig.

Also es gibt schon lange nicht mehr

irgendwie so große Probleme, wenn man upgradet.

Daher braucht man das eigentlich

nicht mehr so wirklich.

Genau, was dabei ist, ist

ganz nett, PsychoPG3

Support, das heißt Async

Datenbank-Unterstützung

kommt damit halt so, rückt näher.

Es gibt ja jetzt auch ein Interface

seit Django 4.1 für

Async-Geschichten mit dem

ORM. Ist alles noch nicht wirklich implementiert,

aber das Interface ist schon mal da, sodass man das halt

so verwenden kann, dass wenn irgendwann sich

unten drunter das mal so verändert, dass halt mehrere

Sachen gleichzeitig irgendwie an die

Datenbank geschickt werden und dann

zurückkommen, dass es einfach so,

dass man einfach so davon profitiert und dass man selber

nochmal was ändern muss. Das muss ich auch mal irgendwann

verstehen, wie das mit der Datenbank funktionieren soll?

Naja, du kannst, also im Grunde

der OEM weiß ja, was er an Queries an die Datenbank

schickt und der schickt dann, also was momentan

so der übliche Weg ist halt, dass

er halt ein

Query nach dem anderen an die Datenbank

schickt und die Latenzen sich alle aufaddieren.

Das ist halt so, wie es, was jetzt,

wenn man nicht so viele Queries macht und

wenn man ein bisschen aufpasst, dann ist es auch nicht so schlimm.

Aber kann natürlich schon sein, wenn man jetzt

50 Queries hat und jede dauert

10 Millisekunden, dann ist man natürlich bei einer halben Sekunde

allein Datenbank-Latenz.

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

schickt oder alle, die nicht voneinander

abhängen, kann man gleichzeitig an die Datenbank schicken

und dann hat man

die Gesamtlatenz, nur die Latenz

von dem Query, was am längsten

dauert sozusagen.

Und das könnte natürlich die

Gesamtlatenz deutlich reduzieren. Also es wäre sehr nett, wenn

das irgendwie ginge.

Aber es ist natürlich eine sehr komplizierte Änderung.

Aber da muss die Datenbank ja natürlich schon parallel auch rechnen können.

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

Und wie stellt die Datenbank

sicher, dass sich jetzt keine

Probleme

hab, festzustellen, dass Dinge auf die

gleichen Stellen zugreifen.

Das ist ja so

die Kernkompetenz eines Datenbankmanagements

Systems sozusagen.

Wie soll das denn gehen?

Das Problem hast du jetzt ja auch schon, wenn du mehrere Frontends hast

oder mehrere Prozesse auf deinem Frontend, die gleichzeitig

alle irgendwie...

Man muss ja gucken, dass sie einen Lock setzt dann irgendwie und dann muss sie

gucken, ist das Lock auch da oder muss halt

eins setzen, wenn sie da irgendwie dran rumfuchtelt und dann

muss sie es wieder... Du meinst jetzt so Richtung

Right zu Griff oder was? Ja. Ja, aber ich meine,

dann schaust du halt eine Transaktion und

siehst, dass dann, hast du eine

konsistente Sicht der Dinge

innerhalb der Transaktion oder die wird halt

dann committed oder aborted und das

ist, also ich glaube, ich stimme

dir zu, dass, Jochen, zu, dass

das halt genau das ist, was die Datenbank halt

im Prinzip richtig gut können sollte.

Also so. Aber das

macht ihr doch eigentlich dann langsamer, oder?

Ja, natürlich macht das alles, das macht alles viel langsamer,

wenn man Transaktionen ausschaltet und F-Sync

ausschaltet, dann wird das, wird eine Datenbank viel schneller.

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

Das ist ja doof.

Das ist auch wieder doof.

Wieder so ein Schritt auf den Haken.

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

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

Die machen ja auch Sachen Concurrent auf Prozessebene oder auf Rechner-Ebene, die da auf die gleiche Datenbank zugreifen.

Also das sollte eine Datenbank schon können?

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

Das heißt, bisher war das kein Problem,

weil man kann sowieso immer nur

im Code synchron

eins nach dem anderen machen. Aber jetzt

kann man ja mehrere, das heißt, man muss auch mehrere

Verbindungen aufmachen, weil

halt immer nur ein Query pro Verbindung

geht. Das heißt, da muss man

dann halt intern poolen

oder muss irgendwie

außen poolen.

Es ist sowieso alles sehr kompliziert. Auch die ganze

Geschichte im OEM, was man dann umstellen muss,

das wird noch lange dauern, bis das alles

richtig funktioniert. Aber wenn es denn mal

irgendwann funktioniert, das ist ja cool.

Und das ist jetzt ein Schritt,

weiterer Schritt dahin. Also wir haben jetzt Async-URM,

Async-Views, Async-Tests.

Ja, ja, Async-URM haben wir

noch nicht. Wir haben nur die Interfaces.

Jetzt auch den Support für eine

Library, die man dafür braucht, um das überhaupt machen zu können.

Das heißt, das letzte, was du nimmst, ist Async-URM.

Genau, das

ist halt auch noch das komplizierteste

Stück Arbeit, was noch da bevorsteht.

Genau.

Dann, es gibt jetzt

Unterstützung für Kommentare,

für Spalten und Tabellen.

Das ist irgendwie ein Issue, der ist seit

Jahren offen und war irgendwie

kompliziert zu fixen, ging nicht so gut. Aus welchen

Gründen auch immer, ich weiß gar nicht genau. Das geht jetzt.

Also wir haben irgendwie den Weg gefunden, wie sie das so

hinkriegen, dass es kein Problem mehr ist.

Und das, was ganz nett ist,

dann

früher, oder ab dann wird man halt

eventuell, es gibt so

Django in Memory Storage, ich weiß

nicht genau, gibt es ein externes

Paket nicht mehr brauchen, das ist dann auch in Django

selber drin. Das heißt, man hat jetzt einen

in Memory-Storage-Backend

für Django mit dabei,

dass man einfach so verwenden kann für Tests zum Beispiel.

Macht halt Tests einfach schneller.

Und, das freut mich

besonders, es gibt jetzt

eine Streaming-HTTP-Response

mit Async-Iteraturen

dran. Das ist im Grunde,

wenn man jetzt

zum Beispiel Files ausliefern will,

ist das halt

ein Problem. Das ging bisher nicht so gut,

einfach deswegen, weil man

da halt über die Blocks

eines Files, die man rausschicken wollte, halt da

so nicht Async drüber iteriert

hat. Und

genau, ich habe da ja mal

auf der Django

2021 einen Vortrag

wie kann man eigentlich Files mit Django

surfen gehalten. Da habe

ich das halt, dieses Ding rausgepatcht

irgendwie so per Monkey-Patching.

Es gibt noch ein Paket, Django-File-Response,

wo ich das so mache. Das ist dann nicht mehr nötig,

weil das macht jetzt Async-Iterator. Das heißt,

es müsste eigentlich Files surfen, müsste jetzt einfach so gehen.

Ja, das ist natürlich auch sehr cool. Wir haben noch ein paar Konferenzen von zweien. Weiß ich jetzt schon die Daten. DjangoCon EU ist irgendwie 29. Mai bis 2. Juni 2023 in Edinburgh. Edinburgh, ich weiß gar nicht, sprechen wir uns auf?

Ja, okay. Tja. Und PyCon.de oder PyData ist in Berlin 17. bis 19. April, da gehe ich wahrscheinlich auch hin.

Euro-Pricen ist vom 17. bis zum 23. Juli.

Okay, ein bisschen später.

Aber ich weiß nicht wo.

Okay.

Das ist noch top secret.

Damit auch ja keiner einen guten Flug buchen kann.

Genau.

Das wird in Europa passieren wahrscheinlich.

Oder das ins Budget fürs Jahr einplanen kann.

Für was auch immer.

Ja.

Ich glaube gerade das Management-Team hat da gewechselt.

Ja.

Ja, also die letzte

hat noch Marc-André mit organisiert

und jetzt machen das irgendwie andere Menschen.

Die haben so eine

neue Art und Weise wollen die machen mit

wer das wie veranstaltet und sich was neues Konzept

da überlegt. Mal gucken, ich bin gespannt.

Jojo.

Okay, ja, nee, dann

das wäre ja nach nur fast

20 Minuten mit den News durch,

das ist mal relativ flott, dann

kommen wir zum Hauptthema.

Eine ganz schnelle Folge. Das glaube ich nicht.

Pai Pai? Ja.

Warum macht man damit nicht was schneller oder was ist der Zweck davon?

Oder weißt du was, womit wir anfangen?

Karl, wer bist du denn eigentlich?

Hi, ich gebe jetzt schon die ganze Zeit so meinen Senf dazu.

Aber ja, also ich bin Karl Friedrich Bolz-Tereik.

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

und habe da eine halbe Stelle und bin im Prinzip angestellt,

um eine Python-Einführung zu halten jedes Semester für Leute,

die nicht Informatik studieren.

Also das ist so Studium Universale mäßig.

Und wenn ich die gemacht habe,

kann ich die restliche Zeit so ein bisschen frei einteilen.

Das ist eigentlich ein ganz angenehmer Deal.

Und ich bin seit irgendwie 2005 ungefähr

einer der Kernentwickler des PiPi-Projekts,

über das wir jetzt auch dann gleich noch mehr reden wollen.

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

Ich war dann auch bei den EU-Projekten,

die da am Anfang eine Zeit lang für Finanzierung gesorgt haben,

recht intensiv involviert.

Und bin halt so mit mal mehr, mal weniger Involvierung

seitdem immer wieder halt dran beteiligt.

Also an dem Open-Source-Funded-Ding,

was dann PiPi direkt entwickelt.

Genau.

Also ich bin jetzt quasi einfach erst mal nur so,

quasi in Anführungszeichen, also nur

einer der Kernentwickler, also die halt quasi

Commit Rights und

Zeug machen. Ich bin aber halt auch

einer der recht Aktiven im Moment.

Also das Projekt

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

Und ich

bin einer derjenigen, die jetzt halt gerade

noch viel, recht viel machen.

Genau, aber

das Projekt hatte über seine Lebenszeit

halt immer wieder auch Phasen, wo das wirklich

auch viel Geld hatte.

Also EU-Förderung, Forschungsförderung, immer mal wieder auch Geld von Firmen.

Und bei einigen von diesen Forschungs- oder Förderungsprojekten war ich halt auch dann quasi aktiv dabei.

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

Ja, genau. Das ist quasi die andere Frage.

Also PyPy ist quasi eine Alternative für CPython.

Wenn man halt irgendwie Python, in Python seine Programme schreibt,

dann geht man halt normalerweise auf python.org

oder vielleicht kriegt man das auch irgendwann das her,

aber man hat halt ein Executable, das heißt Python 3 in der Regel oder Python.

Das führt man aus und dann kriegt man halt irgendwie seine Shell

und kann da Python-Code eingeben oder kann halt damit dann auch Python-Dateien ausführen

und kann auf diese Art und Weise irgendwie seine Programme laufen lassen.

Und dieses Programm, das wird halt von den Kernentwicklern der Sprache Python geschrieben

und das gibt quasi vor, wie sich die Sprache entwickelt.

Und dieses Programm ist in C geschrieben und deswegen kann man das halt auch,

um es von der Sprache zu unterscheiden, kann man das halt auch C-Python nennen.

Also das ist quasi so ein bisschen so ein Terminologie-Trick,

dass man halt quasi die Sprache und die Implementierung,

dass man denen zwei verschiedene Namen gibt.

Also Python ist halt dann die Sprache

und das ist quasi erstmal so eine abstrakte Entität

und dann gibt es aber halt die konkrete Implementierung,

die man fast immer verwendet

und das ist halt CPython.

Und CPython funktioniert jetzt so,

dass es halt ein Interpreter ist.

Also wenn ich jetzt damit

irgendwie meinen Python-Code ausführen will,

dann gibt es so ein bisschen

so einen versteckten Bytecode-Compiler-Schritt.

Also der Python-Code wird dann irgendwie analysiert

und geparst und in so ein Bytecode-Format übersetzt

und dann werden auch so

PYC-Dateien irgendwo

auf der Festplatte auch noch so ein bisschen

zwischengespeichert, damit man das nicht jedes Mal machen muss.

Aber dieser White-Code, der wird halt

dann jedes Mal von einem Interpreter ausgeführt.

Und

was

Piper jetzt ist, ist quasi

der Versuch,

Python-Code schneller zu machen.

Also es ist ja immer

so ein bisschen so ein Meme, dass Python halt irgendwie

besonders langsam sein soll und

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

Und das macht man eben so, dass man eben sich sein Binary nicht von Python.org runterlädt, sondern von PyPy.org. Man kriegt dann ein Binary, das heißt halt irgendwie PyPy. Und das verhält sich erstmal eigentlich ganz genau so, idealerweise quasi ununterscheidbar so, wie der Interpreter, den man von Python.org kriegt.

Vielleicht nochmal ganz kurz, PyPy ist nicht PyPI?

Genau, also P-Y-P-Y. Das ist so ein bisschen doof, dass die so ähnlich sind.

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

Genau, ja, ja, absolut. Aber PyPI lädt man quasi in Python geschriebene Bibliotheken runter, die dann auf der Python-Implementierung laufen, aber PyPi ist eben wirklich das Binary, also die Exit-Datei sozusagen.

Du hast nicht mehr erzählt, eigentlich war diese, weil ihr relativ gleich alt seid als Projekte, war die Unterscheidung früher gar nicht so einfach, weil das andere waren die Cheesecakes?

Genau, also der PyPI hatte halt vorher dieses Cheese-Shop-Branding, weil das ist so ein Monty-Python-Sketch mit dem Cheese-Shop, wo man halt keinen Käse kaufen kann. Ich weiß nicht, ob du das kennst.

Ja.

Genau, da geht halt der Kunde dann so ganz viel Sorten durch und die gibt es aber alle nicht. Und kennst du auch das Wortspiel mit den Wheels?

Nee.

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

Ja.

Und die Wheels sind halt Käse.

Okay, ah.

Also, ja.

Okay.

Ja, okay, verstehe.

Und deswegen gibt es Reels auf

Pipe.pi. Genau, und irgendwann haben die halt

dann aufgehört mit diesem, weil Cheese Shop ist halt

doch sehr

idiosynkratisch oder verspielt.

Ist vielleicht eine positive...

Der erste Draftname für unseren Podcast war

Ministry of Silly Talk. Ah ja, alles klar, nicht schlecht.

Und also

irgendwann wurde halt Pipe.pi dann ein bisschen

ernsthafter und hat halt angefangen, dann

sich nicht mehr das Cheese Shop zu nennen.

Und dann wurde halt die Verwechslungsgefahr plötzlich

dann auch akuter. Aber weil halt

PyPI und PyPi ziemlich

genau gleich alt sind, also PyPI ist ein kleines

bisschen älter, so ein paar Monate oder so,

haben halt beide Projekte

nicht so richtig eingesehen, sich jetzt umzubenennen.

Und deswegen müssen wir

jetzt halt mit dieser

Verwirrung leben. Genau, also wir waren

an dem Punkt, man kann von PyPi.org sich

ein Binary unterladen, das heißt PyPi.exe

oder halt einfach nur PyPi.

Und das verhält sich eigentlich

idealerweise ganz genau so, wie

das Binary, was man von Python.org

kriegt. Man kann damit Python-Code

ausführen, man kann damit

einen interaktiven Interpreter kriegen und

alle Command-Line-Switches

sind die gleichen und verhält sich genau gleich.

Mit dem einzigen Unterschied, dass

der Python-Code, den man

damit ausführt, halt hoffentlich schneller ist.

Was ist mit Paketen und

Libraries und so weiter? Genau, also

alles, was quasi in Python geschrieben ist,

sollte halt gehen.

Wir haben natürlich ab und zu Bugs, also

es gibt immer irgendwelche super

spezifischen Feinheiten,

wo man dann halt doch so ein bisschen

Verhaltensunterschiede finden kann.

Aber so der Anspruch an uns selber ist halt,

dass wir quasi wirklich das komplette

Verhalten der Sprache

eins zu eins

nachbauen und zwar bis in die Bugs rein.

Also es gibt halt immer wieder so

Randfälle, wo man dann anfangen kann zu diskutieren und sagen kann,

naja, was ist denn jetzt mit diesem Randfall?

Könnte man dann nicht argumentieren, dass

C-Python da halt irgendwas komisches macht?

Aber das machen wir halt nicht, sondern wir sagen halt immer

im Zweifelsfall bauen wir halt auch die ganz, ganz

komischen Sachen nach, weil es stellt

sich halt raus, dass

irgendjemand verlässt sich so ein bisschen auf

alles. Also es gibt eigentlich

keinen Randfall, der so

merkwürdig ist, dass es nicht eine Bibliothek gibt,

irgendwie eine kleine vielleicht,

die halt sich dann beschwert, wenn man

das kaputt macht. Also selbst

wenn man halt dann sagt, naja, wir sind aber viel konsistenter

und das macht ja so viel mehr Sinn, nee.

Das ist halt doof. Für so eine Bibliothek ist das doof,

wenn sie halt dann so unterscheiden muss,

auf welcher Python-Implementierung sie jetzt gerade laufen.

Und deswegen versuchen wir da halt auch nichts mehr zu verbessern

oder irgendwie, ja, es gibt natürlich trotzdem Stellen.

Also wir haben halt dann, was weiß ich,

mal eine leicht andere Fehlermeldung in irgendeinem Fall oder so.

So was kommt halt schon vor.

Aber so, also vom Anspruch her sollte sich halt genau gleich verhalten.

Und der einzige Unterschied ist quasi wirklich idealerweise,

dass bei uns die Programme halt viel schneller laufen.

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

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

Also das eine ist halt, wir sind halt nicht die maßgebende Implementierung,

die jetzt die Evolution der Sprache selbst vorgibt.

Also CPython hat halt so eine Doppelfunktion.

Das ist einmal die Default-Implementierung,

die halt von fast allen verwendet wird.

Aber auf der anderen Seite ist es halt auch die Gruppe an Leuten,

die letztlich darüber entscheiden,

in welche Richtung sich die Sprache weiterentwickelt.

Weil in jeder neuen Version von C-Python ist es ja so,

dass da eben nicht nur, jetzt sage ich mal,

irgendwie technische Verbesserungen

an der Implementierung gemacht werden.

Das kommt natürlich auch mal vor.

Also jetzt sind 3F zum Beispiel ganz toll.

Aber insbesondere gibt es halt auch bei jeder Version

irgendwelche neuen Sprachfeatures.

Das heißt, python.org, diese Community,

ist halt für zwei Sachen zuständig. Einmal

dafür, dass das alles funktioniert, aber auf der

anderen Seite eben auch für so Fragen wie

welches PEP nehmen wir an, welches neue

Language-Feature wollen wir haben, welche neue

Standard-Bibliothek,

so Geschichten. Und da,

also da sind wir halt raus. Also aus diesen ganzen

Sprachdesign-Fragen, da haben

wir keine Meinung zu. Ihr nehmt euch dann einfach

das offizielle Release und dann

das darf ein CPython und baut das dann eure

Änderung ein. Ganz genau. Und es ist schon

dann mal so, dass wir bei den CPython-

Diskussionen dann auch mitreden und sagen, ja, aus unserer

Sicht hat das die und die,

also gibt es jetzt hier diese Trade-offs oder so,

aber wir versuchen uns halt

so erstmal aus Sprach

Design-Fragen auch irgendwie erstmal rauszuhalten.

Also einfach auch,

weil das unser Leben so ein bisschen leichter macht, dann

gibt es halt, ich meine, ich habe da

natürlich dann quasi so privat auch manchmal eine

Meinung dazu, was es jetzt an Featuren gibt und

manche finde ich cool und manche finde ich

weniger cool. Also ich meine, das geht ja allen

Python-Programmierern so, dass man halt

eine Meinung hat, aber wenn ich dann quasi

meinen Pai-Pai-Hut aufhabe,

dann versuche ich diese private Meinung

halt dann auch zurückzunehmen und zu sagen,

das ist jetzt halt so, das ist Teil der Sprache und das

implementieren wir jetzt halt. Also du bist ja eigentlich gar kein

Dein-Python-Programmierer, hast du selber gesagt.

Ja, über die Architektur reden wir gleich noch.

Also irgendwie dann schon,

aber halt auf ein bisschen indirekte Art und Weise.

Also ja,

ich wollte noch was zu den Versionen sagen. Wir sind

immer so ein bisschen hinterher.

Das ist nicht so gut. Also eigentlich

haben wir so ein bisschen den Anspruch, dass wir

quasi eine Major-Version hinterher sind.

weil, also

wir können halt nicht Schritt halten

C-Python hat halt einfach viel mehr Leute

und die

die rennen uns halt davon

und was halt so ein bisschen unser Ziel ist, ist, dass

wir quasi immer so eine

Major-Version hinterher sind, das ist auch

immer ganz gut, wenn dann quasi

3.11 rauskommt, dann haben so

langsam alle Bibliotheken sich drauf eingestellt

dass sie 3.10 supporten und wenn

wir dann auch mit unseren 3.10 rauskommen, dann passt das

so ganz gut zusammen

Gerade sind wir ein bisschen

mehr, also wir haben jetzt nicht so krass getaktete

Releases wie C-Python, sondern

das wird halt

wir machen alle paar Monate Release, aber das heißt nicht

unbedingt, dass dann auch die neue C-Python

Version

supported wird

und gerade sind wir so ein bisschen hinterher

3.9 ist jetzt eigentlich sehr sehr stabil

und 3.10

ist in der Mache, aber noch nicht released

und danach kommt halt dann

3.11, also das ist ein quasi

ein Nachteil, warum man Piper halt nicht

nehmen sollte,

ist ein bisschen hinterher.

Und dann habe ich vorhin gesagt,

naja, jedes Python-Programm sollte halt gehen

und idealerweise schneller sein.

Da gibt es jetzt zwei Fußnoten an dieser

Aussage. Die eine Fußnote ist halt

C-Extensions.

Und NumPy ist kaputt?

Nee, kaputt halt nicht. Also inzwischen ist das

so, dass wir so eine komplette

Kompatibilitätsschicht haben,

mit der, sag ich mal,

80% aller

in C-geschriebenen Bibliotheken

in Piper auch gehen.

Aber, das ist wirklich,

wir emulieren halt dieses Interface.

Für C-Python ist das Interface halt wirklich

genau so, wie der Interpreter

auch wirklich funktioniert.

Und der Interpreter benutzt halt Reference-Counting

und die C-API,

die hat halt

überall die Tatsache, dass das Reference-Counting

ist exposed. Es gibt halt

ein Increase-Reference-Count-Makro

und ein Decrease-Reference-Count-Makro

und alle Libraries, die dann

gegen diese API implementiert sind,

die müssen das halt überall auch korrekt verwenden.

Aber bei uns ist es so, dass wir unseren

Speicher halt nicht mit Reference Counting verwalten.

Das heißt, wir müssen dann für

die Bibliotheken so tun, als hätten wir

einen Reference Count. Und das ist halt,

das kostet halt so ein bisschen Performance. Das heißt, bei uns

sind in C geschriebener Erweiterung

halt quasi, die funktionieren,

die können aber halt oft

einfach langsamer sein.

Und das ist natürlich doof, weil

Ein Massenpaket, das schneller sein will,

aber die Sachen sind langsamer, als wenn du die eigentlich auf normalem

Python-Offenheitsmittel hast. Genau, ja, ja. Also ich meine,

der Grund, warum man, es gibt ja so ein bisschen

zwei Motivationen, warum man in C geschrieben die Bibliotheken

verwendet. Einmal, weil man halt gerne mit

irgendwelchen Bibliotheken geschrieben

reden will, die halt in C geschrieben sind.

Das ist halt ein Ansatz. Aber ein anderer

Grund ist halt, wenn man irgendwas schneller machen will,

indem man es in C schreibt. Und diese

Motivation, die funktioniert halt dann

auf PyPy oft nicht. Und das

wäre dann zum Teil einfach auch echt besser, wenn man

halt einfach Python-Code nehmen würde,

aber weil halt für C-Python alle

jetzt schon ihre tollen NC-geschriebenen Optimierungen

gemacht haben, ist das dann für uns

oft auch halt eine Verschlechterung.

Also, ja.

Könnte man da nicht vielleicht einfach auch

den C aus PyPy heraus

irgendwie einfach den C-Python-Interpreter

wieder aufrufen und den diesen

Kram händeln lassen? Ja,

da gab es auch immer mal wieder so ein paar Experimente,

aber dann verliert man halt, also man

will halt, dann verliert

man halt möglicherweise die Vorteile für den Python-Code,

wieder. Also, weil das Problem ist, du willst ja

halt beide Seiten auch miteinander reden lassen. Ja, wenn du

halt nur C-Code hast, dann

ist halt eh die Frage, warum du eigentlich, was

hast du da noch mit Python zu tun?

Spannend wird es halt dann, wenn du quasi Python,

also wenn dein Programm halt wirklich aus

interessanten Teilen auf der Python-Seite

besteht und interessanten Teilen auf der

Bibliotheksseite.

Die andere Fußnote ist, dass es manchmal nicht

klappt. Also es gibt halt,

manchmal hat man wirklich in Python geschrieben

Code und

der wird nicht schneller.

Also man muss halt einfach

messen. Um mal so ein bisschen

so eine Größenordnung zu nennen,

wir haben halt so Speedups

zwischen, so im allerbesten

Fall, wenn halt alles ganz toll ist

und du Pure Python Code hast, gar keine Bibliothek

in C geschrieben ist und das

ist alles jetzt, sag ich mal, sehr numerisch. Also hast

viele Zahlen

und irgendwie viele Floats oder, aber du machst

das auch wirklich alles in Python. Dann kannst du halt so

Speedups von 50 mal

schneller als CPython kriegen. Also das ist halt, das ist

schon, also alle Leute, die halt so was

wie Advent of Code machen, ja,

Advent of Code ist eigentlich so,

ich scherze, aber ist irgendwie auch was

Wahres dran. Advent of Code ist halt irgendwie einer der

Haupt-coolen Use Cases

für PyPy. Es ist halt

irgendwie nicht so viel Code, es passt auf ein paar

Bildschirme, es ist irgendwie sehr algorithmisch

und man braucht nicht so viele Bibliotheken

und das wird halt dann, und Performance ist irgendwie

auch wichtig und da ist halt PyPy einfach

mega gut dafür.

Genau, und weil, also bei

Performance ist es halt so, man muss halt einfach messen.

Also du kannst halt nicht quasi so a priori entscheiden,

dass es immer jetzt Speed-Up X bringt,

sondern es führt quasi keinen Weg darum,

dass du deine konkrete Anwendung halt ausprobierst und schaust,

bringt es was oder halt nicht.

Habt ihr da irgendwie ein Referenzsystem

oder macht ihr das einfach immer so objektiv von dem über den Rechner?

Du meinst jetzt quasi,

inwiefern das von der darunterliegenden Hardware abhängt?

Ja, zum Beispiel, ja.

Das ist, glaube ich, nicht so ein Problem.

Wir unterstützen so einen Haufen CPU-Architekturen,

aber da sind wir nicht so sensitiv.

Es geht eigentlich dann eher darum,

was für Bibliotheken benutzt dein Projekt

und sind die eher so C-lastig oder was.

Es gibt halt Teile der Sprache,

wo wir einfach richtig, richtig gut drin sind,

die schneller zu machen.

Und Teile der Sprache,

wo wir dann nicht ganz so viel rausholen können.

Wie viel lernt C-Python von euch?

Das ist eine gute Frage.

Achso, ich wollte kurz die andere Abschätzung, also im besten Fall

so 30-40x, ich antworte gleich

und im schlechtesten Fall ist man

halt auch mal 30%

langsamer und das ist halt dann doof, da will man halt dann

nicht sein.

C-Python, also

ich habe manchmal

so quasi so Momente

des Zweifelns, ich

verbringe seit 18 Jahren

ein Teil meiner

Freizeit und irgendwie

ein Teil meines Berufs damit, an diesem Projekt zu basteln

und

so richtig,

also, was weiß ich,

99% von allen Deployments sind halt

dem C-Python. Und man kann sich dann halt die Frage

stellen, warum macht man

das eigentlich? Also

mir macht das natürlich irgendwie einfach unglaublich viel

Spaß, also ich bastel da gerne dran rum, aber

es ist natürlich auch schön, dann so ein bisschen so

quasi externe Motivationen aufzukriegen.

Und

klar, es gibt immer wieder Leute,

die das halt dann benutzen und das ist halt auch sehr cool,

aber es gibt halt

immer wieder auch Momente, wo wir dann quasi so

Rück,

so Rück,

politische Rückauswirkungen auf

C-Python haben. Und das ist quasi

meiner Ansicht nach auch so ein bisschen so

ein, so ein, der zweite

Grund, warum ich halt der Ansicht bin,

dass es eine gute Sache ist, dass es

eine zweite, sehr ernsthafte

Implementierung der Sprache Python gibt.

Weil wir quasi,

Also doch so ein bisschen Feature-Entwicklung

durch die Hintertür. So ein bisschen Feature-Entwicklung

durch die Hintertür, ganz genau. Und das ist zum Beispiel

interessanterweise bei den Fehlermeldungen passiert.

Also so ein paar

von den, das war 3.10?

Ja, 3.10 und 3.11.

Ja, da bleibt das Verbesserung.

Und bei beiden,

also ich will jetzt wirklich nicht

Keine Credits claimen.

Ich will keine Credits claimen.

Ich will auf gar keinen Fall, also was Pablo

und Batoan Toskaya und sowas,

was die da an Aufwand reingesteckt haben,

unglaublich nervig

und auch wirklich

sehr, sehr cool. Ich bin sehr zufrieden

mit einer Verbesserung. Wie gesagt, ich unterrichte Anfänger.

Ich kriege das quasi immer mit, wenn das

halt mal schief geht mit den Fehlermeldungen.

Aber so ein bisschen

so der ursprüngliche Drive

kam halt so ein bisschen von Piper. Also zum Beispiel dieses

mit den nicht gematchten

Klammern. Das ist ja so einer der neuen Fehlermeldungen,

dass es halt steht, die öffnende

Klammer, die öffnende Ecke Klammer auf

Zeile 5 wird mit einer runden schließenden Klammer

auf Zeile 9 geschlossen. Da stimmt

das nicht. Das war halt

einfach, das habe ich einfach vor ein paar Jahren mal

implementiert. Und irgendwann hat es halt

in Zepa hätten dann doch jemand mal gesehen und

fand es cool genug, um es halt dann doch

halt auch dann mal quasi

nachzuimplementieren. Und

jetzt ist es so ein bisschen, fast so ein bisschen so ein

Race manchmal. Also gerade

haben die ganz schön auch vorgelegt.

Also so ein paar der Fehlermeldungen

haben wir jetzt noch nicht wieder übernommen.

Aber an ein paar Stellen gibt's

halt immer noch ein paar, wo ich

mit unseren dann zufrieden bin. Zum Beispiel

so ein absoluter Standard

Anfängerfehler, wo man halt

echt Riesenprobleme hat, wenn man

in Python einsteigt, wenn man so

Objektorientierung lernt und man schreibt halt seine ersten Klassen

und schreibt Methoden und kommt halt vielleicht

von Java und vergisst das

Self. Und dann

versucht man, die Methode aufzurufen.

Erstes Argument fehlt. Und dann

stimmt halt die Argumentzahl nicht. Und dann

vergleicht man halt einfach mal die Aufrufstelle

mit

der Funktionsdefinition und sagt,

was ist denn eigentlich dein Problem? Ich hab ja doch

drei Argumente, warum beschwerst du dich denn,

dass ich da nur zwei reinreiche?

Oder, ja, so,

das stimmt ja dann immer nicht.

Und da

mache ich in PyPy einfach nur,

wenn es quasi einen

off-by-one-error bei einem Methodenaufruf

gibt, genau in diese Richtung,

dann schaut der

Interpreter nach, ob das erste Argument

self heißt. Und wenn

nicht, steht einfach nur noch da,

did you forget self in the method definition.

Ja, das wäre wahrscheinlich

eine gute Idee.

Ja, keine Ahnung, das ist natürlich, also

bei diesen Fehlermeldungen ist es halt

auch wirklich so, du hast halt einfach tausend

Fehler, also das ist auch nicht übertrieben, es gibt halt

ganz, ganz viele Stellen im Interpreter,

wo halt Fehler produziert werden und

jede einzelne ist halt dann irgendwie vielleicht

auch gar nicht so wichtig, also

diese Arbeit an Fehlermeldungen, die ist halt

wirklich auch in gewisser Weise sehr nervig, weil man

sich um jede einzelne irgendwie halt Gedanken

machen muss und da gibt es halt

auch keine Shortcuts so, also das

aber das ist halt eine, wo ich mal

dann so einen Tag dran Spaß hatte, mir zu überlegen,

wie man das halt vielleicht verbessern kann und

aber ich, also ich bin

halt, ich habe so ein bisschen

wie gesagt, ich will keinen

Credit klauen, aber ich habe so ein bisschen

das Gefühl, dass wir da einfach so ein bisschen

so einen Push gegeben haben, so einen Initial-Push.

Wir hatten halt an vielen Stellen

da so ein paar Sachen dann

zuerst implementiert und das

fließt jetzt ganz stark in den Zielpreisen ein, da bin ich

einfach mega glücklich drüber.

Das ist der Forscherdrang, der so ein bisschen auch

in die richtige Richtung geht. Der was?

Der Forscherdrang. Ja,

keine Ahnung, das ist jetzt nicht mein

Forschungsgebiet. Das war

eher so ein bisschen, ich habe halt dann wirklich

gesehen, dass es für die Studenten echt dann zum Teil

wirklich blöd ist. Zum Beispiel auch mit diesen,

das wurde jetzt auch abgeschafft,

ich glaube jetzt auch

in 3.11, also, oder in 3.10,

ich weiß nicht so, also zum Teil gab es

diese Fehlermeldung, diese Syntax-Fehlermeldung,

die echt so ganz komische Abkürzungen drin hatten,

die halt einfach nicht ausgeschrieben waren.

Insbesondere bei, zum Beispiel, wenn man

die, wenn man die,

die, die

Quotes vergessen hat beim String.

Also einfach nur x gleich

Anführungszeichen A, B, C und dann hast du hinten die Quotes

vergessen. Da war früher die Fehlermeldung

irgendwie

EOL while scanning

String Literal.

Ein Teil ist runter oder sowas auch noch gezeigt.

Genau, ganz genau.

Und das haben sie jetzt gefixt, das heißt jetzt halt wirklich

End of Line, weil ich meine,

woher soll irgendjemand

wissen, was EOL heißt?

Was Scanning heißt und auch noch was String Literal

heißt.

Und das ist jetzt wirklich schöner und das ist

Zum Beispiel in Triple Quoted String sagt er dir jetzt auch

die Fehlermeldung,

wo, ähm, wo dir,

also, da war die Fehlermeldung halt

immer in der allerletzten Zeile der Datei.

Weil er sucht

ja einfach immer weiter.

Bei Triple Quoted String ist es halt einfach dann

wahrscheinlich der ganze Rest quasi, der da drin liegt.

Und am Schluss ist halt, da fehlt was dann.

Und jetzt, das ist jetzt wirklich,

das wurde in 3.10 gefixt,

ist es jetzt halt so, dass er dir wirklich dann die Zeile zeigt,

wo die öffnenden Triple Quotes sind.

Und das ist natürlich viel schöner.

Und die andere Zeilennummer kommt aber auch vor in der Fehlermeldung.

Das heißt, du hast dann wirklich beides.

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

Und ich meine, in 3.11, die Position Informations,

die sind halt auch so ein bisschen,

das war quasi noch ein bisschen fieser von mir.

Das hatte ich noch nicht mal implementiert.

Da habe ich nur so einen Screenshot gefakt,

wo ich halt einfach nur im Editor einfach mal so diese Tilde

unter den Teil des Ausdrucks gemacht habe, wo der Fehler

herkommt. Dann habe ich einen Screenshot

davon getwittert und das hat

Pablo

gesehen und dann super

aufwendig. Es ist ein wirklich sehr

nerviges Feature. Ja, das glaube ich.

Ich habe mich schon gefragt, wie

das implementiert wurde, weil das

ist ja cool, aber oh mein Gott, wie ist das

denn implementiert? Wie kriegt man das denn

alles raus an den Stellen? Man muss halt wirklich einfach

die gesamte Information durch den gesamten

Stack so durchfädeln

Und das ist an jeder Stelle, da muss man das weiterreichen und an jeder Stelle hat man halt, am Anfang hatten die Syntaxbäume halt auch die Informationen gar nicht. Am Anfang hatte der Syntaxbaum halt nur eine Zeilennummer und dann kam irgendwie noch die Spaltnummer dazu, aber halt nur den Anfang. Also das Ende, bis wohin das dann geht, das war halt, das kam gar nicht vor.

Also nochmal für alle, die das noch nicht kennen, es gibt halt Fehlermeldungen, da wird ja jetzt die Position, wo der Fehler passiert ist, mit so Dreiecken unter Kringelt quasi unterstrichen, wo das halt aufgetroffen sein könnte.

Und da hatte ich halt diesen Tweet gefakt und jetzt gibt's das.

Also das ist mega geil, das sollte ich einfach öfter machen.

Und also ich muss das jetzt, das kommt dann wieder zu mir zurück,

weil wenn wir dann 3.11 unterstützen, dann muss ich das ja auch implementieren.

Also insofern habe ich jetzt mich da ein Stück weit auch selber mit reingelegt,

aber dass es jetzt halt in C-Python drin ist, finde ich einfach mega cool.

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

Und ich meine, das andere große Feature, wo wir halt dann quasi so ein bisschen,

also jetzt nicht Druck ausgeübt,

aber halt dann quasi Einfluss

produziert haben, sind halt

die Ordered Dictionaries.

Ach, okay. Also das ist ja

in 3.6, glaube ich.

Informell, das weiß ich nicht.

Aber 3.7 wird dann auch tatsächlich garantiert.

In 3.6 haben sie halt gesagt, ihr dürft euch nicht

darauf verlassen, dass die Dictionaries jetzt

in der Einführungsreihenfolge

sind. Und in 3.7

haben sie dann gesagt,

na, das funktioniert so gut, dass wir jetzt halt

sagen, wir werden das auch nicht wieder abschaffen.

Man darf sich jetzt darauf verlassen, weil es halt an ganz vielen Stellen

echt auch viele Vorteile hat.

Und das ist ein Pi-Pi-Feature.

Achso, okay, das war gar nicht klar.

Da gab es halt von Raymond Pettinger, gab es mal so ein

Prototyp, aber in Python, in Pure Python.

Und wir haben

halt einfach gesagt, das sieht halt

als Algorithmus echt gut aus.

Und wir machen jetzt das ganze Engineering,

was man halt braucht, um

das dann wirklich quasi in Produktiveinsatz

in die Implementierung einzubauen.

Das haben wir halt einfach dann irgendwann mal gemacht.

Und zwar noch nicht mal für unsere drei, sechs Versionen, sondern halt für unsere zwei, sieben Versionen.

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

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

Also dieser Python-Code war halt so ein, jetzt Sketch wäre ein bisschen untertrieben,

hat halt den Algorithmus so irgendwie präsentiert.

Aber quasi dann das zu nehmen und es dann so weit zu pushen, dass es halt so gut ist und quasi an allen Stellen mit dem bisherigen Dictionary-Algorithmus dann auch wirklich mithalten kann und trotzdem die Insertion-Order halt quasi erhalten bleibt, da haben wir halt dann wirklich nochmal sehr viel extra Aufwand reingesteckt.

Also Maschek Fischakowski und Armin Rigo haben das vor allem gemacht und dann hatten wir das halt irgendwie und dann gab es halt einen C-Python-Entwickler, der, der Name fällt mir gleich auch wieder ein, der hat das dann quasi wieder rückportiert.

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

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

Intuitiv irgendwie.

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

Das war ja früher so. Also früher war es halt irgendwie, hing es von den Hashwerten ab, das war halt komplett intransparent, warum halt dann die Sachen plötzlich ganz anders dastehen.

Ähm, und es ist halt auch gar nicht so, es ist halt auch a priori gar nicht so klar, dass, dass das wirklich effizient geht. Weil man könnte ja halt auch denken.

Wie macht man das jetzt? Macht man quasi so ein extra dazu, das immer noch von den Hashwerten abhängt? Oder, äh.

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

und dann würde man halt erstmal

denken, dass man halt da plötzlich

ganz viel Speicher irgendwie mehr

braucht, weil man diese

Indirektion hat

und da gibt es halt dann so einen Trick und das ist wirklich

auch das, was ich nicht verstanden

hätte vorher, bevor die Leute

sich halt ausgedacht haben, der Trick ist jetzt

die Hashmap, die darf ja nicht voll sein

weil du sonst Collisions kriegst

also wenn du quasi

wenn deine

Hashmap irgendwie zu voll wird, dann musst du halt irgendwie

die verdoppeln, um sie

herzustellen, dass...

Und nächstes Mal speicherfrei ist, wo du irgendwas reinkriegst.

Genau, ja. Und der Trick ist jetzt

aber, dass

du

mit dieser Indirektion jetzt

den großen Teil

einfach

linear speicherst.

Also du kannst dann,

diese Lücken fallen dann weg.

Die Lücken sind nur noch in deiner

Indirektion drin, aber nicht mehr

in deinem wirklichen Array, wo

halt für jeden Eintrag ein

Hash ein Key und ein Value gespeichert werden.

Weil ein Eintrag

von einem Dictionary besteht ja quasi aus

drei Maschinenwörtern und

wenn die dann quasi immer noch so Lücken haben,

hast du halt ständig Lücken, die

alle drei Maschinenwörter groß sind.

Aber wenn du die Indirektion einbaust,

dann ist quasi ein Eintrag nur noch

ein Index in den

dichten, in den dichtgespeicherten

Insertion Order

Speicher.

So, jetzt sind wir an dem Punkt, wo wir eigentlich gerne ein Bild

malen würden.

Und vielleicht ist dann der Blogpost,

ich finde den mal

und wir verlinken den dann, aber

für mich war es halt erstmal nicht klar, dass es

wirklich auch wirklich eine gute Idee ist, das so zu machen.

Also ist es aber.

Also stellt sich halt raus, es ist es.

Ja, cool.

Echt, genau.

Dann hat man quasi dann

für drüber iterieren, muss man dann einfach nur noch

durch die echte Liste gehen und es gar nichts mehr macht.

Das Iterieren ist halt auch besser, weil

vorher war es halt so,

Man musste quasi über die Hashmap drüber iterieren

und bei jedem Eintrag gucken,

ist das überhaupt ein Eintrag oder nicht.

Jetzt kann man aber quasi über den

dichten Speicher drüber iterieren,

wo einfach alle Einträge gültige Einträge sind.

Und man muss halt gar nicht mehr,

man verliert auch ein If

in jedem Next-Aufruf.

Also vorher war es so,

dass man quasi in einem Next-Aufruf

eine Schleife brauchte,

um den nächsten gültigen Eintrag zu finden.

Und jetzt weiß man halt einfach,

es ist der nächste Eintrag.

Ja, genau. Also das wäre halt auch noch so ein Beispiel, wo wir quasi dann die Implementierungsebene so ein bisschen beeinflusst haben. Aber sonst, also so die ganzen Kerntechniken, die wir, also wir haben jetzt noch gar nicht so, bisher haben wir eher so ein bisschen phänomenologisch darüber geredet.

Wir führen das aus, es wird schneller

und ich glaube, irgendwie jetzt müssen wir

vielleicht so ein bisschen anfangen darüber zu reden,

wie das eigentlich geht.

Also die Kern, ja.

Ich hätte noch ein, zwei Fragen.

Also werden

alle Sachen schneller?

Was mit anderen Sprachen, also kann da C++

irgendwie, wenn das irgendwie angebunden ist, ein Problem?

Also es wird

halt erstmal vor allem

Python schneller. Also wirklich, wenn du Python-Code

ausfüllst, wird das schneller. Aber die anderen Sachen laufen

noch. Die anderen Sachen laufen noch

und es kommt so ein bisschen drauf an,

was die genau machen,

ob die dann vielleicht

langsamer werden oder halt einfach gleich

bleiben oder

es gibt halt dann so Randfälle, zum Beispiel

reguläre Ausdrücke sind auch sehr, sehr schnell

bei uns in PyPy,

obwohl die natürlich eigentlich kein Python-Code sind, aber da

haben wir dann eine extra Optimierung dafür, das ist ja

quasi so eine kleine DSL

in Python,

also du sollst ja DSL nochmal beschreiben, weil ich so

Language gemeint habe. Genau, eine Domain-Specific-Language

für String-Matching. Also

ich meine, das ist eine sehr häufige, die halt quasi überall

eingebaut ist, aber es ist ja schon eine andere

Programmiersprache als Python letztlich.

Aber wir haben halt dafür auch dann quasi

ganz viel Optimierung gemacht,

dass das halt auch schnell ist.

Normalerweise kann ich die per PyEnv einfach

installieren, dann mein

PyPy auch? Ich glaube, PyEnv

unterstützt auch PyPy, ja. Also

Tox hat eigentlich zum Beispiel PyPy-Support, wenn du das testen willst.

Das ist schon an vielen

Stellen quasi so ganz

gut in die

in die

Infrastruktur.

Nach dem Semester-Fan

kriegen wir hoffentlich einen Alpha-Release.

Also da arbeite ich

gerade halt dran. Heute Morgen

habe ich zwei Bugs gefixt. Also das ist

das, was ich jetzt gerade so halt wirklich

konkret mache.

Also die großen Features sind halt fast

fertig. Also Pattern-Matching

ist da und

3.10 hatte, also außer Pattern-Matching

halt auch viele so mittelgroße Sachen.

aber Pattern Matching, das war wirklich

auch, kann ich mir vorstellen, das macht

ja beim Parsen

ein relativ großes, ich glaube, das konnte ja auch nur

deswegen in C-Python

irgendwie gemacht werden,

weil da dann der neue

Pack-Parser irgendwie verwendet wurde und ich weiß gar nicht,

bei Pypi, äh Pypi, äh Pypi

ist eigentlich reingefallen.

Da ist ja, da

weiß ich gar nicht, was da verwendet wird, aber das

könnte ja dann auch auswirken. Da hatte ich zum Glück sehr gut,

also vor einem Jahr hatte ich dann 3.9

implementiert und da war

3.10 ja schon raus und da habe ich halt so gesehen,

der Packparser wird wichtig

und ich habe dann quasi bei 3.9 schon

die ganze

technische Vorarbeit dafür geleistet.

Wir haben auch einen Packparser,

quasi mehr oder weniger die gleiche Architektur.

Wir können nicht ganz das gleiche Input-File nehmen,

weil, ich weiß nicht, ob du mal

in diese Grammatik-Datei reingeschaut hast?

Nee, nicht wirklich. Also das ist halt im Prinzip

so ein bisschen so eine kontextfreie Grammatik,

wie man das halt irgendwie

aus irgendeiner Informatik-Vorlesung

vielleicht mal gesehen hat, aber

im Unterschied zur alten Grammatik ist das so,

dass jetzt in der Pack-Grammatik

da sind halt so Schnipsel an C-Code drin.

Und

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

Und wir müssen quasi

die Schnipsel an C-Code, die mussten wir halt quasi von Hand

einfach einmal überall ersetzen. Und das war sehr, sehr

nervig. Und das

ist auch so ein bisschen meine Kritik,

dass quasi

die Grammatik der Sprache vermischt

wird mit den Parsing-Actions, die in C

geschrieben sind, bei C-Python.

Bei uns sind die nicht ins Ziel geschrieben, wir werden gleich noch darüber sprechen, worin die bei uns dann geschrieben sind, aber das war halt dann einmal sehr, sehr nervig, da drüber zu gehen und alle diesen C-Schnipsel dann da auszutauschen und da habe ich dann auch immer mal wieder einen Fehler gemacht, die finde ich dann jetzt auch immer mal wieder einen, also das war halt einfach Aufwand, aber ich habe halt damals quasi schon vor dem Jahr dann quasi schon vorgearbeitet und gesagt, wenn dann 3.10 kommt, dann will ich halt quasi auch schon darauf vorbereitet sein,

dass das Pattern Matching

dann in den Parser zumindest einfach einzufügen

ist. Aber es ist

halt nicht nur ein Parser, es ist ganz viel

neues Syntax, aber es sind halt auch einiges

an neuen Bytecodes und der Bytecode-Compiler

hat halt ganz, ganz

viel recht komplexe

Logik auch gekriegt

und das habe ich jetzt, aber das ist zum größten Teil

jetzt halt ziemlich fertig.

Da fehlt mir noch so ein Randfall,

den muss ich jetzt irgendwann noch fixen, der

hat mich bisher noch zu sehr genervt, aber

also das ist quasi fast

durch.

Und dann, also jedes

Release,

so der,

ich versuche mal so ein bisschen ein

Gefühl dafür zu vermitteln, wie sich das anfühlt, an so einer

neuen Python-Version zu arbeiten. Es gibt halt

immer irgendwie fünf große Features, die man halt

auf der What's New-Seite

kennt und die implementiert man halt.

Das ist dann irgendwie halt auch nice, ja, weil

da ist so ein klar umrissener Task

und man freut sich vielleicht halt auch über, vielleicht

ist es halt auch ein Feature, was man gut findet.

Ich weiß nicht, wie ist euer Bauchgefühl?

Wie findet ihr Pattern-Matching?

Ich liebe es.

Okay, ich habe es noch nicht wirklich viel verwendet.

Ich mag das total gerne.

Statt if, elif irgendwie einfach schöne Cases zu machen.

Gerade für so API-Parsing.

Also ich finde, man muss sich ganz,

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

Ich habe es auch noch nicht so richtig im Produktiv,

also noch nicht wirklich irgendwas geschrieben,

was halt nicht einfach so ein Toy-Beispiel ist.

Aber man muss sich schon so ein bisschen reindenken.

Also ich finde, es unterscheidet sich halt

in mancher Hinsicht schon

so ein bisschen von dem

Feeling von Python an so ein paar

anderen Stellen.

Ich glaube, wenn man dann da

so mal gedanklich drin ist, ist das glaube ich wirklich auch

sehr, sehr cool, aber man braucht so ein bisschen.

Oder ich habe das Gefühl, dass ich es noch so ein bisschen brauche.

Man kann irgendwie so direkte Kommandos geben und

man kann da direkt sagen, was das ist.

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

Weil wenn man halt tatsächlich Typen

definiert hat irgendwie, dann kann man halt einfach

diesen Typ als Case nehmen

und das ist halt

genau das, was man wahrscheinlich irgendwie

Aber also was man dann wirklich in die Patterns

reinschreibt, das ist halt quasi nochmal

so ein bisschen so eine Sprache in der Sprache

und die ist halt

schon so ein bisschen anders halt auch

als

der Rest von Python.

Ja, aber jetzt, ich glaube, du musst vielleicht gleich nochmal so ein bisschen

ausholen darüber, was eigentlich so eine Sprache aus

deiner Sicht halt ist.

Ja, das ist jetzt ziemlich schwammig, da würde ich, also ja.

Genau,

aber auf jeden Fall, also man hat da so ein

großes Feature, sowas wie Pattern Matching,

das ist halt schön, da kann man, weiß man,

das ist relativ klar umrissen, wenn

man das Feature cool findet, dann macht es halt auch richtig

Spaß, das zu implementieren, ja, dann

so über ein paar Tage hinweg fängt das halt dann an

zu funktionieren, das ist halt einfach immer wieder auch sehr

cool und irgendwann

ist man halt dann mit allen großen Featuren fertig

und dann gibt es so ein bisschen,

zusätzlich zu den fünf großen Featuren gibt es halt

vielleicht 30

kleinere und mittlere Feature,

das ist halt so ein bisschen Fleißarbeit

und dann gibt es aber halt einfach

tausend Details

und das sind halt,

das ist der Teil, der quasi am längsten

dauert und ein bisschen

am nervigsten ist, also weil man halt jeden Tag

einfach fünf kleine Details

fixen kann und man

findet die, indem man halt die

Testsuite, die

Teil der C-Python-Standard-Bibliothek

ist, ausführt

und dann halt die fehlenden

Tests nach und nach fixt

und

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

Also es gibt halt Test Padma, das hat man halt irgendwann

dann, das passt dann, dann ist es super.

Aber dann ist halt in allen anderen Dateien

gibt es halt dann so einen fehlschlagenden

Test und jeder von diesen fehlschlagenden

Tests dauert halt zwei Stunden

und das ist halt einfach das, was einfach ganz

ganz, also da

gibt es halt quasi dann so einen long tail an irgendwelchen

Details. Und der

quasi

Fortschritt, den man dadurch erzielt, dass man das

fix, ist halt auch irgendwann dann nicht mehr

so groß, dass man sich, wahrscheinlich denkt man sich dann irgendwann

so, das lohnt sich halt nicht mehr.

Wer das so irgendwann mal benutzt. Genau.

Okay, aber das ist tatsächlich dann TDD auch,

was ihr da macht. Ja, also

Piper ist von, also so von der

Entwicklungsphilosophie sehr,

also ich meine, wir haben ja

vorhin ganz kurz gesagt, dass es jetzt irgendwie

20 Jahre altes Projekt ist, also es wurde

fast genau,

also irgendwie 17. Februar war das erste

Treffen von so

ein paar Leuten in Hildesheim. 2003.

2003, genau. Also völlig anderes Zeitalter so ein bisschen. Und damals war das halt irgendwie so ein bisschen, hatte das so ein bisschen so ein Extreme Programming Kontext auf der Entwicklungsphilosophie Seite. Also so mit Test Development und Agile, bevor das kommerzialisiert wurde, so von der Idee her.

Und es ist wirklich so, dass diese Implementierung von vornherein komplett testdriven entwickelt wurde. Das ist halt an vielen Stellen auch wirklich ganz tief drin in der Philosophie des Projekts. Und es ist auch so, dass PyTest aus PyPy hervorgegangen ist.

Also der Holger Kregel, über den haben wir, bevor wir anfangen aufzunehmen, kurz schon geredet, der war halt einer der Gründer des PyPy-Projekts, also der hat das erste Treffen in Hildesheim organisiert und am Anfang wurde dann für die Tests halt einfach Unitest genommen.