WEBVTT

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

00:00:06.500 --> 00:00:06.960
Hallo Jochen.

00:00:07.220 --> 00:00:08.140
Ja, hallo Dominik.

00:00:08.300 --> 00:00:08.660
Hallo Karl.

00:00:08.780 --> 00:00:09.080
Herzlich Willkommen.

00:00:09.600 --> 00:00:10.000
Hallo Karl.

00:00:10.720 --> 00:00:13.860
Ja, wir wollen wie immer erstmal News machen. Was hast du denn da, Jochen?

00:00:14.520 --> 00:00:17.040
Oh, oh, oh, jetzt muss ich mal, wir müssen hochscrollen.

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

00:00:27.700 --> 00:00:29.920
dass das jetzt schon für Python 3.12

00:00:29.920 --> 00:00:31.360
irgendwie ein

00:00:31.360 --> 00:00:33.400
Compiler-Flag einführen soll, das den

00:00:33.400 --> 00:00:35.780
Global Interpreter-Log optional macht.

00:00:36.380 --> 00:00:37.460
Das war so die letzte Woche

00:00:37.460 --> 00:00:39.540
große Neuigkeit. Also ich glaube, es gibt zwei große Themen,

00:00:39.960 --> 00:00:41.040
Packaging und

00:00:41.040 --> 00:00:43.220
irgendwie diesen

00:00:43.220 --> 00:00:44.780
PEP 703.

00:00:46.060 --> 00:00:47.560
Ja, und ich habe dann auch so ein bisschen reingeguckt.

00:00:47.700 --> 00:00:49.660
Ich bin ja immer so ein bisschen der Ansicht

00:00:49.660 --> 00:00:51.200
oder ich habe dir so ein bisschen vertreten, dass

00:00:51.200 --> 00:00:53.700
ich das eigentlich nicht so ganz nachvollziehen kann,

00:00:53.760 --> 00:00:55.200
warum das so ein Riesenthema ist, weil

00:00:55.200 --> 00:00:56.820
ehrlich gesagt betrifft es mich meistens nicht.

00:00:56.900 --> 00:00:58.980
ich bin eigentlich bisher kaum je in die Situation

00:00:58.980 --> 00:01:00.000
gekommen, dass

00:01:00.000 --> 00:01:02.780
dieser Global Interpreter-Log für mich jetzt ein

00:01:02.780 --> 00:01:03.940
großes Problem gewesen wäre.

00:01:04.960 --> 00:01:06.840
Aber ich habe mir den jetzt nochmal angeguckt und

00:01:06.840 --> 00:01:08.940
tatsächlich, also es gibt da schon viele Situationen,

00:01:08.980 --> 00:01:10.820
wo einem das halt Ärger machen kann. Also mein

00:01:10.820 --> 00:01:12.900
Beispiel war, ich hatte ja mal gefragt, ob jemand ein anderes

00:01:12.900 --> 00:01:14.940
Beispiel hatte, also wenn jetzt eine Datenbank in Python

00:01:14.940 --> 00:01:16.320
schreiben will, dann könnte einem das Ärger machen.

00:01:17.500 --> 00:01:18.840
Und es gibt aber noch viel mehr

00:01:18.840 --> 00:01:20.900
Beispiele und da standen auch welche

00:01:20.900 --> 00:01:22.820
drin, wo ich dann sagen muss, okay, doch, das hat

00:01:22.820 --> 00:01:24.820
schon, da haben Leute schon ein Problem

00:01:24.820 --> 00:01:26.600
dann eventuell. Gerade so im

00:01:26.600 --> 00:01:28.660
Data-Science-Bereich, das war mir gar nicht klar, also ganz wichtig

00:01:28.660 --> 00:01:30.680
ist da wohl, dass man halt

00:01:30.680 --> 00:01:32.780
nicht von unterschiedlichen Prozessen aus auf

00:01:32.780 --> 00:01:34.800
den GPU-Speicher zugreifen

00:01:34.800 --> 00:01:36.040
kann, tatsächlich, so richtig.

00:01:36.660 --> 00:01:38.420
Und dann kriegt man natürlich sehr schnell ein Problem,

00:01:38.780 --> 00:01:40.400
wenn man da nicht mehrere Sets auf

00:01:40.400 --> 00:01:42.300
unterschiedlichen CPUs laufen lassen kann.

00:01:43.100 --> 00:01:44.400
Ja, genau.

00:01:46.340 --> 00:01:46.580
Ja,

00:01:47.320 --> 00:01:48.700
das war so, das ist

00:01:48.700 --> 00:01:50.360
ganz interessant gewesen.

00:01:50.640 --> 00:01:52.540
Aber ist noch voll auch in Diskussion, oder?

00:01:52.540 --> 00:01:54.300
So ein richtiges, so einen klaren

00:01:54.300 --> 00:01:56.300
Konsens gibt es da noch nicht, oder? Hast du da einen

00:01:56.300 --> 00:01:58.400
Überblick? Ne, genau, also die Diskussion

00:01:58.400 --> 00:02:00.200
habe ich mir teilweise angeguckt, aber auch nicht komplett und

00:02:00.200 --> 00:02:02.060
ob es jetzt wirklich kommt oder nicht, keine Ahnung.

00:02:02.540 --> 00:02:04.120
Es stand auch irgendwann ein Zeitplan

00:02:04.120 --> 00:02:06.260
in dem PEP selber drin, der eher so

00:02:06.260 --> 00:02:08.220
sagte, ja, also der Plan ist

00:02:08.220 --> 00:02:10.200
eher, das ab 2024 einzuführen

00:02:10.200 --> 00:02:11.760
und dann 25,

00:02:12.160 --> 00:02:14.240
26, dann halt

00:02:14.240 --> 00:02:16.300
irgendwann dazu überzugehen,

00:02:16.380 --> 00:02:17.940
das halt quasi

00:02:17.940 --> 00:02:20.020
3,15.

00:02:20.620 --> 00:02:22.200
Ja, ich weiß jetzt gar nicht mehr,

00:02:22.200 --> 00:02:24.280
in welcher Relation es war, so 13, 14, 15,

00:02:24.300 --> 00:02:26.580
dann irgendwann umzusteigen

00:02:26.580 --> 00:02:28.220
auf per Default ist der

00:02:28.220 --> 00:02:30.120
Global Interpreter locker aus und dann

00:02:30.120 --> 00:02:32.600
irgendwann es zu deprecaten

00:02:32.600 --> 00:02:34.440
und dann bis irgendwann 2030 oder so wegfallen

00:02:34.440 --> 00:02:36.340
zu lassen, aber das ist dann halt sehr weit in der Zukunft.

00:02:36.820 --> 00:02:37.460
Kleine Ahnung.

00:02:38.060 --> 00:02:40.680
Und der Plan ist aber erstmal, das quasi hinter einer

00:02:40.680 --> 00:02:42.200
Interpreter

00:02:42.200 --> 00:02:44.100
Compile-Time-Flag zu verstecken.

00:02:44.320 --> 00:02:45.240
Ja, okay, alles klar.

00:02:46.900 --> 00:02:48.520
Jetzt haben wir ja direkt am Anfang so was Schwieriges

00:02:48.520 --> 00:02:50.360
gemacht. Können wir vielleicht

00:02:50.360 --> 00:02:52.120
nochmal ganz kurz erklären, was nochmal ein

00:02:52.120 --> 00:02:53.160
Gehör ist?

00:02:53.760 --> 00:02:54.740
Ja, soll ich?

00:02:54.980 --> 00:02:55.800
Ja, gerne.

00:02:56.240 --> 00:02:57.500
Also das Problem ist einfach,

00:02:57.600 --> 00:03:00.500
dass der Python-Interpreter selber nicht Thread-safe ist.

00:03:01.120 --> 00:03:02.740
Dass quasi die ganzen Datenstrukturen,

00:03:02.740 --> 00:03:06.660
die quasi der Interpreter selbst verwendet,

00:03:06.720 --> 00:03:09.160
halt nicht mit irgendwelchen Logs versehen sind,

00:03:09.240 --> 00:03:10.940
sondern es einfach nur davon ausgegangen wird,

00:03:11.020 --> 00:03:12.160
in der Implementierung überall,

00:03:12.900 --> 00:03:15.300
dass zu jedem Zeitpunkt halt nur ein Python-Thread,

00:03:16.020 --> 00:03:18.360
ein Thread wirklich Python-Code ausführen kann.

00:03:19.000 --> 00:03:21.420
Und das führt dazu, dass man halt quasi,

00:03:21.540 --> 00:03:22.680
wenn man Python-Code schreibt,

00:03:23.480 --> 00:03:30.200
nur von einem Thread aus wirklich gerade ausführen kann.

00:03:31.260 --> 00:03:33.500
Und dazu, das hat halt die Auswirkung,

00:03:33.580 --> 00:03:34.380
es war lange kein Problem,

00:03:34.480 --> 00:03:37.480
weil halt keiner irgendwie ein Multi-Prozessor-System hatte.

00:03:37.640 --> 00:03:40.920
Aber jetzt, wo es halt Multi-Core gibt seit 20 Jahren oder so,

00:03:42.320 --> 00:03:44.460
ist es halt immer wieder ein großes Diskussionsding,

00:03:44.800 --> 00:03:47.020
dass es halt nicht so toll ist,

00:03:47.080 --> 00:03:49.980
dass man wirklich Multi-Thread-Algorithmen in Python schreiben kann.

00:03:49.980 --> 00:03:53.280
Ist das brauchbar zusammengefasst?

00:03:53.480 --> 00:03:54.680
Ja, ja, doch, nee, klingt gut.

00:03:55.360 --> 00:04:09.220
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.

00:04:09.660 --> 00:04:20.540
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.

00:04:20.840 --> 00:04:47.120
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.

00:04:47.120 --> 00:05:01.840
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.

00:05:01.840 --> 00:05:28.960
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,

00:05:29.280 --> 00:05:30.960
Aber das hat auch noch ein paar Sachen da drin,

00:05:31.060 --> 00:05:32.560
die jetzt in dem aktuellen Pep nicht drin sind.

00:05:33.900 --> 00:05:34.860
Daher wäre das ein bisschen

00:05:34.860 --> 00:05:36.540
langsamer. Aber ja, also

00:05:36.540 --> 00:05:38.600
10% ist jetzt noch nicht so allzu viel.

00:05:38.960 --> 00:05:40.680
Es gibt auch noch so ein paar andere Sachen, wie zum Beispiel,

00:05:40.740 --> 00:05:42.740
man muss jetzt halt da, es gibt dann so

00:05:42.740 --> 00:05:44.200
ein paar Tricks, die da verwendet werden.

00:05:44.760 --> 00:05:45.700
Und einer ist halt auch,

00:05:46.740 --> 00:05:48.560
dass es jetzt halt immer

00:05:48.560 --> 00:05:50.720
einen Pointer auf den Thread gibt, in jedem

00:05:50.720 --> 00:05:51.540
Python-Objekt,

00:05:52.160 --> 00:05:54.280
der das erzeugt hat, weil man

00:05:54.280 --> 00:05:56.340
der Garbage Collector zwar nur innerhalb der

00:05:56.340 --> 00:05:58.560
von einem Thread erzeugten Sachen aufräumt,

00:05:58.640 --> 00:06:00.680
oder Reference-Counting macht und dann muss man

00:06:00.680 --> 00:06:02.680
das halt vielleicht nicht mehr locken, aber dann muss man halt

00:06:02.680 --> 00:06:04.460
sich merken, welcher Thread das war und das sind halt

00:06:04.460 --> 00:06:06.540
ein 64-Bit-Ding und dann

00:06:06.540 --> 00:06:07.900
hat man noch so einen

00:06:07.900 --> 00:06:10.680
Pointer auf, das ist gar nicht mehr genau,

00:06:10.740 --> 00:06:12.580
das sind insgesamt drei Pointer, die jedes Objekt mehr

00:06:12.580 --> 00:06:14.480
kriegt, drei 64-Bit-Pointer und das ist natürlich schon

00:06:14.480 --> 00:06:16.800
irgendwie, das sind halt 24 Byte

00:06:16.800 --> 00:06:18.740
mehr pro Objekt,

00:06:18.860 --> 00:06:20.660
das ist schon nicht so ohne, also speichermäßig

00:06:20.660 --> 00:06:22.440
ist es auch ganz schön und

00:06:22.440 --> 00:06:23.420
ja,

00:06:23.900 --> 00:06:26.620
ja, so

00:06:26.620 --> 00:06:28.740
Es sind halt nur Trade-Offs.

00:06:28.840 --> 00:06:30.700
Wenn man es gebrauchen kann, ist es vielleicht gut, aber

00:06:30.700 --> 00:06:32.820
wenn man es halt irgendwie nicht braucht,

00:06:33.000 --> 00:06:34.840
dann kann es auch sehr nervig sein.

00:06:34.840 --> 00:06:36.540
Ja, und deswegen

00:06:36.540 --> 00:06:38.500
und die C,

00:06:39.040 --> 00:06:40.780
dieses Application

00:06:40.780 --> 00:06:42.820
Binary Interface

00:06:42.820 --> 00:06:44.140
ist halt auch nicht mehr kompatibel,

00:06:44.700 --> 00:06:46.680
sodass halt man im Grunde

00:06:46.680 --> 00:06:48.500
halt die C-Extensions,

00:06:49.220 --> 00:06:50.040
also für jedes

00:06:50.040 --> 00:06:54.380
Paket, das halt eine

00:06:54.380 --> 00:06:55.700
C-Extension ist,

00:06:56.620 --> 00:06:58.760
muss man halt die entsprechend richtige

00:06:58.760 --> 00:07:00.620
Version installieren für den Infrared-Richter, den man

00:07:00.620 --> 00:07:02.660
verwendet. Also man muss quasi jede C-Extensions

00:07:02.660 --> 00:07:04.860
einmal anfassen und halt zum Teil die

00:07:04.860 --> 00:07:06.520
C-API

00:07:06.520 --> 00:07:08.280
Usage irgendwie dann

00:07:08.280 --> 00:07:10.560
korrekt machen und die Logs einführen,

00:07:10.620 --> 00:07:11.840
wenn das nicht Thread-Safe ist.

00:07:12.600 --> 00:07:14.420
Also das ist halt möglicherweise schon auch Aufwand.

00:07:14.720 --> 00:07:15.000
Ja, ja.

00:07:18.200 --> 00:07:20.380
Also wenn man, okay, also das wird dann tatsächlich ein

00:07:20.380 --> 00:07:22.560
Breaking-Change sein, dann, wenn die C-Extensions

00:07:22.560 --> 00:07:24.320
dann nicht mehr gehen.

00:07:24.320 --> 00:07:25.980
Das ist dann eigentlich Python 4?

00:07:26.620 --> 00:07:28.300
Nee, also sag mal so, du kannst es ja parallel

00:07:28.300 --> 00:07:30.500
verwenden, also wenn du das nicht benutzen willst.

00:07:30.500 --> 00:07:31.220
Wenn der Default sich ändert.

00:07:32.320 --> 00:07:34.220
Ja, aber das ist dann irgendwann, das ist in der weiten

00:07:34.220 --> 00:07:35.880
Zukunft, also das ist halt noch Jahre heran.

00:07:35.880 --> 00:07:38.320
Ja, aber wenn das Python 3.5 ist, dann ist es Python 4.

00:07:39.100 --> 00:07:40.120
Ja gut, ich meine,

00:07:40.320 --> 00:07:42.220
wenn niemand bis dahin umgestellt hat und es keine

00:07:42.220 --> 00:07:43.900
Pakete gibt, dann wird man das wahrscheinlich einfach nicht machen.

00:07:44.400 --> 00:07:46.220
Wenn es alle schon machen, alle relevanten,

00:07:46.520 --> 00:07:48.300
dann ist es halt auch nicht mehr so schlimm, wenn man das deprecated

00:07:48.300 --> 00:07:50.200
also, ja, keine Ahnung,

00:07:50.280 --> 00:07:52.260
ist wahrscheinlich jetzt sehr schwer, da irgendwelche Voraussagen zu

00:07:52.260 --> 00:07:54.100
machen. Aber, ja.

00:07:54.140 --> 00:07:56.120
Ich glaube, wir müssen nachher einfach, aber auf jeden Fall

00:07:56.120 --> 00:07:58.300
uns merken, dass wir noch ein bisschen über C-Extensions

00:07:58.300 --> 00:08:00.160
reden müssen. Oh ja, ich glaube, das werden wir.

00:08:01.960 --> 00:08:02.540
Wer war denn

00:08:02.540 --> 00:08:04.220
da bei Facebook noch mal mit dabei? War das Sam Gross?

00:08:04.320 --> 00:08:05.000
Sam Gross, genau.

00:08:06.180 --> 00:08:08.080
Du hattest vielleicht den Vortrag auf der Eurofight

00:08:08.080 --> 00:08:09.400
letztes Jahr gesehen. Ja, ja.

00:08:10.180 --> 00:08:12.120
Ich habe nicht so viel verstanden, aber ich habe ihn mir angeguckt.

00:08:12.860 --> 00:08:13.540
Okay, ja.

00:08:14.780 --> 00:08:16.340
Ja, ja, ist auch ein schwieriges Thema, glaube ich.

00:08:16.920 --> 00:08:20.300
der, der, der, also einige der Ideen

00:08:20.300 --> 00:08:21.880
sind auch schon, also diese Geschichte mit den

00:08:21.880 --> 00:08:24.080
drei Pointern, die es jetzt gibt, es gab ein akademisches

00:08:24.080 --> 00:08:25.640
Paper dazu, wie man das denn bauen kann

00:08:25.640 --> 00:08:27.620
und da wurden die, diese

00:08:27.620 --> 00:08:29.480
Informationen, die darin stecken, in einen Pointer

00:08:29.480 --> 00:08:31.500
reingefriemelt irgendwie,

00:08:31.660 --> 00:08:33.880
reinkodiert und das war den Leuten

00:08:33.880 --> 00:08:35.560
aber dann jetzt zu heiß und dann haben sie gesagt,

00:08:35.600 --> 00:08:37.380
nee, wir nehmen lieber drei, das ist zu gefährlich,

00:08:37.580 --> 00:08:39.360
was können da alles für Overflows passieren?

00:08:40.100 --> 00:08:41.880
Und also daran sieht man

00:08:41.880 --> 00:08:43.720
schon, dass es halt, dass sie sich das nicht getraut haben,

00:08:43.780 --> 00:08:45.640
das einfach so zu übernehmen, es ist kompliziert.

00:08:46.320 --> 00:08:47.680
Würdest du das Paper bitte auch verlinken?

00:08:47.740 --> 00:08:49.680
Das klingt eigentlich spannend. Ja, kann ich machen.

00:08:50.400 --> 00:08:51.380
Mach auch den Talk von

00:08:51.380 --> 00:08:53.340
der Europython rein, wenn es den irgendwo schon gibt.

00:08:53.780 --> 00:08:56.100
Ich füge das mal hinzu.

00:08:56.660 --> 00:08:56.960
Alles klar.

00:08:57.380 --> 00:08:59.580
Er hat das nämlich genau erklärt, wie er das so vorhat.

00:09:00.340 --> 00:09:01.940
Und das war schon...

00:09:01.940 --> 00:09:04.020
Er hat einige clevere Ideen dabei gehabt, fand ich.

00:09:04.700 --> 00:09:05.820
Auch ein spannender Typ, ja.

00:09:07.300 --> 00:09:07.660
Ja.

00:09:08.560 --> 00:09:08.920
Okay.

00:09:09.400 --> 00:09:10.760
Habt ihr noch nichts? Du hast gesagt Packaging.

00:09:10.820 --> 00:09:12.540
Ja, Packaging.

00:09:14.100 --> 00:09:15.500
Das war ein anderes großes Thema.

00:09:15.660 --> 00:09:17.620
Auch vor zwei Wochen oder so gestartet.

00:09:17.800 --> 00:09:18.480
Oder noch ein bisschen länger.

00:09:18.880 --> 00:09:21.120
Und das kann ich halt immer noch so versichern.

00:09:21.200 --> 00:09:22.200
Es gibt einen sehr, sehr langen Thread.

00:09:23.780 --> 00:09:25.580
ich weiß gar nicht genau, wo war das

00:09:25.580 --> 00:09:27.520
denn? Das Ding heißt

00:09:27.520 --> 00:09:29.420
irgendwie Python Packaging Strategy Discussion

00:09:29.420 --> 00:09:31.400
Teil 1, das ist auf DiscussPython.org.

00:09:31.500 --> 00:09:33.060
Ah, okay. Ja, und

00:09:33.060 --> 00:09:35.300
habe ich nicht ganz gelesen, das war mir dann zu viel,

00:09:35.480 --> 00:09:37.480
aber es gab, dann haben

00:09:37.480 --> 00:09:39.320
auch diverse Leute da längere

00:09:39.320 --> 00:09:41.220
Blogposts darüber geschrieben, was sie denn so denken.

00:09:41.640 --> 00:09:43.020
Also ja, das Problem ist natürlich

00:09:43.020 --> 00:09:45.280
irgendwie bei allen Umfragen, die man zum Thema

00:09:45.280 --> 00:09:47.440
Python macht, dann wird

00:09:47.440 --> 00:09:49.340
das von Leuten, die da nicht so

00:09:49.340 --> 00:09:51.420
erfahren sind, immer als Painpoint Nummer 1

00:09:51.760 --> 00:09:53.280
beschrieben, dass es halt so kompliziert ist

00:09:53.280 --> 00:09:55.360
und dass man nicht weiß, was man denn jetzt

00:09:55.360 --> 00:09:57.080
nehmen soll für welche Tools und

00:09:57.080 --> 00:09:59.320
wie man die dann jetzt am besten, wie rum man die hält

00:09:59.320 --> 00:10:00.740
und dann wird es nicht irgendwie

00:10:00.740 --> 00:10:02.920
keine furchtbaren Sachen passieren und

00:10:02.920 --> 00:10:05.040
ja, das ist ein Problem und

00:10:05.040 --> 00:10:07.280
aber es gibt auch keine so richtig einfache

00:10:07.280 --> 00:10:07.640
Lösung

00:10:07.640 --> 00:10:11.400
und ich weiß es nicht so genau. Ich glaube, das Fazit

00:10:11.400 --> 00:10:13.480
war mehr so, ja, es liegt halt vor allen Dingen

00:10:13.480 --> 00:10:15.300
daran, dass halt auch Python einfach sehr alt ist und Leute

00:10:15.300 --> 00:10:17.300
das auf sehr unterschiedliche Art verwenden und man

00:10:17.300 --> 00:10:19.120
kann es nicht gut lösen, weil

00:10:19.120 --> 00:10:21.020
man kann nicht allen gerecht werden,

00:10:21.380 --> 00:10:23.320
weil manche Leute brauchen halt sehr feingranulare

00:10:23.320 --> 00:10:24.920
Geschichten und andere lieber

00:10:24.920 --> 00:10:26.660
ein eigenes Interface und das kann man,

00:10:27.240 --> 00:10:28.800
ja, wie will man das unter einen Hut bringen?

00:10:28.900 --> 00:10:30.780
Das ist schwierig. Also auch interessant,

00:10:31.100 --> 00:10:32.820
fand ich genau, ich weiß nicht, ob das in dem Zusammenhang

00:10:32.820 --> 00:10:34.620
aufgetaucht ist, aber es ist auch erst wenige Wochen alt, von

00:10:34.620 --> 00:10:36.100
Nathaniel Smith, ein

00:10:36.100 --> 00:10:38.660
neuer Paketsprachler, Posey heißt er,

00:10:39.000 --> 00:10:40.460
oder Posey, ich weiß nicht genau, wie man das ausspricht,

00:10:41.320 --> 00:10:42.840
der ist das eine, ein Rust-Binary,

00:10:43.080 --> 00:10:44.800
die quasi das ganze Zeugs von

00:10:44.800 --> 00:10:47.000
Python übernehmen soll, also den Interpreter mit ausliefern

00:10:47.000 --> 00:10:48.880
und Pakete bauen und

00:10:48.880 --> 00:10:50.880
Dependencies bauen und

00:10:50.880 --> 00:10:52.300
deren Grafen bauen und so. Und das

00:10:52.300 --> 00:10:54.880
sah, fand ich, relativ interessant aus, weil genau

00:10:54.880 --> 00:10:56.920
das auch eines der Pages ist, die allen Leuten, mit denen ich

00:10:56.920 --> 00:10:58.040
irgendwas mit Paisen machen will, erstmal

00:10:58.040 --> 00:11:00.840
erklären muss, hä, wie geht denn das? Oh, das ist aber kompliziert und warum

00:11:00.840 --> 00:11:02.800
ist das denn so? Und ja,

00:11:02.880 --> 00:11:04.820
sobald dann halt, also wenn die einen Paisen machen, okay, aber wenn die

00:11:04.820 --> 00:11:06.580
nochmal eine andere Paisenversion, irgendwann habe ich es ja später so,

00:11:06.620 --> 00:11:08.760
geht alles kaputt und Fahrt anpassen und dies, das

00:11:08.760 --> 00:11:10.820
ist für einige Menschen gar nicht so einfach zu handeln.

00:11:11.080 --> 00:11:12.740
Ja, und Natalia ist auch jemand, dem man

00:11:12.740 --> 00:11:14.600
quasi den Geschmack zutraut, das

00:11:14.600 --> 00:11:15.780
richtig gut zu machen. Ja.

00:11:17.220 --> 00:11:18.420
Ja, ja, ja, also bekannt

00:11:18.420 --> 00:11:20.360
wie, er hat ja Trio

00:11:20.360 --> 00:11:22.420
geschrieben, also eine andere Implementation

00:11:22.420 --> 00:11:24.360
für so Async-Geschichten

00:11:24.360 --> 00:11:26.400
und eine andere

00:11:26.400 --> 00:11:27.760
Art, das zu machen. Er hat einen sehr

00:11:27.760 --> 00:11:30.440
tollen Artikel geschrieben, irgendwie

00:11:30.440 --> 00:11:32.080
für Structured Concurrency,

00:11:32.340 --> 00:11:34.260
den verlinke ich auch mal gerne

00:11:34.260 --> 00:11:36.340
oder sage Leuten, dass sie sich das mal durchlesen sollen.

00:11:37.720 --> 00:11:38.380
Ja, insofern,

00:11:38.600 --> 00:11:40.460
ja genau, das habe ich auch da direkt aufhorchen

00:11:40.460 --> 00:11:41.600
lassen, als ich gehört habe, wer das gemacht hat.

00:11:43.620 --> 00:11:44.420
Ja, auf der

00:11:44.420 --> 00:11:46.280
anderen Seite weiß ich jetzt nicht so genau. Also er

00:11:46.280 --> 00:11:47.980
schreibt, gut, er macht das jetzt in Rust, weil

00:11:47.980 --> 00:11:49.860
er wollte schon immer mal was von Rust machen.

00:11:50.300 --> 00:11:52.320
Ich weiß nicht genau, wo man das unbedingt, also alle Leute

00:11:52.320 --> 00:11:54.120
machen und haben irgendwie Dinge, Tooling in Rust.

00:11:56.180 --> 00:11:56.540
Bei

00:11:56.540 --> 00:11:58.200
JavaScript verstehe ich das so ein bisschen, weil

00:11:58.200 --> 00:12:00.300
die haben da, also jede Änderung

00:12:00.300 --> 00:12:02.120
im Code führt halt dazu, dass irgendwie so 20

00:12:02.120 --> 00:12:04.360
Transpiler, irgendwelche

00:12:04.360 --> 00:12:06.080
Linter, sonst was irgendwie loslaufen und Dinge machen.

00:12:06.960 --> 00:12:07.280
Und

00:12:07.280 --> 00:12:10.040
wenn dann jedes Mal so ein fetter Node.js-Prozess

00:12:10.040 --> 00:12:12.380
gestartet wird, dann

00:12:12.380 --> 00:12:14.260
dauert das, dann addiert sich das natürlich

00:12:14.260 --> 00:12:16.360
irgendwie auf in der Latenz. Aber Python

00:12:16.360 --> 00:12:18.200
hat man das ja jetzt so eigentlich auch nicht.

00:12:18.220 --> 00:12:20.260
Naja, aber immerhin hast du eine vorkompilierte Binary,

00:12:20.440 --> 00:12:22.100
die du irgendwie ausliefern kannst. Und in Rust ist das

00:12:22.100 --> 00:12:24.100
vielleicht so ein Typensicher und irgendwie ordentlich

00:12:24.100 --> 00:12:26.120
schnell. Und ich glaube, man kann

00:12:26.120 --> 00:12:28.200
die halt auch relativ leicht dann so statisch

00:12:28.200 --> 00:12:30.080
verlinken und hat halt wirklich nur eine

00:12:30.080 --> 00:12:31.980
Datei. Ja, genau. Ja, okay.

00:12:32.060 --> 00:12:33.780
Ansonsten hat man das Bootstrapping-Problem, dass man erstmal

00:12:33.780 --> 00:12:36.020
einen Package-Manager installieren muss, damit man sich

00:12:36.020 --> 00:12:38.040
den richtigen Package-Manager, also das Problem

00:12:38.040 --> 00:12:38.980
das Poetry hat mit dem

00:12:38.980 --> 00:12:41.600
curl und get Poetry

00:12:41.600 --> 00:12:43.820
schrecklich Schell-Skript irgendwie von

00:12:43.820 --> 00:12:45.340
einer Webseite ausführen. Ja. Ja.

00:12:45.840 --> 00:12:47.580
Ja, okay. Gut, das löst es. Das stimmt.

00:12:48.220 --> 00:12:49.900
Ja. Das sind so ein paar Sachen,

00:12:50.000 --> 00:12:51.860
die glaube ich gar nicht schlecht sind. Also ja, aber Rastor ist cool.

00:12:51.960 --> 00:12:54.000
Ich habe es auch mal ein bisschen ausprobiert in Advent of Cody.

00:12:54.620 --> 00:12:54.720
Aber

00:12:54.720 --> 00:12:57.700
die Weihnachtszeit ist ja jetzt schon wieder vorbei.

00:12:58.420 --> 00:12:59.460
Ich weiß nicht, was ich finde.

00:12:59.660 --> 00:13:01.960
Also das, was ich meistens

00:13:01.960 --> 00:13:03.500
verwende, ist halt für Pakete bauen

00:13:03.500 --> 00:13:05.780
Flit. Das macht eigentlich nur das.

00:13:06.100 --> 00:13:07.760
Ansonsten verwende ich für Abhängigkeit Pip-Tools.

00:13:09.880 --> 00:13:10.060
Und

00:13:10.060 --> 00:13:11.940
ja. Pip-Tools fand ich

00:13:11.940 --> 00:13:13.520
ja fürchterlich, aber du findest Poetry fürchterlich.

00:13:14.080 --> 00:13:15.460
Ich habe Poetry lange verwendet.

00:13:15.660 --> 00:13:17.660
Also fürchterlich ist...

00:13:17.660 --> 00:13:19.340
Ja, wir hatten uns ja, glaube ich, das war schon ein, zwei

00:13:19.340 --> 00:13:20.300
Folgen her, über dieses

00:13:20.300 --> 00:13:23.220
Problem mit den Dependencies irgendwie schon

00:13:23.220 --> 00:13:24.300
auseinandergesetzt noch.

00:13:26.540 --> 00:13:27.340
Warum das vielleicht

00:13:27.340 --> 00:13:29.220
blöd ist, aber ich sage mal so, theoretisch kann man

00:13:29.220 --> 00:13:31.260
die ja trotzdem einfach dann selber

00:13:31.260 --> 00:13:33.120
einstellen in der PyProject-Hummel.

00:13:34.700 --> 00:13:35.060
Ja, ja, das

00:13:35.060 --> 00:13:37.000
Problem ist, dass Poetry

00:13:37.000 --> 00:13:38.160
implizit halt,

00:13:39.540 --> 00:13:41.580
wenn man sagt Poetry add irgendein Paket,

00:13:42.200 --> 00:13:43.400
irgendwie ein

00:13:43.400 --> 00:13:44.440
Upper Bound auf die

00:13:44.440 --> 00:13:47.020
Version macht, was

00:13:47.020 --> 00:13:49.220
Wenn man eine Library schreibt, wo andere halt sehr blöd

00:13:49.220 --> 00:13:51.280
ist, weil die dann sofort in Dependency-Problemen

00:13:51.280 --> 00:13:52.840
laufen, Konflikte laufen.

00:13:53.220 --> 00:13:54.860
Man muss ja manuell quasi tatsächlich dann

00:13:54.860 --> 00:13:56.700
die Funktion wegnennen.

00:13:57.160 --> 00:13:57.560
Naja, gut.

00:13:58.660 --> 00:14:00.740
Das ist, glaube ich, eine gute Idee.

00:14:01.740 --> 00:14:02.920
Ich habe letztens gesehen, PipTools

00:14:02.920 --> 00:14:04.600
in PyProject Hummel irgendwie rein

00:14:04.600 --> 00:14:06.040
gemeldet.

00:14:07.460 --> 00:14:08.700
Letzte Woche war

00:14:08.700 --> 00:14:10.760
PyGDF-Treffen und

00:14:10.760 --> 00:14:13.040
Jens hat mir das mal

00:14:13.040 --> 00:14:15.080
erzählt, dass er das jetzt macht.

00:14:15.160 --> 00:14:16.940
Er benutzt PipTools. Ist auch nicht so super

00:14:16.940 --> 00:14:18.820
nicht hundertprozentig zufrieden, aber

00:14:18.820 --> 00:14:20.280
irgendwie

00:14:20.280 --> 00:14:23.060
benutzt man das auch häufiger

00:14:23.060 --> 00:14:25.060
und hat einen Weg gefunden, wie man das

00:14:25.060 --> 00:14:27.160
relativ einfach, die Abhängigkeiten auch in

00:14:27.160 --> 00:14:29.100
der PyProject-Tunnel da reinschreiben

00:14:29.100 --> 00:14:31.120
kann und hat mir mal gezeigt, wie man das macht.

00:14:31.240 --> 00:14:32.600
Das könnte ich auch verlinken, stimmt.

00:14:33.280 --> 00:14:34.260
Ist natürlich auch nicht so schlecht.

00:14:35.060 --> 00:14:37.080
Weil dann hat man alles wieder, weil das ist natürlich

00:14:37.080 --> 00:14:38.760
im Moment ist das ganze Packaging und

00:14:38.760 --> 00:14:40.980
Dependency-Management-Zeugs irgendwie relativ

00:14:40.980 --> 00:14:43.120
furchtbar. Das funktioniert

00:14:43.120 --> 00:14:44.920
auch nicht US-übergreifend gut und

00:14:44.920 --> 00:14:45.460
das ist

00:14:45.460 --> 00:14:48.440
ziemlich ein Mist. Ich hoffe ja wirklich, dass dieses

00:14:48.440 --> 00:14:49.620
RAS-Paket da einiges

00:14:49.620 --> 00:14:52.340
ändert, weil das

00:14:52.340 --> 00:14:53.240
will man so alles nicht haben.

00:14:54.960 --> 00:14:55.320
Ja.

00:14:56.360 --> 00:14:58.260
Wird uns noch eine Zeit lang begleiten, das sehen wir, glaube ich.

00:14:59.980 --> 00:15:00.340
Ja.

00:15:01.020 --> 00:15:01.380
Okay.

00:15:02.160 --> 00:15:03.360
Kommen wir zu erfreulicheren Dingen.

00:15:04.180 --> 00:15:06.120
Django gibt es jetzt eine neue Alpha-Version, also die

00:15:06.120 --> 00:15:07.580
Django 4.2 kommt

00:15:07.580 --> 00:15:09.400
im März irgendwann, hoffentlich.

00:15:09.900 --> 00:15:10.660
Ist das wieder die LTS?

00:15:12.320 --> 00:15:12.680
Ja.

00:15:13.800 --> 00:15:15.180
Genau, wobei das nicht so eine

00:15:15.180 --> 00:15:17.060
große Rolle spielt. Die offizielle Empfehlung an der Stelle ist

00:15:17.060 --> 00:15:19.240
immer, die letzte

00:15:19.240 --> 00:15:21.040
Stabile zu nehmen und nicht LTS. LTS

00:15:21.040 --> 00:15:23.080
ist mehr so, naja, es gibt halt Firmen, die das irgendwie

00:15:23.080 --> 00:15:25.100
haben wollen oder keine Ahnung, aber das ist nicht

00:15:25.100 --> 00:15:27.060
mehr so, wie man das machen sollte. Es wird nicht empfohlen,

00:15:27.220 --> 00:15:29.000
immer auf den LTS-Version zu bleiben.

00:15:29.460 --> 00:15:31.100
Dafür verändert sich auch einfach zu wenig.

00:15:31.400 --> 00:15:32.780
Also es gibt schon lange nicht mehr

00:15:32.780 --> 00:15:35.160
irgendwie so große Probleme, wenn man upgradet.

00:15:36.040 --> 00:15:36.980
Daher braucht man das eigentlich

00:15:36.980 --> 00:15:37.820
nicht mehr so wirklich.

00:15:38.800 --> 00:15:40.420
Genau, was dabei ist, ist

00:15:40.420 --> 00:15:43.160
ganz nett, PsychoPG3

00:15:43.160 --> 00:15:44.380
Support, das heißt Async

00:15:44.380 --> 00:15:47.180
Datenbank-Unterstützung

00:15:47.180 --> 00:15:48.800
kommt damit halt so, rückt näher.

00:15:48.800 --> 00:15:50.580
Es gibt ja jetzt auch ein Interface

00:15:50.580 --> 00:15:52.680
seit Django 4.1 für

00:15:52.680 --> 00:15:54.820
Async-Geschichten mit dem

00:15:54.820 --> 00:15:57.020
ORM. Ist alles noch nicht wirklich implementiert,

00:15:57.100 --> 00:15:58.840
aber das Interface ist schon mal da, sodass man das halt

00:15:58.840 --> 00:16:00.760
so verwenden kann, dass wenn irgendwann sich

00:16:00.760 --> 00:16:02.680
unten drunter das mal so verändert, dass halt mehrere

00:16:02.680 --> 00:16:04.740
Sachen gleichzeitig irgendwie an die

00:16:04.740 --> 00:16:05.860
Datenbank geschickt werden und dann

00:16:05.860 --> 00:16:08.760
zurückkommen, dass es einfach so,

00:16:08.820 --> 00:16:10.620
dass man einfach so davon profitiert und dass man selber

00:16:10.620 --> 00:16:12.540
nochmal was ändern muss. Das muss ich auch mal irgendwann

00:16:12.540 --> 00:16:14.160
verstehen, wie das mit der Datenbank funktionieren soll?

00:16:15.220 --> 00:16:16.600
Naja, du kannst, also im Grunde

00:16:16.600 --> 00:16:18.680
der OEM weiß ja, was er an Queries an die Datenbank

00:16:18.680 --> 00:16:20.520
schickt und der schickt dann, also was momentan

00:16:20.520 --> 00:16:22.460
so der übliche Weg ist halt, dass

00:16:22.460 --> 00:16:23.560
er halt ein

00:16:23.560 --> 00:16:26.540
Query nach dem anderen an die Datenbank

00:16:26.540 --> 00:16:28.220
schickt und die Latenzen sich alle aufaddieren.

00:16:28.600 --> 00:16:30.480
Das ist halt so, wie es, was jetzt,

00:16:30.640 --> 00:16:32.040
wenn man nicht so viele Queries macht und

00:16:32.040 --> 00:16:34.220
wenn man ein bisschen aufpasst, dann ist es auch nicht so schlimm.

00:16:34.680 --> 00:16:36.220
Aber kann natürlich schon sein, wenn man jetzt

00:16:36.220 --> 00:16:38.440
50 Queries hat und jede dauert

00:16:38.440 --> 00:16:40.260
10 Millisekunden, dann ist man natürlich bei einer halben Sekunde

00:16:40.260 --> 00:16:41.840
allein Datenbank-Latenz.

00:16:42.540 --> 00:16:44.820
Besser wäre es ja, wenn man alle gleichzeitig an die Datenbank

00:16:44.820 --> 00:16:46.860
schickt oder alle, die nicht voneinander

00:16:46.860 --> 00:16:48.640
abhängen, kann man gleichzeitig an die Datenbank schicken

00:16:48.640 --> 00:16:50.580
und dann hat man

00:16:50.580 --> 00:16:52.560
die Gesamtlatenz, nur die Latenz

00:16:52.560 --> 00:16:54.960
von dem Query, was am längsten

00:16:54.960 --> 00:16:55.920
dauert sozusagen.

00:16:56.780 --> 00:16:58.400
Und das könnte natürlich die

00:16:58.400 --> 00:17:00.700
Gesamtlatenz deutlich reduzieren. Also es wäre sehr nett, wenn

00:17:00.700 --> 00:17:01.260
das irgendwie ginge.

00:17:02.440 --> 00:17:04.180
Aber es ist natürlich eine sehr komplizierte Änderung.

00:17:04.340 --> 00:17:06.800
Aber da muss die Datenbank ja natürlich schon parallel auch rechnen können.

00:17:07.040 --> 00:17:09.000
Ja, das können die. Das können die alle.

00:17:09.300 --> 00:17:10.880
Und wie stellt die Datenbank

00:17:10.880 --> 00:17:12.080
sicher, dass sich jetzt keine

00:17:12.080 --> 00:17:14.220
Probleme

00:17:14.220 --> 00:17:16.100
hab, festzustellen, dass Dinge auf die

00:17:16.100 --> 00:17:17.240
gleichen Stellen zugreifen.

00:17:17.560 --> 00:17:20.300
Das ist ja so

00:17:20.300 --> 00:17:22.200
die Kernkompetenz eines Datenbankmanagements

00:17:22.200 --> 00:17:23.000
Systems sozusagen.

00:17:24.280 --> 00:17:25.460
Wie soll das denn gehen?

00:17:25.660 --> 00:17:28.200
Das Problem hast du jetzt ja auch schon, wenn du mehrere Frontends hast

00:17:28.200 --> 00:17:30.240
oder mehrere Prozesse auf deinem Frontend, die gleichzeitig

00:17:30.240 --> 00:17:31.260
alle irgendwie...

00:17:31.260 --> 00:17:34.040
Man muss ja gucken, dass sie einen Lock setzt dann irgendwie und dann muss sie

00:17:34.040 --> 00:17:36.120
gucken, ist das Lock auch da oder muss halt

00:17:36.120 --> 00:17:38.140
eins setzen, wenn sie da irgendwie dran rumfuchtelt und dann

00:17:38.140 --> 00:17:39.980
muss sie es wieder... Du meinst jetzt so Richtung

00:17:39.980 --> 00:17:42.160
Right zu Griff oder was? Ja. Ja, aber ich meine,

00:17:42.880 --> 00:17:44.140
dann schaust du halt eine Transaktion und

00:17:44.140 --> 00:17:45.680
siehst, dass dann, hast du eine

00:17:45.680 --> 00:17:47.200
konsistente Sicht der Dinge

00:17:47.200 --> 00:17:50.020
innerhalb der Transaktion oder die wird halt

00:17:50.020 --> 00:17:51.720
dann committed oder aborted und das

00:17:51.720 --> 00:17:53.800
ist, also ich glaube, ich stimme

00:17:53.800 --> 00:17:55.880
dir zu, dass, Jochen, zu, dass

00:17:55.880 --> 00:17:57.740
das halt genau das ist, was die Datenbank halt

00:17:57.740 --> 00:17:59.540
im Prinzip richtig gut können sollte.

00:18:00.100 --> 00:18:02.080
Also so. Aber das

00:18:02.080 --> 00:18:03.260
macht ihr doch eigentlich dann langsamer, oder?

00:18:03.760 --> 00:18:05.960
Ja, natürlich macht das alles, das macht alles viel langsamer,

00:18:05.960 --> 00:18:07.840
wenn man Transaktionen ausschaltet und F-Sync

00:18:07.840 --> 00:18:09.900
ausschaltet, dann wird das, wird eine Datenbank viel schneller.

00:18:09.980 --> 00:18:12.900
Also aber das Problem ist halt, dann sind halt deine Daten eventuell auch weg.

00:18:13.160 --> 00:18:14.460
Das ist ja doof.

00:18:14.500 --> 00:18:15.260
Das ist auch wieder doof.

00:18:15.580 --> 00:18:16.680
Wieder so ein Schritt auf den Haken.

00:18:17.720 --> 00:18:25.240
Also, aber dieses Problem hast du auch, wenn du zwei Frontends hast, die auf den gleichen Daten arbeiten, hast du das ja auch schon.

00:18:25.560 --> 00:18:29.540
Auch ohne, dass die Frontends in sich selber nochmal irgendwie Concurrent-Dinge machen.

00:18:30.020 --> 00:18:36.640
Die machen ja auch Sachen Concurrent auf Prozessebene oder auf Rechner-Ebene, die da auf die gleiche Datenbank zugreifen.

00:18:36.640 --> 00:18:39.140
Also das sollte eine Datenbank schon können?

00:18:39.980 --> 00:18:57.240
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.

00:18:57.240 --> 00:18:59.600
Das heißt, bisher war das kein Problem,

00:18:59.720 --> 00:19:00.640
weil man kann sowieso immer nur

00:19:00.640 --> 00:19:03.420
im Code synchron

00:19:03.420 --> 00:19:05.520
eins nach dem anderen machen. Aber jetzt

00:19:05.520 --> 00:19:07.020
kann man ja mehrere, das heißt, man muss auch mehrere

00:19:07.020 --> 00:19:09.220
Verbindungen aufmachen, weil

00:19:09.220 --> 00:19:10.780
halt immer nur ein Query pro Verbindung

00:19:10.780 --> 00:19:13.180
geht. Das heißt, da muss man

00:19:13.180 --> 00:19:15.740
dann halt intern poolen

00:19:15.740 --> 00:19:16.500
oder muss irgendwie

00:19:16.500 --> 00:19:18.660
außen poolen.

00:19:18.780 --> 00:19:21.160
Es ist sowieso alles sehr kompliziert. Auch die ganze

00:19:21.160 --> 00:19:22.520
Geschichte im OEM, was man dann umstellen muss,

00:19:22.520 --> 00:19:24.460
das wird noch lange dauern, bis das alles

00:19:24.460 --> 00:19:26.480
richtig funktioniert. Aber wenn es denn mal

00:19:26.480 --> 00:19:27.500
irgendwann funktioniert, das ist ja cool.

00:19:29.160 --> 00:19:30.140
Und das ist jetzt ein Schritt,

00:19:30.280 --> 00:19:32.660
weiterer Schritt dahin. Also wir haben jetzt Async-URM,

00:19:32.800 --> 00:19:34.340
Async-Views, Async-Tests.

00:19:34.980 --> 00:19:36.560
Ja, ja, Async-URM haben wir

00:19:36.560 --> 00:19:37.860
noch nicht. Wir haben nur die Interfaces.

00:19:38.920 --> 00:19:40.400
Jetzt auch den Support für eine

00:19:40.400 --> 00:19:42.400
Library, die man dafür braucht, um das überhaupt machen zu können.

00:19:42.540 --> 00:19:44.520
Das heißt, das letzte, was du nimmst, ist Async-URM.

00:19:45.660 --> 00:19:46.580
Genau, das

00:19:46.580 --> 00:19:48.340
ist halt auch noch das komplizierteste

00:19:48.340 --> 00:19:50.620
Stück Arbeit, was noch da bevorsteht.

00:19:50.620 --> 00:19:50.800
Genau.

00:19:52.780 --> 00:19:54.640
Dann, es gibt jetzt

00:19:54.640 --> 00:19:56.320
Unterstützung für Kommentare,

00:19:56.480 --> 00:19:57.960
für Spalten und Tabellen.

00:19:58.660 --> 00:20:00.580
Das ist irgendwie ein Issue, der ist seit

00:20:00.580 --> 00:20:02.460
Jahren offen und war irgendwie

00:20:02.460 --> 00:20:04.600
kompliziert zu fixen, ging nicht so gut. Aus welchen

00:20:04.600 --> 00:20:06.300
Gründen auch immer, ich weiß gar nicht genau. Das geht jetzt.

00:20:07.040 --> 00:20:08.460
Also wir haben irgendwie den Weg gefunden, wie sie das so

00:20:08.460 --> 00:20:09.740
hinkriegen, dass es kein Problem mehr ist.

00:20:10.720 --> 00:20:12.500
Und das, was ganz nett ist,

00:20:13.100 --> 00:20:13.480
dann

00:20:13.480 --> 00:20:16.360
früher, oder ab dann wird man halt

00:20:16.360 --> 00:20:17.620
eventuell, es gibt so

00:20:17.620 --> 00:20:20.460
Django in Memory Storage, ich weiß

00:20:20.460 --> 00:20:22.680
nicht genau, gibt es ein externes

00:20:22.680 --> 00:20:24.380
Paket nicht mehr brauchen, das ist dann auch in Django

00:20:24.380 --> 00:20:26.120
selber drin. Das heißt, man hat jetzt einen

00:20:26.120 --> 00:20:28.600
in Memory-Storage-Backend

00:20:28.600 --> 00:20:30.460
für Django mit dabei,

00:20:30.700 --> 00:20:32.340
dass man einfach so verwenden kann für Tests zum Beispiel.

00:20:33.200 --> 00:20:34.200
Macht halt Tests einfach schneller.

00:20:35.260 --> 00:20:36.600
Und, das freut mich

00:20:36.600 --> 00:20:38.640
besonders, es gibt jetzt

00:20:38.640 --> 00:20:41.160
eine Streaming-HTTP-Response

00:20:41.160 --> 00:20:43.080
mit Async-Iteraturen

00:20:43.080 --> 00:20:45.160
dran. Das ist im Grunde,

00:20:46.520 --> 00:20:46.980
wenn man jetzt

00:20:46.980 --> 00:20:48.520
zum Beispiel Files ausliefern will,

00:20:49.740 --> 00:20:51.160
ist das halt

00:20:51.160 --> 00:20:52.900
ein Problem. Das ging bisher nicht so gut,

00:20:53.000 --> 00:20:55.020
einfach deswegen, weil man

00:20:55.020 --> 00:20:57.200
da halt über die Blocks

00:20:57.200 --> 00:20:59.120
eines Files, die man rausschicken wollte, halt da

00:20:59.120 --> 00:21:01.140
so nicht Async drüber iteriert

00:21:01.140 --> 00:21:03.060
hat. Und

00:21:03.060 --> 00:21:04.880
genau, ich habe da ja mal

00:21:04.880 --> 00:21:05.860
auf der Django

00:21:05.860 --> 00:21:09.040
2021 einen Vortrag

00:21:09.040 --> 00:21:10.540
wie kann man eigentlich Files mit Django

00:21:10.540 --> 00:21:13.080
surfen gehalten. Da habe

00:21:13.080 --> 00:21:15.460
ich das halt, dieses Ding rausgepatcht

00:21:15.460 --> 00:21:16.720
irgendwie so per Monkey-Patching.

00:21:17.320 --> 00:21:19.240
Es gibt noch ein Paket, Django-File-Response,

00:21:19.360 --> 00:21:21.220
wo ich das so mache. Das ist dann nicht mehr nötig,

00:21:21.300 --> 00:21:22.800
weil das macht jetzt Async-Iterator. Das heißt,

00:21:22.800 --> 00:21:24.760
es müsste eigentlich Files surfen, müsste jetzt einfach so gehen.

00:21:25.020 --> 00:21:44.960
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?

00:21:44.960 --> 00:21:53.340
Ja, okay. Tja. Und PyCon.de oder PyData ist in Berlin 17. bis 19. April, da gehe ich wahrscheinlich auch hin.

00:21:53.680 --> 00:21:59.480
Euro-Pricen ist vom 17. bis zum 23. Juli.

00:21:59.660 --> 00:22:00.320
Okay, ein bisschen später.

00:22:00.320 --> 00:22:01.220
Aber ich weiß nicht wo.

00:22:02.000 --> 00:22:02.240
Okay.

00:22:02.720 --> 00:22:03.580
Das ist noch top secret.

00:22:05.960 --> 00:22:08.280
Damit auch ja keiner einen guten Flug buchen kann.

00:22:08.580 --> 00:22:08.940
Genau.

00:22:09.680 --> 00:22:11.280
Das wird in Europa passieren wahrscheinlich.

00:22:11.380 --> 00:22:12.960
Oder das ins Budget fürs Jahr einplanen kann.

00:22:13.760 --> 00:22:15.740
Für was auch immer.

00:22:16.700 --> 00:22:16.820
Ja.

00:22:17.360 --> 00:22:19.120
Ich glaube gerade das Management-Team hat da gewechselt.

00:22:20.600 --> 00:22:20.740
Ja.

00:22:20.940 --> 00:22:22.500
Ja, also die letzte

00:22:22.500 --> 00:22:24.420
hat noch Marc-André mit organisiert

00:22:24.420 --> 00:22:25.940
und jetzt machen das irgendwie andere Menschen.

00:22:27.220 --> 00:22:28.580
Die haben so eine

00:22:28.580 --> 00:22:29.800
neue Art und Weise wollen die machen mit

00:22:29.800 --> 00:22:32.400
wer das wie veranstaltet und sich was neues Konzept

00:22:32.400 --> 00:22:34.520
da überlegt. Mal gucken, ich bin gespannt.

00:22:35.640 --> 00:22:35.940
Jojo.

00:22:36.640 --> 00:22:37.740
Okay, ja, nee, dann

00:22:37.740 --> 00:22:39.860
das wäre ja nach nur fast

00:22:39.860 --> 00:22:41.460
20 Minuten mit den News durch,

00:22:41.860 --> 00:22:44.120
das ist mal relativ flott, dann

00:22:44.120 --> 00:22:45.820
kommen wir zum Hauptthema.

00:22:45.820 --> 00:22:47.740
Eine ganz schnelle Folge. Das glaube ich nicht.

00:22:48.080 --> 00:22:49.440
Pai Pai? Ja.

00:22:50.020 --> 00:22:54.300
Warum macht man damit nicht was schneller oder was ist der Zweck davon?

00:22:54.660 --> 00:22:55.820
Oder weißt du was, womit wir anfangen?

00:22:56.340 --> 00:22:57.280
Karl, wer bist du denn eigentlich?

00:22:57.500 --> 00:23:00.180
Hi, ich gebe jetzt schon die ganze Zeit so meinen Senf dazu.

00:23:01.440 --> 00:23:05.020
Aber ja, also ich bin Karl Friedrich Bolz-Tereik.

00:23:05.100 --> 00:23:09.200
Ich bin hier an der Uni ein wissenschaftlicher Angestellter in Düsseldorf

00:23:09.200 --> 00:23:14.880
und habe da eine halbe Stelle und bin im Prinzip angestellt,

00:23:14.880 --> 00:23:19.740
um eine Python-Einführung zu halten jedes Semester für Leute,

00:23:19.860 --> 00:23:20.840
die nicht Informatik studieren.

00:23:21.020 --> 00:23:22.860
Also das ist so Studium Universale mäßig.

00:23:24.320 --> 00:23:27.740
Und wenn ich die gemacht habe,

00:23:28.000 --> 00:23:30.660
kann ich die restliche Zeit so ein bisschen frei einteilen.

00:23:30.780 --> 00:23:33.060
Das ist eigentlich ein ganz angenehmer Deal.

00:23:34.000 --> 00:23:38.460
Und ich bin seit irgendwie 2005 ungefähr

00:23:38.460 --> 00:23:41.560
einer der Kernentwickler des PiPi-Projekts,

00:23:41.560 --> 00:23:44.740
über das wir jetzt auch dann gleich noch mehr reden wollen.

00:23:45.820 --> 00:23:48.060
Also ich habe da halt irgendwie am Anfang von meinem Studium angefangen.

00:23:48.200 --> 00:23:51.580
Ich war dann auch bei den EU-Projekten,

00:23:51.920 --> 00:23:56.040
die da am Anfang eine Zeit lang für Finanzierung gesorgt haben,

00:23:56.540 --> 00:23:58.880
recht intensiv involviert.

00:23:59.660 --> 00:24:02.580
Und bin halt so mit mal mehr, mal weniger Involvierung

00:24:02.580 --> 00:24:06.060
seitdem immer wieder halt dran beteiligt.

00:24:09.260 --> 00:24:10.980
Also an dem Open-Source-Funded-Ding,

00:24:11.060 --> 00:24:12.940
was dann PiPi direkt entwickelt.

00:24:14.160 --> 00:24:14.680
Genau.

00:24:14.880 --> 00:24:17.020
Also ich bin jetzt quasi einfach erst mal nur so,

00:24:17.320 --> 00:24:18.800
quasi in Anführungszeichen, also nur

00:24:18.800 --> 00:24:20.880
einer der Kernentwickler, also die halt quasi

00:24:20.880 --> 00:24:22.440
Commit Rights und

00:24:22.440 --> 00:24:25.080
Zeug machen. Ich bin aber halt auch

00:24:25.080 --> 00:24:27.200
einer der recht Aktiven im Moment.

00:24:27.800 --> 00:24:29.020
Also das Projekt

00:24:29.020 --> 00:24:31.220
schrumpft so ein bisschen, da können wir vielleicht später auch noch drüber reden.

00:24:32.120 --> 00:24:33.040
Und ich

00:24:33.040 --> 00:24:35.040
bin einer derjenigen, die jetzt halt gerade

00:24:35.040 --> 00:24:36.980
noch viel, recht viel machen.

00:24:39.920 --> 00:24:40.620
Genau, aber

00:24:40.620 --> 00:24:43.340
das Projekt hatte über seine Lebenszeit

00:24:43.340 --> 00:24:45.080
halt immer wieder auch Phasen, wo das wirklich

00:24:45.080 --> 00:24:46.340
auch viel Geld hatte.

00:24:47.320 --> 00:24:52.040
Also EU-Förderung, Forschungsförderung, immer mal wieder auch Geld von Firmen.

00:24:52.040 --> 00:25:00.260
Und bei einigen von diesen Forschungs- oder Förderungsprojekten war ich halt auch dann quasi aktiv dabei.

00:25:02.320 --> 00:25:04.980
Da musst du auch mal direkt erzählen, was PyPy überhaupt ist.

00:25:05.140 --> 00:25:08.840
Ja, genau. Das ist quasi die andere Frage.

00:25:09.100 --> 00:25:12.020
Also PyPy ist quasi eine Alternative für CPython.

00:25:12.120 --> 00:25:17.100
Wenn man halt irgendwie Python, in Python seine Programme schreibt,

00:25:17.220 --> 00:25:18.900
dann geht man halt normalerweise auf python.org

00:25:18.900 --> 00:25:21.020
oder vielleicht kriegt man das auch irgendwann das her,

00:25:21.020 --> 00:25:25.600
aber man hat halt ein Executable, das heißt Python 3 in der Regel oder Python.

00:25:26.400 --> 00:25:28.880
Das führt man aus und dann kriegt man halt irgendwie seine Shell

00:25:28.880 --> 00:25:32.860
und kann da Python-Code eingeben oder kann halt damit dann auch Python-Dateien ausführen

00:25:32.860 --> 00:25:36.400
und kann auf diese Art und Weise irgendwie seine Programme laufen lassen.

00:25:37.100 --> 00:25:46.800
Und dieses Programm, das wird halt von den Kernentwicklern der Sprache Python geschrieben

00:25:46.800 --> 00:25:50.020
und das gibt quasi vor, wie sich die Sprache entwickelt.

00:25:50.760 --> 00:25:55.520
Und dieses Programm ist in C geschrieben und deswegen kann man das halt auch,

00:25:55.520 --> 00:25:59.300
um es von der Sprache zu unterscheiden, kann man das halt auch C-Python nennen.

00:26:00.180 --> 00:26:02.820
Also das ist quasi so ein bisschen so ein Terminologie-Trick,

00:26:03.120 --> 00:26:05.840
dass man halt quasi die Sprache und die Implementierung,

00:26:06.380 --> 00:26:07.580
dass man denen zwei verschiedene Namen gibt.

00:26:07.720 --> 00:26:08.980
Also Python ist halt dann die Sprache

00:26:08.980 --> 00:26:11.980
und das ist quasi erstmal so eine abstrakte Entität

00:26:11.980 --> 00:26:13.380
und dann gibt es aber halt die konkrete Implementierung,

00:26:13.460 --> 00:26:14.660
die man fast immer verwendet

00:26:14.660 --> 00:26:16.040
und das ist halt CPython.

00:26:16.820 --> 00:26:18.180
Und CPython funktioniert jetzt so,

00:26:18.260 --> 00:26:19.580
dass es halt ein Interpreter ist.

00:26:19.780 --> 00:26:20.600
Also wenn ich jetzt damit

00:26:20.600 --> 00:26:22.040
irgendwie meinen Python-Code ausführen will,

00:26:22.780 --> 00:26:24.760
dann gibt es so ein bisschen

00:26:24.760 --> 00:26:27.120
so einen versteckten Bytecode-Compiler-Schritt.

00:26:27.900 --> 00:26:31.900
Also der Python-Code wird dann irgendwie analysiert

00:26:31.900 --> 00:26:34.240
und geparst und in so ein Bytecode-Format übersetzt

00:26:34.240 --> 00:26:36.080
und dann werden auch so

00:26:36.080 --> 00:26:38.640
PYC-Dateien irgendwo

00:26:38.640 --> 00:26:39.960
auf der Festplatte auch noch so ein bisschen

00:26:39.960 --> 00:26:42.620
zwischengespeichert, damit man das nicht jedes Mal machen muss.

00:26:43.120 --> 00:26:44.620
Aber dieser White-Code, der wird halt

00:26:44.620 --> 00:26:46.280
dann jedes Mal von einem Interpreter ausgeführt.

00:26:47.700 --> 00:26:47.800
Und

00:26:47.800 --> 00:26:50.860
was

00:26:50.860 --> 00:26:52.260
Piper jetzt ist, ist quasi

00:26:52.260 --> 00:26:53.800
der Versuch,

00:26:54.580 --> 00:26:56.340
Python-Code schneller zu machen.

00:26:56.920 --> 00:26:58.680
Also es ist ja immer

00:26:58.680 --> 00:27:00.480
so ein bisschen so ein Meme, dass Python halt irgendwie

00:27:00.480 --> 00:27:02.120
besonders langsam sein soll und

00:27:02.120 --> 00:27:17.300
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.

00:27:17.300 --> 00:27:34.140
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.

00:27:34.460 --> 00:27:36.720
Vielleicht nochmal ganz kurz, PyPy ist nicht PyPI?

00:27:37.260 --> 00:27:43.420
Genau, also P-Y-P-Y. Das ist so ein bisschen doof, dass die so ähnlich sind.

00:27:44.240 --> 00:27:46.300
Ja, weil man von PyPI ja auch viel runterlädt.

00:27:46.300 --> 00:28:02.180
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.

00:28:02.260 --> 00:28:09.320
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?

00:28:09.320 --> 00:28:19.640
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.

00:28:20.040 --> 00:28:20.400
Ja.

00:28:20.620 --> 00:28:26.280
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?

00:28:26.860 --> 00:28:27.140
Nee.

00:28:27.900 --> 00:28:30.180
Naja, im Cheese-Shop gibt es halt Käseräder.

00:28:30.740 --> 00:28:30.980
Ja.

00:28:31.440 --> 00:28:33.920
Und die Wheels sind halt Käse.

00:28:34.100 --> 00:28:34.760
Okay, ah.

00:28:35.180 --> 00:28:35.820
Also, ja.

00:28:36.020 --> 00:28:36.180
Okay.

00:28:36.180 --> 00:28:38.780
Ja, okay, verstehe.

00:28:39.100 --> 00:28:40.480
Und deswegen gibt es Reels auf

00:28:40.480 --> 00:28:43.060
Pipe.pi. Genau, und irgendwann haben die halt

00:28:43.060 --> 00:28:44.980
dann aufgehört mit diesem, weil Cheese Shop ist halt

00:28:44.980 --> 00:28:45.800
doch sehr

00:28:45.800 --> 00:28:49.180
idiosynkratisch oder verspielt.

00:28:49.440 --> 00:28:50.280
Ist vielleicht eine positive...

00:28:50.280 --> 00:28:53.020
Der erste Draftname für unseren Podcast war

00:28:53.020 --> 00:28:55.140
Ministry of Silly Talk. Ah ja, alles klar, nicht schlecht.

00:28:56.140 --> 00:28:57.140
Und also

00:28:57.140 --> 00:28:59.140
irgendwann wurde halt Pipe.pi dann ein bisschen

00:28:59.140 --> 00:29:00.720
ernsthafter und hat halt angefangen, dann

00:29:00.720 --> 00:29:02.940
sich nicht mehr das Cheese Shop zu nennen.

00:29:03.040 --> 00:29:05.140
Und dann wurde halt die Verwechslungsgefahr plötzlich

00:29:05.140 --> 00:29:07.400
dann auch akuter. Aber weil halt

00:29:07.400 --> 00:29:09.100
PyPI und PyPi ziemlich

00:29:09.100 --> 00:29:11.480
genau gleich alt sind, also PyPI ist ein kleines

00:29:11.480 --> 00:29:13.340
bisschen älter, so ein paar Monate oder so,

00:29:14.200 --> 00:29:15.520
haben halt beide Projekte

00:29:15.520 --> 00:29:17.620
nicht so richtig eingesehen, sich jetzt umzubenennen.

00:29:17.880 --> 00:29:19.320
Und deswegen müssen wir

00:29:19.320 --> 00:29:20.300
jetzt halt mit dieser

00:29:20.300 --> 00:29:23.420
Verwirrung leben. Genau, also wir waren

00:29:23.420 --> 00:29:25.120
an dem Punkt, man kann von PyPi.org sich

00:29:25.120 --> 00:29:27.460
ein Binary unterladen, das heißt PyPi.exe

00:29:27.460 --> 00:29:28.860
oder halt einfach nur PyPi.

00:29:29.360 --> 00:29:30.860
Und das verhält sich eigentlich

00:29:30.860 --> 00:29:33.320
idealerweise ganz genau so, wie

00:29:33.320 --> 00:29:35.300
das Binary, was man von Python.org

00:29:35.300 --> 00:29:37.080
kriegt. Man kann damit Python-Code

00:29:37.080 --> 00:29:38.240
ausführen, man kann damit

00:29:38.240 --> 00:29:41.220
einen interaktiven Interpreter kriegen und

00:29:41.220 --> 00:29:43.320
alle Command-Line-Switches

00:29:43.320 --> 00:29:44.800
sind die gleichen und verhält sich genau gleich.

00:29:44.960 --> 00:29:46.500
Mit dem einzigen Unterschied, dass

00:29:46.500 --> 00:29:49.160
der Python-Code, den man

00:29:49.160 --> 00:29:50.800
damit ausführt, halt hoffentlich schneller ist.

00:29:51.820 --> 00:29:53.080
Was ist mit Paketen und

00:29:53.080 --> 00:29:54.900
Libraries und so weiter? Genau, also

00:29:54.900 --> 00:29:57.080
alles, was quasi in Python geschrieben ist,

00:29:57.160 --> 00:29:58.240
sollte halt gehen.

00:29:58.960 --> 00:30:00.700
Wir haben natürlich ab und zu Bugs, also

00:30:00.700 --> 00:30:03.120
es gibt immer irgendwelche super

00:30:03.120 --> 00:30:05.080
spezifischen Feinheiten,

00:30:05.600 --> 00:30:06.920
wo man dann halt doch so ein bisschen

00:30:06.920 --> 00:30:09.080
Verhaltensunterschiede finden kann.

00:30:09.760 --> 00:30:11.380
Aber so der Anspruch an uns selber ist halt,

00:30:11.440 --> 00:30:13.400
dass wir quasi wirklich das komplette

00:30:13.400 --> 00:30:14.480
Verhalten der Sprache

00:30:14.480 --> 00:30:17.620
eins zu eins

00:30:17.620 --> 00:30:19.620
nachbauen und zwar bis in die Bugs rein.

00:30:19.940 --> 00:30:21.480
Also es gibt halt immer wieder so

00:30:21.480 --> 00:30:23.560
Randfälle, wo man dann anfangen kann zu diskutieren und sagen kann,

00:30:23.640 --> 00:30:25.640
naja, was ist denn jetzt mit diesem Randfall?

00:30:25.820 --> 00:30:27.200
Könnte man dann nicht argumentieren, dass

00:30:27.200 --> 00:30:28.580
C-Python da halt irgendwas komisches macht?

00:30:29.180 --> 00:30:31.280
Aber das machen wir halt nicht, sondern wir sagen halt immer

00:30:31.280 --> 00:30:34.220
im Zweifelsfall bauen wir halt auch die ganz, ganz

00:30:34.220 --> 00:30:36.280
komischen Sachen nach, weil es stellt

00:30:36.280 --> 00:30:37.260
sich halt raus, dass

00:30:37.260 --> 00:30:40.100
irgendjemand verlässt sich so ein bisschen auf

00:30:40.100 --> 00:30:41.960
alles. Also es gibt eigentlich

00:30:41.960 --> 00:30:44.240
keinen Randfall, der so

00:30:44.240 --> 00:30:46.260
merkwürdig ist, dass es nicht eine Bibliothek gibt,

00:30:46.920 --> 00:30:48.180
irgendwie eine kleine vielleicht,

00:30:48.700 --> 00:30:50.160
die halt sich dann beschwert, wenn man

00:30:50.160 --> 00:30:52.140
das kaputt macht. Also selbst

00:30:52.140 --> 00:30:54.300
wenn man halt dann sagt, naja, wir sind aber viel konsistenter

00:30:54.300 --> 00:30:55.620
und das macht ja so viel mehr Sinn, nee.

00:30:58.000 --> 00:31:00.120
Das ist halt doof. Für so eine Bibliothek ist das doof,

00:31:00.220 --> 00:31:03.240
wenn sie halt dann so unterscheiden muss,

00:31:03.440 --> 00:31:06.000
auf welcher Python-Implementierung sie jetzt gerade laufen.

00:31:06.000 --> 00:31:09.840
Und deswegen versuchen wir da halt auch nichts mehr zu verbessern

00:31:09.840 --> 00:31:13.960
oder irgendwie, ja, es gibt natürlich trotzdem Stellen.

00:31:14.080 --> 00:31:15.300
Also wir haben halt dann, was weiß ich,

00:31:15.400 --> 00:31:17.620
mal eine leicht andere Fehlermeldung in irgendeinem Fall oder so.

00:31:17.720 --> 00:31:19.160
So was kommt halt schon vor.

00:31:21.180 --> 00:31:23.820
Aber so, also vom Anspruch her sollte sich halt genau gleich verhalten.

00:31:24.360 --> 00:31:27.360
Und der einzige Unterschied ist quasi wirklich idealerweise,

00:31:27.640 --> 00:31:30.220
dass bei uns die Programme halt viel schneller laufen.

00:31:30.820 --> 00:31:33.940
Und warum macht man das dann nicht direkt immer mit PyPy alles?

00:31:34.320 --> 00:31:38.180
Ja, also genau, jetzt können wir so ein bisschen über die Nachteile reden.

00:31:38.180 --> 00:31:44.080
Also das eine ist halt, wir sind halt nicht die maßgebende Implementierung,

00:31:44.240 --> 00:31:48.200
die jetzt die Evolution der Sprache selbst vorgibt.

00:31:49.560 --> 00:31:51.580
Also CPython hat halt so eine Doppelfunktion.

00:31:52.160 --> 00:31:56.260
Das ist einmal die Default-Implementierung,

00:31:56.340 --> 00:31:57.720
die halt von fast allen verwendet wird.

00:31:58.040 --> 00:32:02.260
Aber auf der anderen Seite ist es halt auch die Gruppe an Leuten,

00:32:03.020 --> 00:32:04.620
die letztlich darüber entscheiden,

00:32:05.220 --> 00:32:06.840
in welche Richtung sich die Sprache weiterentwickelt.

00:32:07.380 --> 00:32:10.120
Weil in jeder neuen Version von C-Python ist es ja so,

00:32:10.200 --> 00:32:11.800
dass da eben nicht nur, jetzt sage ich mal,

00:32:11.800 --> 00:32:13.160
irgendwie technische Verbesserungen

00:32:13.160 --> 00:32:14.920
an der Implementierung gemacht werden.

00:32:15.340 --> 00:32:16.620
Das kommt natürlich auch mal vor.

00:32:16.880 --> 00:32:18.200
Also jetzt sind 3F zum Beispiel ganz toll.

00:32:19.100 --> 00:32:21.500
Aber insbesondere gibt es halt auch bei jeder Version

00:32:21.500 --> 00:32:22.420
irgendwelche neuen Sprachfeatures.

00:32:23.100 --> 00:32:25.820
Das heißt, python.org, diese Community,

00:32:25.900 --> 00:32:27.640
ist halt für zwei Sachen zuständig. Einmal

00:32:27.640 --> 00:32:29.920
dafür, dass das alles funktioniert, aber auf der

00:32:29.920 --> 00:32:31.740
anderen Seite eben auch für so Fragen wie

00:32:31.740 --> 00:32:33.720
welches PEP nehmen wir an, welches neue

00:32:33.720 --> 00:32:36.000
Language-Feature wollen wir haben, welche neue

00:32:36.000 --> 00:32:37.540
Standard-Bibliothek,

00:32:38.380 --> 00:32:39.480
so Geschichten. Und da,

00:32:39.760 --> 00:32:41.860
also da sind wir halt raus. Also aus diesen ganzen

00:32:41.860 --> 00:32:43.960
Sprachdesign-Fragen, da haben

00:32:43.960 --> 00:32:45.860
wir keine Meinung zu. Ihr nehmt euch dann einfach

00:32:45.860 --> 00:32:47.820
das offizielle Release und dann

00:32:47.820 --> 00:32:49.940
das darf ein CPython und baut das dann eure

00:32:49.940 --> 00:32:51.960
Änderung ein. Ganz genau. Und es ist schon

00:32:51.960 --> 00:32:54.140
dann mal so, dass wir bei den CPython-

00:32:54.140 --> 00:32:55.780
Diskussionen dann auch mitreden und sagen, ja, aus unserer

00:32:55.780 --> 00:32:56.980
Sicht hat das die und die,

00:32:58.040 --> 00:32:59.740
also gibt es jetzt hier diese Trade-offs oder so,

00:32:59.900 --> 00:33:01.820
aber wir versuchen uns halt

00:33:01.820 --> 00:33:03.400
so erstmal aus Sprach

00:33:03.400 --> 00:33:06.100
Design-Fragen auch irgendwie erstmal rauszuhalten.

00:33:06.940 --> 00:33:07.780
Also einfach auch,

00:33:07.860 --> 00:33:09.420
weil das unser Leben so ein bisschen leichter macht, dann

00:33:09.420 --> 00:33:11.660
gibt es halt, ich meine, ich habe da

00:33:11.660 --> 00:33:13.640
natürlich dann quasi so privat auch manchmal eine

00:33:13.640 --> 00:33:15.580
Meinung dazu, was es jetzt an Featuren gibt und

00:33:15.580 --> 00:33:16.960
manche finde ich cool und manche finde ich

00:33:16.960 --> 00:33:19.480
weniger cool. Also ich meine, das geht ja allen

00:33:19.480 --> 00:33:21.560
Python-Programmierern so, dass man halt

00:33:21.560 --> 00:33:23.620
eine Meinung hat, aber wenn ich dann quasi

00:33:23.620 --> 00:33:26.000
meinen Pai-Pai-Hut aufhabe,

00:33:26.080 --> 00:33:27.660
dann versuche ich diese private Meinung

00:33:27.660 --> 00:33:28.960
halt dann auch zurückzunehmen und zu sagen,

00:33:29.840 --> 00:33:31.700
das ist jetzt halt so, das ist Teil der Sprache und das

00:33:31.700 --> 00:33:33.680
implementieren wir jetzt halt. Also du bist ja eigentlich gar kein

00:33:33.680 --> 00:33:35.280
Dein-Python-Programmierer, hast du selber gesagt.

00:33:35.620 --> 00:33:37.920
Ja, über die Architektur reden wir gleich noch.

00:33:38.440 --> 00:33:39.520
Also irgendwie dann schon,

00:33:39.820 --> 00:33:41.740
aber halt auf ein bisschen indirekte Art und Weise.

00:33:42.200 --> 00:33:42.860
Also ja,

00:33:43.720 --> 00:33:45.660
ich wollte noch was zu den Versionen sagen. Wir sind

00:33:45.660 --> 00:33:46.980
immer so ein bisschen hinterher.

00:33:48.200 --> 00:33:49.840
Das ist nicht so gut. Also eigentlich

00:33:49.840 --> 00:33:51.740
haben wir so ein bisschen den Anspruch, dass wir

00:33:51.740 --> 00:33:53.540
quasi eine Major-Version hinterher sind.

00:33:53.620 --> 00:33:55.960
weil, also

00:33:55.960 --> 00:33:57.500
wir können halt nicht Schritt halten

00:33:57.500 --> 00:33:59.400
C-Python hat halt einfach viel mehr Leute

00:33:59.400 --> 00:34:00.780
und die

00:34:00.780 --> 00:34:03.080
die rennen uns halt davon

00:34:03.080 --> 00:34:05.860
und was halt so ein bisschen unser Ziel ist, ist, dass

00:34:05.860 --> 00:34:07.840
wir quasi immer so eine

00:34:07.840 --> 00:34:09.880
Major-Version hinterher sind, das ist auch

00:34:09.880 --> 00:34:11.900
immer ganz gut, wenn dann quasi

00:34:11.900 --> 00:34:13.860
3.11 rauskommt, dann haben so

00:34:13.860 --> 00:34:15.940
langsam alle Bibliotheken sich drauf eingestellt

00:34:15.940 --> 00:34:17.840
dass sie 3.10 supporten und wenn

00:34:17.840 --> 00:34:19.800
wir dann auch mit unseren 3.10 rauskommen, dann passt das

00:34:19.800 --> 00:34:20.480
so ganz gut zusammen

00:34:20.480 --> 00:34:22.860
Gerade sind wir ein bisschen

00:34:22.860 --> 00:34:24.940
mehr, also wir haben jetzt nicht so krass getaktete

00:34:24.940 --> 00:34:26.600
Releases wie C-Python, sondern

00:34:26.600 --> 00:34:28.520
das wird halt

00:34:28.520 --> 00:34:30.760
wir machen alle paar Monate Release, aber das heißt nicht

00:34:30.760 --> 00:34:32.780
unbedingt, dass dann auch die neue C-Python

00:34:32.780 --> 00:34:33.200
Version

00:34:33.200 --> 00:34:36.320
supported wird

00:34:36.320 --> 00:34:37.760
und gerade sind wir so ein bisschen hinterher

00:34:37.760 --> 00:34:40.740
3.9 ist jetzt eigentlich sehr sehr stabil

00:34:40.740 --> 00:34:42.320
und 3.10

00:34:42.320 --> 00:34:44.900
ist in der Mache, aber noch nicht released

00:34:44.900 --> 00:34:46.300
und danach kommt halt dann

00:34:46.300 --> 00:34:48.600
3.11, also das ist ein quasi

00:34:48.600 --> 00:34:50.140
ein Nachteil, warum man Piper halt nicht

00:34:50.140 --> 00:34:51.400
nehmen sollte,

00:34:52.360 --> 00:34:53.440
ist ein bisschen hinterher.

00:34:54.360 --> 00:34:55.780
Und dann habe ich vorhin gesagt,

00:34:56.020 --> 00:34:57.860
naja, jedes Python-Programm sollte halt gehen

00:34:57.860 --> 00:34:59.340
und idealerweise schneller sein.

00:34:59.860 --> 00:35:02.040
Da gibt es jetzt zwei Fußnoten an dieser

00:35:02.040 --> 00:35:04.120
Aussage. Die eine Fußnote ist halt

00:35:04.120 --> 00:35:04.960
C-Extensions.

00:35:05.620 --> 00:35:06.480
Und NumPy ist kaputt?

00:35:06.900 --> 00:35:09.960
Nee, kaputt halt nicht. Also inzwischen ist das

00:35:09.960 --> 00:35:11.740
so, dass wir so eine komplette

00:35:11.740 --> 00:35:13.640
Kompatibilitätsschicht haben,

00:35:14.360 --> 00:35:15.720
mit der, sag ich mal,

00:35:16.420 --> 00:35:17.620
80% aller

00:35:17.620 --> 00:35:20.200
in C-geschriebenen Bibliotheken

00:35:20.200 --> 00:35:21.400
in Piper auch gehen.

00:35:22.340 --> 00:35:24.000
Aber, das ist wirklich,

00:35:24.400 --> 00:35:26.020
wir emulieren halt dieses Interface.

00:35:26.420 --> 00:35:28.260
Für C-Python ist das Interface halt wirklich

00:35:28.260 --> 00:35:30.240
genau so, wie der Interpreter

00:35:30.240 --> 00:35:31.100
auch wirklich funktioniert.

00:35:31.860 --> 00:35:33.860
Und der Interpreter benutzt halt Reference-Counting

00:35:33.860 --> 00:35:36.400
und die C-API,

00:35:36.700 --> 00:35:38.340
die hat halt

00:35:38.340 --> 00:35:40.520
überall die Tatsache, dass das Reference-Counting

00:35:40.520 --> 00:35:41.920
ist exposed. Es gibt halt

00:35:41.920 --> 00:35:44.880
ein Increase-Reference-Count-Makro

00:35:44.880 --> 00:35:46.600
und ein Decrease-Reference-Count-Makro

00:35:46.600 --> 00:35:48.620
und alle Libraries, die dann

00:35:48.620 --> 00:35:50.760
gegen diese API implementiert sind,

00:35:50.820 --> 00:35:52.420
die müssen das halt überall auch korrekt verwenden.

00:35:53.240 --> 00:35:54.980
Aber bei uns ist es so, dass wir unseren

00:35:54.980 --> 00:35:56.680
Speicher halt nicht mit Reference Counting verwalten.

00:35:57.300 --> 00:35:58.520
Das heißt, wir müssen dann für

00:35:58.520 --> 00:36:00.900
die Bibliotheken so tun, als hätten wir

00:36:00.900 --> 00:36:02.680
einen Reference Count. Und das ist halt,

00:36:02.780 --> 00:36:04.820
das kostet halt so ein bisschen Performance. Das heißt, bei uns

00:36:04.820 --> 00:36:06.840
sind in C geschriebener Erweiterung

00:36:06.840 --> 00:36:08.800
halt quasi, die funktionieren,

00:36:09.340 --> 00:36:10.980
die können aber halt oft

00:36:10.980 --> 00:36:12.340
einfach langsamer sein.

00:36:12.940 --> 00:36:14.040
Und das ist natürlich doof, weil

00:36:14.040 --> 00:36:16.360
Ein Massenpaket, das schneller sein will,

00:36:16.400 --> 00:36:18.460
aber die Sachen sind langsamer, als wenn du die eigentlich auf normalem

00:36:18.460 --> 00:36:20.320
Python-Offenheitsmittel hast. Genau, ja, ja. Also ich meine,

00:36:20.380 --> 00:36:22.260
der Grund, warum man, es gibt ja so ein bisschen

00:36:22.260 --> 00:36:24.600
zwei Motivationen, warum man in C geschrieben die Bibliotheken

00:36:24.600 --> 00:36:26.460
verwendet. Einmal, weil man halt gerne mit

00:36:26.460 --> 00:36:27.660
irgendwelchen Bibliotheken geschrieben

00:36:27.660 --> 00:36:30.200
reden will, die halt in C geschrieben sind.

00:36:30.340 --> 00:36:31.920
Das ist halt ein Ansatz. Aber ein anderer

00:36:31.920 --> 00:36:34.420
Grund ist halt, wenn man irgendwas schneller machen will,

00:36:34.420 --> 00:36:36.560
indem man es in C schreibt. Und diese

00:36:36.560 --> 00:36:38.440
Motivation, die funktioniert halt dann

00:36:38.440 --> 00:36:40.460
auf PyPy oft nicht. Und das

00:36:40.460 --> 00:36:42.440
wäre dann zum Teil einfach auch echt besser, wenn man

00:36:42.440 --> 00:36:43.960
halt einfach Python-Code nehmen würde,

00:36:44.740 --> 00:36:46.320
aber weil halt für C-Python alle

00:36:46.320 --> 00:36:48.180
jetzt schon ihre tollen NC-geschriebenen Optimierungen

00:36:48.180 --> 00:36:50.100
gemacht haben, ist das dann für uns

00:36:50.100 --> 00:36:51.720
oft auch halt eine Verschlechterung.

00:36:52.140 --> 00:36:54.120
Also, ja.

00:36:54.580 --> 00:36:56.160
Könnte man da nicht vielleicht einfach auch

00:36:56.160 --> 00:36:58.360
den C aus PyPy heraus

00:36:58.360 --> 00:37:00.340
irgendwie einfach den C-Python-Interpreter

00:37:00.340 --> 00:37:01.880
wieder aufrufen und den diesen

00:37:01.880 --> 00:37:03.700
Kram händeln lassen? Ja,

00:37:04.060 --> 00:37:06.480
da gab es auch immer mal wieder so ein paar Experimente,

00:37:07.040 --> 00:37:08.380
aber dann verliert man halt, also man

00:37:08.380 --> 00:37:10.420
will halt, dann verliert

00:37:10.420 --> 00:37:12.360
man halt möglicherweise die Vorteile für den Python-Code,

00:37:12.440 --> 00:37:14.380
wieder. Also, weil das Problem ist, du willst ja

00:37:14.380 --> 00:37:16.320
halt beide Seiten auch miteinander reden lassen. Ja, wenn du

00:37:16.320 --> 00:37:18.420
halt nur C-Code hast, dann

00:37:18.420 --> 00:37:20.300
ist halt eh die Frage, warum du eigentlich, was

00:37:20.300 --> 00:37:21.520
hast du da noch mit Python zu tun?

00:37:22.660 --> 00:37:24.460
Spannend wird es halt dann, wenn du quasi Python,

00:37:25.180 --> 00:37:26.460
also wenn dein Programm halt wirklich aus

00:37:26.460 --> 00:37:27.980
interessanten Teilen auf der Python-Seite

00:37:27.980 --> 00:37:29.940
besteht und interessanten Teilen auf der

00:37:29.940 --> 00:37:33.380
Bibliotheksseite.

00:37:33.980 --> 00:37:36.180
Die andere Fußnote ist, dass es manchmal nicht

00:37:36.180 --> 00:37:37.380
klappt. Also es gibt halt,

00:37:38.280 --> 00:37:39.940
manchmal hat man wirklich in Python geschrieben

00:37:39.940 --> 00:37:40.780
Code und

00:37:40.780 --> 00:37:43.780
der wird nicht schneller.

00:37:44.180 --> 00:37:45.020
Also man muss halt einfach

00:37:45.020 --> 00:37:48.140
messen. Um mal so ein bisschen

00:37:48.140 --> 00:37:49.720
so eine Größenordnung zu nennen,

00:37:49.960 --> 00:37:52.320
wir haben halt so Speedups

00:37:52.320 --> 00:37:54.540
zwischen, so im allerbesten

00:37:54.540 --> 00:37:56.180
Fall, wenn halt alles ganz toll ist

00:37:56.180 --> 00:37:58.140
und du Pure Python Code hast, gar keine Bibliothek

00:37:58.140 --> 00:38:00.100
in C geschrieben ist und das

00:38:00.100 --> 00:38:02.040
ist alles jetzt, sag ich mal, sehr numerisch. Also hast

00:38:02.040 --> 00:38:03.960
viele Zahlen

00:38:03.960 --> 00:38:06.000
und irgendwie viele Floats oder, aber du machst

00:38:06.000 --> 00:38:08.100
das auch wirklich alles in Python. Dann kannst du halt so

00:38:08.100 --> 00:38:10.160
Speedups von 50 mal

00:38:10.160 --> 00:38:12.180
schneller als CPython kriegen. Also das ist halt, das ist

00:38:12.180 --> 00:38:14.260
schon, also alle Leute, die halt so was

00:38:14.260 --> 00:38:16.100
wie Advent of Code machen, ja,

00:38:16.360 --> 00:38:18.280
Advent of Code ist eigentlich so,

00:38:18.720 --> 00:38:20.240
ich scherze, aber ist irgendwie auch was

00:38:20.240 --> 00:38:22.100
Wahres dran. Advent of Code ist halt irgendwie einer der

00:38:22.100 --> 00:38:24.280
Haupt-coolen Use Cases

00:38:24.280 --> 00:38:26.480
für PyPy. Es ist halt

00:38:26.480 --> 00:38:28.060
irgendwie nicht so viel Code, es passt auf ein paar

00:38:28.060 --> 00:38:30.320
Bildschirme, es ist irgendwie sehr algorithmisch

00:38:30.320 --> 00:38:31.900
und man braucht nicht so viele Bibliotheken

00:38:31.900 --> 00:38:34.200
und das wird halt dann, und Performance ist irgendwie

00:38:34.200 --> 00:38:36.060
auch wichtig und da ist halt PyPy einfach

00:38:36.060 --> 00:38:36.780
mega gut dafür.

00:38:38.780 --> 00:38:40.060
Genau, und weil, also bei

00:38:40.060 --> 00:38:41.740
Performance ist es halt so, man muss halt einfach messen.

00:38:41.980 --> 00:38:46.420
Also du kannst halt nicht quasi so a priori entscheiden,

00:38:46.560 --> 00:38:50.500
dass es immer jetzt Speed-Up X bringt,

00:38:50.780 --> 00:38:53.080
sondern es führt quasi keinen Weg darum,

00:38:53.220 --> 00:38:55.720
dass du deine konkrete Anwendung halt ausprobierst und schaust,

00:38:56.420 --> 00:38:58.120
bringt es was oder halt nicht.

00:38:58.120 --> 00:38:59.300
Habt ihr da irgendwie ein Referenzsystem

00:38:59.300 --> 00:39:02.180
oder macht ihr das einfach immer so objektiv von dem über den Rechner?

00:39:03.860 --> 00:39:05.080
Du meinst jetzt quasi,

00:39:05.840 --> 00:39:08.000
inwiefern das von der darunterliegenden Hardware abhängt?

00:39:08.260 --> 00:39:08.900
Ja, zum Beispiel, ja.

00:39:10.060 --> 00:39:11.860
Das ist, glaube ich, nicht so ein Problem.

00:39:12.100 --> 00:39:15.180
Wir unterstützen so einen Haufen CPU-Architekturen,

00:39:15.320 --> 00:39:18.100
aber da sind wir nicht so sensitiv.

00:39:18.160 --> 00:39:19.340
Es geht eigentlich dann eher darum,

00:39:19.780 --> 00:39:21.260
was für Bibliotheken benutzt dein Projekt

00:39:21.260 --> 00:39:23.880
und sind die eher so C-lastig oder was.

00:39:25.000 --> 00:39:26.600
Es gibt halt Teile der Sprache,

00:39:26.680 --> 00:39:28.700
wo wir einfach richtig, richtig gut drin sind,

00:39:28.780 --> 00:39:29.480
die schneller zu machen.

00:39:30.060 --> 00:39:30.960
Und Teile der Sprache,

00:39:31.100 --> 00:39:33.900
wo wir dann nicht ganz so viel rausholen können.

00:39:34.540 --> 00:39:36.200
Wie viel lernt C-Python von euch?

00:39:37.280 --> 00:39:38.420
Das ist eine gute Frage.

00:39:39.840 --> 00:39:41.920
Achso, ich wollte kurz die andere Abschätzung, also im besten Fall

00:39:41.920 --> 00:39:43.880
so 30-40x, ich antworte gleich

00:39:43.880 --> 00:39:46.080
und im schlechtesten Fall ist man

00:39:46.080 --> 00:39:47.960
halt auch mal 30%

00:39:47.960 --> 00:39:49.900
langsamer und das ist halt dann doof, da will man halt dann

00:39:49.900 --> 00:39:50.360
nicht sein.

00:39:51.740 --> 00:39:53.620
C-Python, also

00:39:53.620 --> 00:39:55.960
ich habe manchmal

00:39:55.960 --> 00:39:57.660
so quasi so Momente

00:39:57.660 --> 00:39:59.660
des Zweifelns, ich

00:39:59.660 --> 00:40:01.700
verbringe seit 18 Jahren

00:40:01.700 --> 00:40:03.780
ein Teil meiner

00:40:03.780 --> 00:40:05.640
Freizeit und irgendwie

00:40:05.640 --> 00:40:08.160
ein Teil meines Berufs damit, an diesem Projekt zu basteln

00:40:08.160 --> 00:40:08.680
und

00:40:08.680 --> 00:40:11.100
so richtig,

00:40:12.100 --> 00:40:13.400
also, was weiß ich,

00:40:13.580 --> 00:40:15.620
99% von allen Deployments sind halt

00:40:15.620 --> 00:40:17.660
dem C-Python. Und man kann sich dann halt die Frage

00:40:17.660 --> 00:40:19.780
stellen, warum macht man

00:40:19.780 --> 00:40:21.500
das eigentlich? Also

00:40:21.500 --> 00:40:23.680
mir macht das natürlich irgendwie einfach unglaublich viel

00:40:23.680 --> 00:40:25.640
Spaß, also ich bastel da gerne dran rum, aber

00:40:25.640 --> 00:40:27.800
es ist natürlich auch schön, dann so ein bisschen so

00:40:27.800 --> 00:40:29.880
quasi externe Motivationen aufzukriegen.

00:40:30.640 --> 00:40:30.940
Und

00:40:30.940 --> 00:40:33.660
klar, es gibt immer wieder Leute,

00:40:33.660 --> 00:40:35.760
die das halt dann benutzen und das ist halt auch sehr cool,

00:40:36.000 --> 00:40:37.720
aber es gibt halt

00:40:37.720 --> 00:40:39.680
immer wieder auch Momente, wo wir dann quasi so

00:40:39.680 --> 00:40:39.980
Rück,

00:40:41.060 --> 00:40:42.980
so Rück,

00:40:44.060 --> 00:40:45.580
politische Rückauswirkungen auf

00:40:45.580 --> 00:40:47.620
C-Python haben. Und das ist quasi

00:40:47.620 --> 00:40:49.480
meiner Ansicht nach auch so ein bisschen so

00:40:49.480 --> 00:40:51.840
ein, so ein, der zweite

00:40:51.840 --> 00:40:53.600
Grund, warum ich halt der Ansicht bin,

00:40:53.660 --> 00:40:55.620
dass es eine gute Sache ist, dass es

00:40:55.620 --> 00:40:57.860
eine zweite, sehr ernsthafte

00:40:57.860 --> 00:40:59.320
Implementierung der Sprache Python gibt.

00:40:59.960 --> 00:41:00.960
Weil wir quasi,

00:41:01.520 --> 00:41:03.320
Also doch so ein bisschen Feature-Entwicklung

00:41:03.320 --> 00:41:05.480
durch die Hintertür. So ein bisschen Feature-Entwicklung

00:41:05.480 --> 00:41:07.380
durch die Hintertür, ganz genau. Und das ist zum Beispiel

00:41:07.380 --> 00:41:09.080
interessanterweise bei den Fehlermeldungen passiert.

00:41:10.100 --> 00:41:11.520
Also so ein paar

00:41:11.520 --> 00:41:13.000
von den, das war 3.10?

00:41:13.700 --> 00:41:14.860
Ja, 3.10 und 3.11.

00:41:15.280 --> 00:41:17.520
Ja, da bleibt das Verbesserung.

00:41:18.160 --> 00:41:19.180
Und bei beiden,

00:41:19.740 --> 00:41:21.480
also ich will jetzt wirklich nicht

00:41:21.480 --> 00:41:23.660
Keine Credits claimen.

00:41:23.700 --> 00:41:24.880
Ich will keine Credits claimen.

00:41:25.280 --> 00:41:27.100
Ich will auf gar keinen Fall, also was Pablo

00:41:27.100 --> 00:41:29.140
und Batoan Toskaya und sowas,

00:41:29.240 --> 00:41:30.800
was die da an Aufwand reingesteckt haben,

00:41:31.320 --> 00:41:33.400
unglaublich nervig

00:41:33.400 --> 00:41:35.120
und auch wirklich

00:41:35.120 --> 00:41:37.360
sehr, sehr cool. Ich bin sehr zufrieden

00:41:37.360 --> 00:41:39.080
mit einer Verbesserung. Wie gesagt, ich unterrichte Anfänger.

00:41:39.200 --> 00:41:40.660
Ich kriege das quasi immer mit, wenn das

00:41:40.660 --> 00:41:42.760
halt mal schief geht mit den Fehlermeldungen.

00:41:43.460 --> 00:41:45.220
Aber so ein bisschen

00:41:45.220 --> 00:41:47.000
so der ursprüngliche Drive

00:41:47.000 --> 00:41:48.900
kam halt so ein bisschen von Piper. Also zum Beispiel dieses

00:41:48.900 --> 00:41:51.200
mit den nicht gematchten

00:41:51.200 --> 00:41:53.080
Klammern. Das ist ja so einer der neuen Fehlermeldungen,

00:41:53.200 --> 00:41:55.120
dass es halt steht, die öffnende

00:41:55.120 --> 00:41:56.900
Klammer, die öffnende Ecke Klammer auf

00:41:56.900 --> 00:41:58.800
Zeile 5 wird mit einer runden schließenden Klammer

00:41:58.800 --> 00:42:01.020
auf Zeile 9 geschlossen. Da stimmt

00:42:01.020 --> 00:42:03.040
das nicht. Das war halt

00:42:03.040 --> 00:42:04.900
einfach, das habe ich einfach vor ein paar Jahren mal

00:42:04.900 --> 00:42:06.900
implementiert. Und irgendwann hat es halt

00:42:06.900 --> 00:42:08.680
in Zepa hätten dann doch jemand mal gesehen und

00:42:08.680 --> 00:42:10.280
fand es cool genug, um es halt dann doch

00:42:10.280 --> 00:42:12.920
halt auch dann mal quasi

00:42:12.920 --> 00:42:14.140
nachzuimplementieren. Und

00:42:14.140 --> 00:42:16.820
jetzt ist es so ein bisschen, fast so ein bisschen so ein

00:42:16.820 --> 00:42:18.820
Race manchmal. Also gerade

00:42:18.820 --> 00:42:20.700
haben die ganz schön auch vorgelegt.

00:42:21.080 --> 00:42:22.860
Also so ein paar der Fehlermeldungen

00:42:22.860 --> 00:42:24.580
haben wir jetzt noch nicht wieder übernommen.

00:42:25.300 --> 00:42:27.040
Aber an ein paar Stellen gibt's

00:42:27.040 --> 00:42:28.540
halt immer noch ein paar, wo ich

00:42:28.540 --> 00:42:30.160
mit unseren dann zufrieden bin. Zum Beispiel

00:42:30.160 --> 00:42:32.820
so ein absoluter Standard

00:42:32.820 --> 00:42:34.080
Anfängerfehler, wo man halt

00:42:34.080 --> 00:42:36.880
echt Riesenprobleme hat, wenn man

00:42:36.880 --> 00:42:38.640
in Python einsteigt, wenn man so

00:42:38.640 --> 00:42:40.980
Objektorientierung lernt und man schreibt halt seine ersten Klassen

00:42:40.980 --> 00:42:42.880
und schreibt Methoden und kommt halt vielleicht

00:42:42.880 --> 00:42:44.780
von Java und vergisst das

00:42:44.780 --> 00:42:46.740
Self. Und dann

00:42:46.740 --> 00:42:48.320
versucht man, die Methode aufzurufen.

00:42:49.020 --> 00:42:50.900
Erstes Argument fehlt. Und dann

00:42:50.900 --> 00:42:52.820
stimmt halt die Argumentzahl nicht. Und dann

00:42:52.820 --> 00:42:54.460
vergleicht man halt einfach mal die Aufrufstelle

00:42:54.460 --> 00:42:55.760
mit

00:42:55.760 --> 00:42:58.420
der Funktionsdefinition und sagt,

00:42:58.720 --> 00:43:00.720
was ist denn eigentlich dein Problem? Ich hab ja doch

00:43:00.720 --> 00:43:02.580
drei Argumente, warum beschwerst du dich denn,

00:43:02.820 --> 00:43:04.540
dass ich da nur zwei reinreiche?

00:43:05.720 --> 00:43:06.440
Oder, ja, so,

00:43:06.520 --> 00:43:07.960
das stimmt ja dann immer nicht.

00:43:08.700 --> 00:43:09.220
Und da

00:43:09.220 --> 00:43:12.220
mache ich in PyPy einfach nur,

00:43:12.560 --> 00:43:14.240
wenn es quasi einen

00:43:14.240 --> 00:43:16.540
off-by-one-error bei einem Methodenaufruf

00:43:16.540 --> 00:43:18.520
gibt, genau in diese Richtung,

00:43:19.160 --> 00:43:20.340
dann schaut der

00:43:20.340 --> 00:43:22.080
Interpreter nach, ob das erste Argument

00:43:22.080 --> 00:43:24.340
self heißt. Und wenn

00:43:24.340 --> 00:43:26.240
nicht, steht einfach nur noch da,

00:43:26.740 --> 00:43:28.640
did you forget self in the method definition.

00:43:28.640 --> 00:43:30.520
Ja, das wäre wahrscheinlich

00:43:30.520 --> 00:43:30.940
eine gute Idee.

00:43:31.620 --> 00:43:33.620
Ja, keine Ahnung, das ist natürlich, also

00:43:33.620 --> 00:43:36.500
bei diesen Fehlermeldungen ist es halt

00:43:36.500 --> 00:43:38.460
auch wirklich so, du hast halt einfach tausend

00:43:38.460 --> 00:43:40.400
Fehler, also das ist auch nicht übertrieben, es gibt halt

00:43:40.400 --> 00:43:42.640
ganz, ganz viele Stellen im Interpreter,

00:43:42.720 --> 00:43:44.520
wo halt Fehler produziert werden und

00:43:44.520 --> 00:43:46.380
jede einzelne ist halt dann irgendwie vielleicht

00:43:46.380 --> 00:43:47.520
auch gar nicht so wichtig, also

00:43:47.520 --> 00:43:50.240
diese Arbeit an Fehlermeldungen, die ist halt

00:43:50.240 --> 00:43:52.360
wirklich auch in gewisser Weise sehr nervig, weil man

00:43:52.360 --> 00:43:54.240
sich um jede einzelne irgendwie halt Gedanken

00:43:54.240 --> 00:43:56.320
machen muss und da gibt es halt

00:43:56.320 --> 00:43:57.820
auch keine Shortcuts so, also das

00:43:57.820 --> 00:44:00.280
aber das ist halt eine, wo ich mal

00:44:00.280 --> 00:44:02.260
dann so einen Tag dran Spaß hatte, mir zu überlegen,

00:44:02.320 --> 00:44:03.920
wie man das halt vielleicht verbessern kann und

00:44:03.920 --> 00:44:06.320
aber ich, also ich bin

00:44:06.320 --> 00:44:08.400
halt, ich habe so ein bisschen

00:44:08.400 --> 00:44:10.280
wie gesagt, ich will keinen

00:44:10.280 --> 00:44:11.440
Credit klauen, aber ich habe so ein bisschen

00:44:11.440 --> 00:44:14.460
das Gefühl, dass wir da einfach so ein bisschen

00:44:14.460 --> 00:44:16.200
so einen Push gegeben haben, so einen Initial-Push.

00:44:16.380 --> 00:44:17.440
Wir hatten halt an vielen Stellen

00:44:17.440 --> 00:44:20.280
da so ein paar Sachen dann

00:44:20.280 --> 00:44:21.740
zuerst implementiert und das

00:44:21.740 --> 00:44:24.220
fließt jetzt ganz stark in den Zielpreisen ein, da bin ich

00:44:24.220 --> 00:44:25.360
einfach mega glücklich drüber.

00:44:26.060 --> 00:44:27.920
Das ist der Forscherdrang, der so ein bisschen auch

00:44:27.920 --> 00:44:29.620
in die richtige Richtung geht. Der was?

00:44:29.860 --> 00:44:32.040
Der Forscherdrang. Ja,

00:44:32.040 --> 00:44:33.440
keine Ahnung, das ist jetzt nicht mein

00:44:33.440 --> 00:44:36.020
Forschungsgebiet. Das war

00:44:36.020 --> 00:44:37.800
eher so ein bisschen, ich habe halt dann wirklich

00:44:37.800 --> 00:44:39.820
gesehen, dass es für die Studenten echt dann zum Teil

00:44:39.820 --> 00:44:41.680
wirklich blöd ist. Zum Beispiel auch mit diesen,

00:44:42.180 --> 00:44:43.300
das wurde jetzt auch abgeschafft,

00:44:44.320 --> 00:44:45.840
ich glaube jetzt auch

00:44:45.840 --> 00:44:47.980
in 3.11, also, oder in 3.10,

00:44:48.080 --> 00:44:49.840
ich weiß nicht so, also zum Teil gab es

00:44:49.840 --> 00:44:52.080
diese Fehlermeldung, diese Syntax-Fehlermeldung,

00:44:52.140 --> 00:44:53.800
die echt so ganz komische Abkürzungen drin hatten,

00:44:54.440 --> 00:44:55.820
die halt einfach nicht ausgeschrieben waren.

00:44:56.480 --> 00:44:57.860
Insbesondere bei, zum Beispiel, wenn man

00:44:57.860 --> 00:44:59.940
die, wenn man die,

00:44:59.940 --> 00:45:01.680
die, die

00:45:01.680 --> 00:45:02.960
Quotes vergessen hat beim String.

00:45:03.660 --> 00:45:05.060
Also einfach nur x gleich

00:45:05.060 --> 00:45:07.220
Anführungszeichen A, B, C und dann hast du hinten die Quotes

00:45:07.220 --> 00:45:09.240
vergessen. Da war früher die Fehlermeldung

00:45:09.240 --> 00:45:11.520
irgendwie

00:45:11.520 --> 00:45:13.160
EOL while scanning

00:45:13.160 --> 00:45:14.320
String Literal.

00:45:14.560 --> 00:45:16.520
Ein Teil ist runter oder sowas auch noch gezeigt.

00:45:16.680 --> 00:45:17.940
Genau, ganz genau.

00:45:18.640 --> 00:45:20.840
Und das haben sie jetzt gefixt, das heißt jetzt halt wirklich

00:45:20.840 --> 00:45:22.680
End of Line, weil ich meine,

00:45:23.920 --> 00:45:24.840
woher soll irgendjemand

00:45:24.840 --> 00:45:26.080
wissen, was EOL heißt?

00:45:26.320 --> 00:45:28.740
Was Scanning heißt und auch noch was String Literal

00:45:28.740 --> 00:45:28.980
heißt.

00:45:30.320 --> 00:45:32.260
Und das ist jetzt wirklich schöner und das ist

00:45:32.260 --> 00:45:34.340
Zum Beispiel in Triple Quoted String sagt er dir jetzt auch

00:45:34.340 --> 00:45:35.080
die Fehlermeldung,

00:45:36.680 --> 00:45:38.220
wo, ähm, wo dir,

00:45:39.000 --> 00:45:40.440
also, da war die Fehlermeldung halt

00:45:40.440 --> 00:45:42.020
immer in der allerletzten Zeile der Datei.

00:45:43.000 --> 00:45:44.440
Weil er sucht

00:45:44.440 --> 00:45:45.880
ja einfach immer weiter.

00:45:45.880 --> 00:45:47.980
Bei Triple Quoted String ist es halt einfach dann

00:45:47.980 --> 00:45:50.020
wahrscheinlich der ganze Rest quasi, der da drin liegt.

00:45:50.340 --> 00:45:51.780
Und am Schluss ist halt, da fehlt was dann.

00:45:52.200 --> 00:45:53.440
Und jetzt, das ist jetzt wirklich,

00:45:53.780 --> 00:45:55.160
das wurde in 3.10 gefixt,

00:45:55.780 --> 00:45:57.780
ist es jetzt halt so, dass er dir wirklich dann die Zeile zeigt,

00:45:57.880 --> 00:45:59.600
wo die öffnenden Triple Quotes sind.

00:45:59.680 --> 00:46:00.680
Und das ist natürlich viel schöner.

00:46:01.340 --> 00:46:04.960
Und die andere Zeilennummer kommt aber auch vor in der Fehlermeldung.

00:46:05.080 --> 00:46:06.240
Das heißt, du hast dann wirklich beides.

00:46:07.240 --> 00:46:10.900
Und ja, also das ist alles schon sehr, sehr cool.

00:46:10.900 --> 00:46:16.860
Und ich meine, in 3.11, die Position Informations,

00:46:17.340 --> 00:46:18.520
die sind halt auch so ein bisschen,

00:46:19.160 --> 00:46:21.220
das war quasi noch ein bisschen fieser von mir.

00:46:21.280 --> 00:46:22.660
Das hatte ich noch nicht mal implementiert.

00:46:23.280 --> 00:46:24.820
Da habe ich nur so einen Screenshot gefakt,

00:46:25.740 --> 00:46:31.260
wo ich halt einfach nur im Editor einfach mal so diese Tilde

00:46:31.260 --> 00:46:33.280
unter den Teil des Ausdrucks gemacht habe, wo der Fehler

00:46:33.280 --> 00:46:35.140
herkommt. Dann habe ich einen Screenshot

00:46:35.140 --> 00:46:37.140
davon getwittert und das hat

00:46:37.140 --> 00:46:39.640
Pablo

00:46:39.640 --> 00:46:41.420
gesehen und dann super

00:46:41.420 --> 00:46:43.320
aufwendig. Es ist ein wirklich sehr

00:46:43.320 --> 00:46:45.220
nerviges Feature. Ja, das glaube ich.

00:46:45.420 --> 00:46:47.480
Ich habe mich schon gefragt, wie

00:46:47.480 --> 00:46:48.940
das implementiert wurde, weil das

00:46:48.940 --> 00:46:51.320
ist ja cool, aber oh mein Gott, wie ist das

00:46:51.320 --> 00:46:53.380
denn implementiert? Wie kriegt man das denn

00:46:53.380 --> 00:46:55.220
alles raus an den Stellen? Man muss halt wirklich einfach

00:46:55.220 --> 00:46:57.380
die gesamte Information durch den gesamten

00:46:58.020 --> 00:46:59.680
Stack so durchfädeln

00:46:59.680 --> 00:47:18.840
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.

00:47:18.940 --> 00:47:28.600
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.

00:47:28.600 --> 00:47:30.620
Und da hatte ich halt diesen Tweet gefakt und jetzt gibt's das.

00:47:30.840 --> 00:47:33.440
Also das ist mega geil, das sollte ich einfach öfter machen.

00:47:34.540 --> 00:47:38.740
Und also ich muss das jetzt, das kommt dann wieder zu mir zurück,

00:47:38.840 --> 00:47:41.140
weil wenn wir dann 3.11 unterstützen, dann muss ich das ja auch implementieren.

00:47:41.720 --> 00:47:45.460
Also insofern habe ich jetzt mich da ein Stück weit auch selber mit reingelegt,

00:47:45.560 --> 00:47:47.820
aber dass es jetzt halt in C-Python drin ist, finde ich einfach mega cool.

00:47:47.820 --> 00:47:51.460
Ja, dann weiß man halt schon, dass es sich lohnen wird, das zu implementieren.

00:47:52.220 --> 00:47:54.820
Und ich meine, das andere große Feature, wo wir halt dann quasi so ein bisschen,

00:47:58.200 --> 00:47:59.820
also jetzt nicht Druck ausgeübt,

00:47:59.900 --> 00:48:01.960
aber halt dann quasi Einfluss

00:48:01.960 --> 00:48:03.900
produziert haben, sind halt

00:48:03.900 --> 00:48:04.760
die Ordered Dictionaries.

00:48:05.420 --> 00:48:07.660
Ach, okay. Also das ist ja

00:48:07.660 --> 00:48:08.860
in 3.6, glaube ich.

00:48:09.640 --> 00:48:11.040
Informell, das weiß ich nicht.

00:48:11.740 --> 00:48:13.740
Aber 3.7 wird dann auch tatsächlich garantiert.

00:48:14.020 --> 00:48:15.740
In 3.6 haben sie halt gesagt, ihr dürft euch nicht

00:48:15.740 --> 00:48:17.460
darauf verlassen, dass die Dictionaries jetzt

00:48:17.460 --> 00:48:19.120
in der Einführungsreihenfolge

00:48:19.120 --> 00:48:21.960
sind. Und in 3.7

00:48:21.960 --> 00:48:23.540
haben sie dann gesagt,

00:48:23.660 --> 00:48:25.560
na, das funktioniert so gut, dass wir jetzt halt

00:48:25.560 --> 00:48:27.040
sagen, wir werden das auch nicht wieder abschaffen.

00:48:27.340 --> 00:48:29.400
Man darf sich jetzt darauf verlassen, weil es halt an ganz vielen Stellen

00:48:29.400 --> 00:48:30.640
echt auch viele Vorteile hat.

00:48:31.480 --> 00:48:32.720
Und das ist ein Pi-Pi-Feature.

00:48:33.220 --> 00:48:34.680
Achso, okay, das war gar nicht klar.

00:48:34.900 --> 00:48:37.560
Da gab es halt von Raymond Pettinger, gab es mal so ein

00:48:37.560 --> 00:48:39.420
Prototyp, aber in Python, in Pure Python.

00:48:40.820 --> 00:48:41.420
Und wir haben

00:48:41.420 --> 00:48:43.440
halt einfach gesagt, das sieht halt

00:48:43.440 --> 00:48:44.740
als Algorithmus echt gut aus.

00:48:45.180 --> 00:48:47.320
Und wir machen jetzt das ganze Engineering,

00:48:47.420 --> 00:48:49.480
was man halt braucht, um

00:48:49.480 --> 00:48:51.460
das dann wirklich quasi in Produktiveinsatz

00:48:51.460 --> 00:48:53.280
in die Implementierung einzubauen.

00:48:53.760 --> 00:48:55.480
Das haben wir halt einfach dann irgendwann mal gemacht.

00:48:56.260 --> 00:49:00.940
Und zwar noch nicht mal für unsere drei, sechs Versionen, sondern halt für unsere zwei, sieben Versionen.

00:49:01.820 --> 00:49:05.900
Also bei uns sind halt Dictionaries schon immer, also nicht schon immer, aber jetzt schon seit ungefähr zehn Jahren irgendwie geordnet.

00:49:06.620 --> 00:49:10.180
Und das war auch ganz schön, also dann, das war auch dann schon noch ein ganz schwieriger Aufwand.

00:49:10.460 --> 00:49:15.420
Also dieser Python-Code war halt so ein, jetzt Sketch wäre ein bisschen untertrieben,

00:49:16.600 --> 00:49:22.580
hat halt den Algorithmus so irgendwie präsentiert.

00:49:22.580 --> 00:49:41.860
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.

00:49:41.860 --> 00:49:55.600
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.

00:49:56.440 --> 00:50:13.220
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.

00:50:15.380 --> 00:50:22.120
Und ich meine, das ist ja eigentlich auch ganz cool, weil es ist halt wirklich, ich meine, das ist ja ein extra Feature.

00:50:22.600 --> 00:50:23.220
Intuitiv irgendwie.

00:50:23.440 --> 00:50:35.660
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.

00:50:35.660 --> 00:50:44.220
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.

00:50:45.380 --> 00:50:56.120
Ä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.

00:50:56.900 --> 00:51:02.480
Wie macht man das jetzt? Macht man quasi so ein extra dazu, das immer noch von den Hashwerten abhängt? Oder, äh.

00:51:03.040 --> 00:51:15.140
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.

00:51:15.380 --> 00:51:17.360
und dann würde man halt erstmal

00:51:17.360 --> 00:51:19.480
denken, dass man halt da plötzlich

00:51:19.480 --> 00:51:21.560
ganz viel Speicher irgendwie mehr

00:51:21.560 --> 00:51:23.300
braucht, weil man diese

00:51:23.300 --> 00:51:24.000
Indirektion hat

00:51:24.000 --> 00:51:27.300
und da gibt es halt dann so einen Trick und das ist wirklich

00:51:27.300 --> 00:51:29.360
auch das, was ich nicht verstanden

00:51:29.360 --> 00:51:31.240
hätte vorher, bevor die Leute

00:51:31.240 --> 00:51:33.520
sich halt ausgedacht haben, der Trick ist jetzt

00:51:33.520 --> 00:51:35.460
die Hashmap, die darf ja nicht voll sein

00:51:35.460 --> 00:51:36.680
weil du sonst Collisions kriegst

00:51:36.680 --> 00:51:38.900
also wenn du quasi

00:51:38.900 --> 00:51:40.960
wenn deine

00:51:40.960 --> 00:51:43.380
Hashmap irgendwie zu voll wird, dann musst du halt irgendwie

00:51:43.380 --> 00:51:45.360
die verdoppeln, um sie

00:51:45.360 --> 00:51:46.540
herzustellen, dass...

00:51:46.540 --> 00:51:48.160
Und nächstes Mal speicherfrei ist, wo du irgendwas reinkriegst.

00:51:48.160 --> 00:51:50.160
Genau, ja. Und der Trick ist jetzt

00:51:50.160 --> 00:51:50.740
aber, dass

00:51:50.740 --> 00:51:52.460
du

00:51:52.460 --> 00:51:56.100
mit dieser Indirektion jetzt

00:51:56.100 --> 00:51:58.360
den großen Teil

00:51:58.360 --> 00:52:00.500
einfach

00:52:00.500 --> 00:52:01.600
linear speicherst.

00:52:02.800 --> 00:52:04.080
Also du kannst dann,

00:52:04.360 --> 00:52:06.020
diese Lücken fallen dann weg.

00:52:06.820 --> 00:52:07.980
Die Lücken sind nur noch in deiner

00:52:07.980 --> 00:52:10.140
Indirektion drin, aber nicht mehr

00:52:10.140 --> 00:52:12.100
in deinem wirklichen Array, wo

00:52:12.100 --> 00:52:14.040
halt für jeden Eintrag ein

00:52:14.040 --> 00:52:15.860
Hash ein Key und ein Value gespeichert werden.

00:52:17.200 --> 00:52:18.240
Weil ein Eintrag

00:52:18.240 --> 00:52:20.120
von einem Dictionary besteht ja quasi aus

00:52:20.120 --> 00:52:22.080
drei Maschinenwörtern und

00:52:22.080 --> 00:52:24.100
wenn die dann quasi immer noch so Lücken haben,

00:52:24.660 --> 00:52:26.000
hast du halt ständig Lücken, die

00:52:26.000 --> 00:52:27.580
alle drei Maschinenwörter groß sind.

00:52:28.080 --> 00:52:29.980
Aber wenn du die Indirektion einbaust,

00:52:30.120 --> 00:52:31.780
dann ist quasi ein Eintrag nur noch

00:52:31.780 --> 00:52:34.120
ein Index in den

00:52:34.120 --> 00:52:36.400
dichten, in den dichtgespeicherten

00:52:36.400 --> 00:52:38.140
Insertion Order

00:52:38.140 --> 00:52:38.600
Speicher.

00:52:39.820 --> 00:52:42.080
So, jetzt sind wir an dem Punkt, wo wir eigentlich gerne ein Bild

00:52:42.080 --> 00:52:42.600
malen würden.

00:52:43.080 --> 00:52:45.540
Und vielleicht ist dann der Blogpost,

00:52:46.160 --> 00:52:47.380
ich finde den mal

00:52:47.380 --> 00:52:48.420
und wir verlinken den dann, aber

00:52:48.420 --> 00:52:51.300
für mich war es halt erstmal nicht klar, dass es

00:52:51.300 --> 00:52:53.540
wirklich auch wirklich eine gute Idee ist, das so zu machen.

00:52:54.000 --> 00:52:55.040
Also ist es aber.

00:52:55.460 --> 00:52:56.940
Also stellt sich halt raus, es ist es.

00:52:58.340 --> 00:52:58.860
Ja, cool.

00:53:00.220 --> 00:53:01.180
Echt, genau.

00:53:01.960 --> 00:53:03.360
Dann hat man quasi dann

00:53:03.360 --> 00:53:05.360
für drüber iterieren, muss man dann einfach nur noch

00:53:05.360 --> 00:53:07.660
durch die echte Liste gehen und es gar nichts mehr macht.

00:53:07.900 --> 00:53:09.320
Das Iterieren ist halt auch besser, weil

00:53:09.320 --> 00:53:10.980
vorher war es halt so,

00:53:11.300 --> 00:53:13.640
Man musste quasi über die Hashmap drüber iterieren

00:53:13.640 --> 00:53:15.180
und bei jedem Eintrag gucken,

00:53:15.620 --> 00:53:16.800
ist das überhaupt ein Eintrag oder nicht.

00:53:17.620 --> 00:53:20.320
Jetzt kann man aber quasi über den

00:53:20.320 --> 00:53:22.000
dichten Speicher drüber iterieren,

00:53:22.100 --> 00:53:24.180
wo einfach alle Einträge gültige Einträge sind.

00:53:25.400 --> 00:53:26.480
Und man muss halt gar nicht mehr,

00:53:26.560 --> 00:53:28.380
man verliert auch ein If

00:53:28.380 --> 00:53:29.980
in jedem Next-Aufruf.

00:53:31.900 --> 00:53:33.140
Also vorher war es so,

00:53:33.180 --> 00:53:34.460
dass man quasi in einem Next-Aufruf

00:53:34.460 --> 00:53:35.300
eine Schleife brauchte,

00:53:35.300 --> 00:53:36.700
um den nächsten gültigen Eintrag zu finden.

00:53:37.280 --> 00:53:38.240
Und jetzt weiß man halt einfach,

00:53:38.320 --> 00:53:39.220
es ist der nächste Eintrag.

00:53:41.300 --> 00:54:00.140
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.

00:54:00.460 --> 00:54:01.840
Wir führen das aus, es wird schneller

00:54:01.840 --> 00:54:04.260
und ich glaube, irgendwie jetzt müssen wir

00:54:04.260 --> 00:54:06.000
vielleicht so ein bisschen anfangen darüber zu reden,

00:54:06.200 --> 00:54:06.940
wie das eigentlich geht.

00:54:10.260 --> 00:54:11.860
Also die Kern, ja.

00:54:12.080 --> 00:54:13.320
Ich hätte noch ein, zwei Fragen.

00:54:15.180 --> 00:54:15.720
Also werden

00:54:15.720 --> 00:54:16.900
alle Sachen schneller?

00:54:18.240 --> 00:54:20.060
Was mit anderen Sprachen, also kann da C++

00:54:20.060 --> 00:54:21.900
irgendwie, wenn das irgendwie angebunden ist, ein Problem?

00:54:22.700 --> 00:54:24.320
Also es wird

00:54:24.320 --> 00:54:25.200
halt erstmal vor allem

00:54:25.200 --> 00:54:28.140
Python schneller. Also wirklich, wenn du Python-Code

00:54:28.140 --> 00:54:30.100
ausfüllst, wird das schneller. Aber die anderen Sachen laufen

00:54:30.100 --> 00:54:31.720
noch. Die anderen Sachen laufen noch

00:54:31.720 --> 00:54:33.700
und es kommt so ein bisschen drauf an,

00:54:34.920 --> 00:54:36.060
was die genau machen,

00:54:36.300 --> 00:54:37.820
ob die dann vielleicht

00:54:37.820 --> 00:54:39.940
langsamer werden oder halt einfach gleich

00:54:39.940 --> 00:54:40.860
bleiben oder

00:54:40.860 --> 00:54:43.940
es gibt halt dann so Randfälle, zum Beispiel

00:54:43.940 --> 00:54:45.820
reguläre Ausdrücke sind auch sehr, sehr schnell

00:54:45.820 --> 00:54:47.140
bei uns in PyPy,

00:54:47.860 --> 00:54:49.860
obwohl die natürlich eigentlich kein Python-Code sind, aber da

00:54:49.860 --> 00:54:51.860
haben wir dann eine extra Optimierung dafür, das ist ja

00:54:51.860 --> 00:54:53.740
quasi so eine kleine DSL

00:54:53.740 --> 00:54:55.460
in Python,

00:54:55.560 --> 00:54:57.680
also du sollst ja DSL nochmal beschreiben, weil ich so

00:54:57.680 --> 00:55:00.080
Language gemeint habe. Genau, eine Domain-Specific-Language

00:55:00.080 --> 00:55:01.520
für String-Matching. Also

00:55:01.520 --> 00:55:03.900
ich meine, das ist eine sehr häufige, die halt quasi überall

00:55:03.900 --> 00:55:05.880
eingebaut ist, aber es ist ja schon eine andere

00:55:05.880 --> 00:55:07.380
Programmiersprache als Python letztlich.

00:55:08.200 --> 00:55:10.060
Aber wir haben halt dafür auch dann quasi

00:55:10.060 --> 00:55:11.640
ganz viel Optimierung gemacht,

00:55:11.860 --> 00:55:12.720
dass das halt auch schnell ist.

00:55:14.260 --> 00:55:15.980
Normalerweise kann ich die per PyEnv einfach

00:55:15.980 --> 00:55:16.960
installieren, dann mein

00:55:16.960 --> 00:55:19.960
PyPy auch? Ich glaube, PyEnv

00:55:19.960 --> 00:55:21.420
unterstützt auch PyPy, ja. Also

00:55:21.420 --> 00:55:24.080
Tox hat eigentlich zum Beispiel PyPy-Support, wenn du das testen willst.

00:55:24.940 --> 00:55:26.060
Das ist schon an vielen

00:55:26.060 --> 00:55:27.940
Stellen quasi so ganz

00:55:27.940 --> 00:55:30.060
gut in die

00:55:30.060 --> 00:55:31.520
in die

00:55:31.520 --> 00:55:33.420
Infrastruktur.

00:55:35.380 --> 00:55:36.160
Nach dem Semester-Fan

00:55:36.160 --> 00:55:38.340
kriegen wir hoffentlich einen Alpha-Release.

00:55:38.760 --> 00:55:40.100
Also da arbeite ich

00:55:40.100 --> 00:55:42.200
gerade halt dran. Heute Morgen

00:55:42.200 --> 00:55:44.020
habe ich zwei Bugs gefixt. Also das ist

00:55:44.020 --> 00:55:45.900
das, was ich jetzt gerade so halt wirklich

00:55:45.900 --> 00:55:46.520
konkret mache.

00:55:47.780 --> 00:55:49.960
Also die großen Features sind halt fast

00:55:49.960 --> 00:55:52.080
fertig. Also Pattern-Matching

00:55:52.080 --> 00:55:53.840
ist da und

00:55:53.840 --> 00:55:56.100
3.10 hatte, also außer Pattern-Matching

00:55:56.100 --> 00:55:57.860
halt auch viele so mittelgroße Sachen.

00:55:59.860 --> 00:56:02.120
aber Pattern Matching, das war wirklich

00:56:02.120 --> 00:56:04.040
auch, kann ich mir vorstellen, das macht

00:56:04.040 --> 00:56:05.800
ja beim Parsen

00:56:05.800 --> 00:56:07.900
ein relativ großes, ich glaube, das konnte ja auch nur

00:56:07.900 --> 00:56:10.000
deswegen in C-Python

00:56:10.000 --> 00:56:11.560
irgendwie gemacht werden,

00:56:12.060 --> 00:56:13.620
weil da dann der neue

00:56:13.620 --> 00:56:15.740
Pack-Parser irgendwie verwendet wurde und ich weiß gar nicht,

00:56:15.820 --> 00:56:18.100
bei Pypi, äh Pypi, äh Pypi

00:56:18.100 --> 00:56:19.080
ist eigentlich reingefallen.

00:56:20.340 --> 00:56:22.040
Da ist ja, da

00:56:22.040 --> 00:56:23.740
weiß ich gar nicht, was da verwendet wird, aber das

00:56:23.740 --> 00:56:25.660
könnte ja dann auch auswirken. Da hatte ich zum Glück sehr gut,

00:56:25.820 --> 00:56:27.640
also vor einem Jahr hatte ich dann 3.9

00:56:27.640 --> 00:56:29.180
implementiert und da war

00:56:29.180 --> 00:56:31.520
3.10 ja schon raus und da habe ich halt so gesehen,

00:56:31.960 --> 00:56:33.340
der Packparser wird wichtig

00:56:33.340 --> 00:56:35.560
und ich habe dann quasi bei 3.9 schon

00:56:35.560 --> 00:56:36.240
die ganze

00:56:36.240 --> 00:56:39.080
technische Vorarbeit dafür geleistet.

00:56:39.200 --> 00:56:41.380
Wir haben auch einen Packparser,

00:56:41.500 --> 00:56:42.980
quasi mehr oder weniger die gleiche Architektur.

00:56:43.400 --> 00:56:45.640
Wir können nicht ganz das gleiche Input-File nehmen,

00:56:46.260 --> 00:56:47.340
weil, ich weiß nicht, ob du mal

00:56:47.340 --> 00:56:48.820
in diese Grammatik-Datei reingeschaut hast?

00:56:49.420 --> 00:56:51.520
Nee, nicht wirklich. Also das ist halt im Prinzip

00:56:51.520 --> 00:56:53.780
so ein bisschen so eine kontextfreie Grammatik,

00:56:53.820 --> 00:56:54.660
wie man das halt irgendwie

00:56:54.660 --> 00:56:57.320
aus irgendeiner Informatik-Vorlesung

00:56:57.320 --> 00:56:58.720
vielleicht mal gesehen hat, aber

00:56:58.720 --> 00:57:01.320
im Unterschied zur alten Grammatik ist das so,

00:57:01.420 --> 00:57:03.300
dass jetzt in der Pack-Grammatik

00:57:03.300 --> 00:57:05.460
da sind halt so Schnipsel an C-Code drin.

00:57:06.940 --> 00:57:07.300
Und

00:57:07.300 --> 00:57:09.500
die können wir halt, die wollen wir halt nicht haben.

00:57:10.160 --> 00:57:11.240
Und wir müssen quasi

00:57:11.240 --> 00:57:13.400
die Schnipsel an C-Code, die mussten wir halt quasi von Hand

00:57:13.400 --> 00:57:15.520
einfach einmal überall ersetzen. Und das war sehr, sehr

00:57:15.520 --> 00:57:17.600
nervig. Und das

00:57:17.600 --> 00:57:18.920
ist auch so ein bisschen meine Kritik,

00:57:20.040 --> 00:57:20.900
dass quasi

00:57:20.900 --> 00:57:23.500
die Grammatik der Sprache vermischt

00:57:23.500 --> 00:57:25.440
wird mit den Parsing-Actions, die in C

00:57:25.440 --> 00:57:26.560
geschrieben sind, bei C-Python.

00:57:27.320 --> 00:57:55.040
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,

00:57:55.040 --> 00:57:56.960
dass das Pattern Matching

00:57:56.960 --> 00:57:59.300
dann in den Parser zumindest einfach einzufügen

00:57:59.300 --> 00:58:01.200
ist. Aber es ist

00:58:01.200 --> 00:58:03.060
halt nicht nur ein Parser, es ist ganz viel

00:58:03.060 --> 00:58:05.220
neues Syntax, aber es sind halt auch einiges

00:58:05.220 --> 00:58:07.220
an neuen Bytecodes und der Bytecode-Compiler

00:58:07.220 --> 00:58:09.180
hat halt ganz, ganz

00:58:09.180 --> 00:58:11.160
viel recht komplexe

00:58:11.160 --> 00:58:12.120
Logik auch gekriegt

00:58:12.120 --> 00:58:15.000
und das habe ich jetzt, aber das ist zum größten Teil

00:58:15.000 --> 00:58:16.480
jetzt halt ziemlich fertig.

00:58:16.760 --> 00:58:19.180
Da fehlt mir noch so ein Randfall,

00:58:19.240 --> 00:58:20.560
den muss ich jetzt irgendwann noch fixen, der

00:58:20.560 --> 00:58:22.660
hat mich bisher noch zu sehr genervt, aber

00:58:22.660 --> 00:58:24.660
also das ist quasi fast

00:58:24.660 --> 00:58:24.960
durch.

00:58:27.360 --> 00:58:28.520
Und dann, also jedes

00:58:28.520 --> 00:58:30.240
Release,

00:58:31.000 --> 00:58:31.420
so der,

00:58:33.000 --> 00:58:34.640
ich versuche mal so ein bisschen ein

00:58:34.640 --> 00:58:36.660
Gefühl dafür zu vermitteln, wie sich das anfühlt, an so einer

00:58:36.660 --> 00:58:38.600
neuen Python-Version zu arbeiten. Es gibt halt

00:58:38.600 --> 00:58:40.640
immer irgendwie fünf große Features, die man halt

00:58:40.640 --> 00:58:42.800
auf der What's New-Seite

00:58:42.800 --> 00:58:44.800
kennt und die implementiert man halt.

00:58:44.940 --> 00:58:46.740
Das ist dann irgendwie halt auch nice, ja, weil

00:58:46.740 --> 00:58:48.800
da ist so ein klar umrissener Task

00:58:48.800 --> 00:58:50.540
und man freut sich vielleicht halt auch über, vielleicht

00:58:50.540 --> 00:58:52.460
ist es halt auch ein Feature, was man gut findet.

00:58:52.660 --> 00:58:54.980
Ich weiß nicht, wie ist euer Bauchgefühl?

00:58:55.200 --> 00:58:56.500
Wie findet ihr Pattern-Matching?

00:58:57.000 --> 00:58:57.600
Ich liebe es.

00:58:58.240 --> 00:59:00.280
Okay, ich habe es noch nicht wirklich viel verwendet.

00:59:01.060 --> 00:59:02.180
Ich mag das total gerne.

00:59:02.660 --> 00:59:05.160
Statt if, elif irgendwie einfach schöne Cases zu machen.

00:59:05.620 --> 00:59:07.400
Gerade für so API-Parsing.

00:59:07.580 --> 00:59:08.840
Also ich finde, man muss sich ganz,

00:59:08.980 --> 00:59:11.820
ich verstehe absolut, dass man das total cool finden kann.

00:59:12.180 --> 00:59:13.720
Ich habe es auch noch nicht so richtig im Produktiv,

00:59:13.980 --> 00:59:16.580
also noch nicht wirklich irgendwas geschrieben,

00:59:16.580 --> 00:59:19.080
was halt nicht einfach so ein Toy-Beispiel ist.

00:59:19.180 --> 00:59:21.160
Aber man muss sich schon so ein bisschen reindenken.

00:59:21.400 --> 00:59:23.320
Also ich finde, es unterscheidet sich halt

00:59:23.320 --> 00:59:24.500
in mancher Hinsicht schon

00:59:24.500 --> 00:59:26.980
so ein bisschen von dem

00:59:26.980 --> 00:59:29.120
Feeling von Python an so ein paar

00:59:29.120 --> 00:59:29.680
anderen Stellen.

00:59:31.840 --> 00:59:33.320
Ich glaube, wenn man dann da

00:59:33.320 --> 00:59:35.280
so mal gedanklich drin ist, ist das glaube ich wirklich auch

00:59:35.280 --> 00:59:37.380
sehr, sehr cool, aber man braucht so ein bisschen.

00:59:37.720 --> 00:59:39.400
Oder ich habe das Gefühl, dass ich es noch so ein bisschen brauche.

00:59:39.440 --> 00:59:41.180
Man kann irgendwie so direkte Kommandos geben und

00:59:41.180 --> 00:59:42.840
man kann da direkt sagen, was das ist.

00:59:42.940 --> 00:59:45.440
Und im Zusammenhang mit den Typen, finde ich, ist das sehr schön.

00:59:45.700 --> 00:59:47.100
Weil wenn man halt tatsächlich Typen

00:59:47.100 --> 00:59:49.060
definiert hat irgendwie, dann kann man halt einfach

00:59:49.060 --> 00:59:50.860
diesen Typ als Case nehmen

00:59:50.860 --> 00:59:51.980
und das ist halt

00:59:51.980 --> 00:59:54.320
genau das, was man wahrscheinlich irgendwie

00:59:54.320 --> 00:59:56.860
Aber also was man dann wirklich in die Patterns

00:59:56.860 --> 00:59:58.800
reinschreibt, das ist halt quasi nochmal

00:59:58.800 --> 01:00:00.840
so ein bisschen so eine Sprache in der Sprache

01:00:00.840 --> 01:00:02.880
und die ist halt

01:00:02.880 --> 01:00:04.940
schon so ein bisschen anders halt auch

01:00:04.940 --> 01:00:05.980
als

01:00:05.980 --> 01:00:07.580
der Rest von Python.

01:00:08.340 --> 01:00:10.420
Ja, aber jetzt, ich glaube, du musst vielleicht gleich nochmal so ein bisschen

01:00:10.420 --> 01:00:12.700
ausholen darüber, was eigentlich so eine Sprache aus

01:00:12.700 --> 01:00:13.500
deiner Sicht halt ist.

01:00:13.860 --> 01:00:16.620
Ja, das ist jetzt ziemlich schwammig, da würde ich, also ja.

01:00:18.460 --> 01:00:18.780
Genau,

01:00:18.980 --> 01:00:20.620
aber auf jeden Fall, also man hat da so ein

01:00:20.620 --> 01:00:22.240
großes Feature, sowas wie Pattern Matching,

01:00:22.680 --> 01:00:24.560
das ist halt schön, da kann man, weiß man,

01:00:24.640 --> 01:00:26.620
das ist relativ klar umrissen, wenn

01:00:26.620 --> 01:00:28.640
man das Feature cool findet, dann macht es halt auch richtig

01:00:28.640 --> 01:00:30.040
Spaß, das zu implementieren, ja, dann

01:00:30.040 --> 01:00:32.560
so über ein paar Tage hinweg fängt das halt dann an

01:00:32.560 --> 01:00:34.560
zu funktionieren, das ist halt einfach immer wieder auch sehr

01:00:34.560 --> 01:00:36.720
cool und irgendwann

01:00:36.720 --> 01:00:38.620
ist man halt dann mit allen großen Featuren fertig

01:00:38.620 --> 01:00:39.520
und dann gibt es so ein bisschen,

01:00:40.720 --> 01:00:42.480
zusätzlich zu den fünf großen Featuren gibt es halt

01:00:42.480 --> 01:00:44.200
vielleicht 30

01:00:44.200 --> 01:00:45.900
kleinere und mittlere Feature,

01:00:46.840 --> 01:00:48.340
das ist halt so ein bisschen Fleißarbeit

01:00:48.340 --> 01:00:50.660
und dann gibt es aber halt einfach

01:00:50.660 --> 01:00:52.380
tausend Details

01:00:52.380 --> 01:00:55.060
und das sind halt,

01:00:55.220 --> 01:00:57.200
das ist der Teil, der quasi am längsten

01:00:57.200 --> 01:00:58.140
dauert und ein bisschen

01:00:58.140 --> 01:01:01.060
am nervigsten ist, also weil man halt jeden Tag

01:01:01.060 --> 01:01:03.120
einfach fünf kleine Details

01:01:03.120 --> 01:01:05.100
fixen kann und man

01:01:05.100 --> 01:01:06.400
findet die, indem man halt die

01:01:06.400 --> 01:01:08.360
Testsuite, die

01:01:08.360 --> 01:01:11.380
Teil der C-Python-Standard-Bibliothek

01:01:11.380 --> 01:01:11.940
ist, ausführt

01:01:11.940 --> 01:01:14.800
und dann halt die fehlenden

01:01:14.800 --> 01:01:15.920
Tests nach und nach fixt

01:01:15.920 --> 01:01:17.220
und

01:01:17.220 --> 01:01:20.040
mit den großen Features ist man halt irgendwann durch.

01:01:20.180 --> 01:01:22.080
Also es gibt halt Test Padma, das hat man halt irgendwann

01:01:22.080 --> 01:01:23.640
dann, das passt dann, dann ist es super.

01:01:24.280 --> 01:01:26.140
Aber dann ist halt in allen anderen Dateien

01:01:26.140 --> 01:01:28.200
gibt es halt dann so einen fehlschlagenden

01:01:28.200 --> 01:01:30.160
Test und jeder von diesen fehlschlagenden

01:01:30.160 --> 01:01:31.460
Tests dauert halt zwei Stunden

01:01:31.460 --> 01:01:34.120
und das ist halt einfach das, was einfach ganz

01:01:34.120 --> 01:01:36.160
ganz, also da

01:01:36.160 --> 01:01:38.040
gibt es halt quasi dann so einen long tail an irgendwelchen

01:01:38.040 --> 01:01:40.120
Details. Und der

01:01:40.120 --> 01:01:41.520
quasi

01:01:41.520 --> 01:01:44.000
Fortschritt, den man dadurch erzielt, dass man das

01:01:44.000 --> 01:01:45.860
fix, ist halt auch irgendwann dann nicht mehr

01:01:45.860 --> 01:01:47.780
so groß, dass man sich, wahrscheinlich denkt man sich dann irgendwann

01:01:47.780 --> 01:01:49.500
so, das lohnt sich halt nicht mehr.

01:01:49.500 --> 01:01:51.300
Wer das so irgendwann mal benutzt. Genau.

01:01:52.000 --> 01:01:53.780
Okay, aber das ist tatsächlich dann TDD auch,

01:01:53.860 --> 01:01:55.820
was ihr da macht. Ja, also

01:01:55.820 --> 01:01:57.720
Piper ist von, also so von der

01:01:57.720 --> 01:01:59.060
Entwicklungsphilosophie sehr,

01:01:59.980 --> 01:02:01.740
also ich meine, wir haben ja

01:02:01.740 --> 01:02:03.460
vorhin ganz kurz gesagt, dass es jetzt irgendwie

01:02:03.460 --> 01:02:05.240
20 Jahre altes Projekt ist, also es wurde

01:02:05.240 --> 01:02:07.620
fast genau,

01:02:07.740 --> 01:02:09.560
also irgendwie 17. Februar war das erste

01:02:09.560 --> 01:02:11.660
Treffen von so

01:02:11.660 --> 01:02:13.620
ein paar Leuten in Hildesheim. 2003.

01:02:14.000 --> 01:02:36.260
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.

01:02:36.260 --> 01:02:56.660
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.

01:02:57.460 --> 01:03:16.860
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.

01:03:16.860 --> 01:03:18.960
und Unitest ist ja ein

01:03:18.960 --> 01:03:21.060
von Java

01:03:21.060 --> 01:03:23.540
portiertes, an Java

01:03:23.540 --> 01:03:25.400
Architektur angelehntes

01:03:25.400 --> 01:03:26.220
Testing Framework.

01:03:27.360 --> 01:03:29.320
JUnit, aber ich glaube JUnit

01:03:29.320 --> 01:03:30.640
ist irgendwie SUnit von

01:03:30.640 --> 01:03:33.300
Smarttalk. Aber durch

01:03:33.300 --> 01:03:35.080
diesen Umweg über Java ist es halt

01:03:35.080 --> 01:03:37.140
irgendwie doch ein bisschen ungelenk

01:03:37.140 --> 01:03:37.860
an vielen Stellen.

01:03:38.720 --> 01:03:41.040
Und weil Holger halt dann das alles

01:03:41.040 --> 01:03:42.940
auch ganz schön doof fand, hat er

01:03:42.940 --> 01:03:44.680
recht früh als Teil

01:03:44.680 --> 01:03:46.920
Projekt von PyPy halt angefangen

01:03:46.920 --> 01:03:48.000
PyTest zu entwickeln

01:03:48.000 --> 01:03:51.160
und

01:03:51.160 --> 01:03:52.460
das ging dann quasi

01:03:52.460 --> 01:03:55.000
aus dem PyPy-Projekt irgendwie so ein Stück

01:03:55.000 --> 01:03:56.180
weit hervor und ist jetzt natürlich

01:03:56.180 --> 01:03:58.960
eine Million Mal erfolgreicher

01:03:58.960 --> 01:04:00.880
als alles, was PyPy irgendwie jemals sonst

01:04:00.880 --> 01:04:02.980
so gemacht hat. PyPy-Spannende, also am Anfang

01:04:02.980 --> 01:04:04.900
habe ich es gehasst und jetzt finde ich es richtig gut, weil es halt echt

01:04:04.900 --> 01:04:06.720
total gut ist und ich finde es sehr PySonic

01:04:06.720 --> 01:04:08.740
und wenn man einmal so ein bisschen vielleicht verstanden hat, wie das

01:04:08.740 --> 01:04:10.060
funktioniert, das ist sehr, sehr, sehr schön

01:04:10.060 --> 01:04:12.740
zu nutzen auch, ja. Also ich meine halt einfach so

01:04:12.740 --> 01:04:14.660
dieses, dass man davon wegkommt, dass man diese

01:04:14.660 --> 01:04:17.380
97 self-assert

01:04:17.380 --> 01:04:17.780
irgendwas

01:04:17.780 --> 01:04:21.300
Funktionen braucht, um gute Fehlermeldungen

01:04:21.300 --> 01:04:22.680
zu kriegen. Das ist halt schon

01:04:22.680 --> 01:04:24.800
self-assert, equal, irgendwie CamelCase und sowas.

01:04:25.020 --> 01:04:25.900
Equal oder Equals?

01:04:26.080 --> 01:04:27.100
Genau, ja, ja, genau.

01:04:27.180 --> 01:04:28.480
Du machst bloß nichts Falsches.

01:04:30.100 --> 01:04:33.640
Ja, und CamelCase natürlich auch mal.

01:04:34.720 --> 01:04:35.840
Ja, und ich finde

01:04:35.840 --> 01:04:37.740
halt also gerade so die Hürde, man schreibt halt

01:04:37.740 --> 01:04:39.580
einfach eine Funktion, die Test heißt, dahin und dann

01:04:39.580 --> 01:04:41.420
geht halt, das ist halt schon sehr, sehr cool.

01:04:42.640 --> 01:04:43.100
Ne, genau, also

01:04:43.100 --> 01:04:45.360
also Test-Driven Development war halt

01:04:45.360 --> 01:04:47.560
einer der Kernideen

01:04:47.560 --> 01:04:49.320
so auf der, wie entwickeln

01:04:49.320 --> 01:04:51.260
wir dieses Projekt? Das andere

01:04:51.260 --> 01:04:53.220
war halt, das ist so ein bisschen verloren

01:04:53.220 --> 01:04:55.120
gegangen über die Jahre, aber einer der Ideen am

01:04:55.120 --> 01:04:57.160
Anfang war halt wirklich, wir wollen eine

01:04:57.160 --> 01:04:59.440
sehr gut verständliche

01:04:59.440 --> 01:05:00.620
Implementierung der Sprache schreiben.

01:05:01.480 --> 01:05:03.020
Und da müssen wir

01:05:03.020 --> 01:05:05.100
irgendwann jetzt halt dann doch mal zur Architektur kommen.

01:05:06.060 --> 01:05:07.160
Warum heißt das Ding eigentlich PyPy?

01:05:09.100 --> 01:05:09.340
Und

01:05:09.340 --> 01:05:10.680
Ich weiß PyPy noch nicht ganz.

01:05:10.980 --> 01:05:11.340
Ja.

01:05:12.680 --> 01:05:13.420
Nein, Entschuldigung.

01:05:13.600 --> 01:05:15.580
Also das Projekt ist halt entstanden

01:05:15.580 --> 01:05:17.780
aus Diskussionen auf

01:05:17.780 --> 01:05:19.260
erst der deutschen Python-Mailing-Liste

01:05:19.260 --> 01:05:21.680
und dann irgendwie auch Complying Python

01:05:21.680 --> 01:05:23.320
von halt

01:05:23.320 --> 01:05:25.880
Python-Fans, also halt so ein paar

01:05:25.880 --> 01:05:28.020
Leute, die irgendwie Python als Programmiersprache toll fanden

01:05:28.020 --> 01:05:29.860
und die halt gesagt haben, naja, es ist doch

01:05:29.860 --> 01:05:31.440
philosophisch eigentlich irgendwie blöd,

01:05:32.140 --> 01:05:33.860
dass wir alle Python so toll finden,

01:05:34.420 --> 01:05:34.880
aber die,

01:05:35.780 --> 01:05:37.780
der Interpreter für Python, dass der ja

01:05:37.780 --> 01:05:38.600
in C geschrieben ist.

01:05:40.120 --> 01:05:41.380
Und Piper ist halt wirklich,

01:05:41.820 --> 01:05:44.140
Die Idee war wirklich, wir schreiben jetzt eine Implementierung

01:05:44.140 --> 01:05:45.860
für Python, aber wir wollen dafür halt

01:05:45.860 --> 01:05:47.840
nicht C nehmen, weil C so eine blöde Sprache ist, sondern wir

01:05:47.840 --> 01:05:49.980
wollen dafür halt Python nehmen, weil wir ja alle Python-Fans

01:05:49.980 --> 01:05:52.080
sind. Und das war quasi,

01:05:52.260 --> 01:05:53.980
also da kommt der Name her, PyPy ist Python

01:05:53.980 --> 01:05:55.900
in Python. Und das war

01:05:55.900 --> 01:05:57.760
halt so ein bisschen

01:05:57.760 --> 01:05:59.800
die Ursprungsmotivation. Wir

01:05:59.800 --> 01:06:01.360
wollen jetzt die Sprache nehmen, die wir cool finden,

01:06:01.800 --> 01:06:03.040
um die Sprache

01:06:03.040 --> 01:06:05.860
selbst zu implementieren. Und das klingt halt erst mal

01:06:05.860 --> 01:06:07.740
ganz, also nach einem sehr

01:06:07.740 --> 01:06:09.720
akademischen Experiment.

01:06:10.180 --> 01:06:12.240
Und das war es ein Stück weit, glaube ich, auch erstmal.

01:06:12.380 --> 01:06:13.940
Also erstmal war halt so ein bisschen die Idee auch,

01:06:14.620 --> 01:06:16.220
wir wollen irgendwie Code schreiben,

01:06:16.300 --> 01:06:18.240
die man halt einfach erstmal schön lesen kann.

01:06:18.680 --> 01:06:20.920
Und der soll natürlich schon auch irgendwie funktionieren,

01:06:21.580 --> 01:06:24.840
aber insbesondere soll der halt einfach architektonisch toll sein

01:06:24.840 --> 01:06:27.320
und irgendwie elegant und alles schön,

01:06:27.460 --> 01:06:30.080
diese Sprachsemantik soll irgendwie ganz klar ausgedrückt werden

01:06:30.080 --> 01:06:31.860
in diesem Python-Code.

01:06:32.120 --> 01:06:33.520
Das war quasi eine der Ideen.

01:06:34.320 --> 01:06:35.920
Und erst später kam es dann hinzu,

01:06:36.060 --> 01:06:39.840
dass quasi Performance eigentlich ein immer wichtiger Teil

01:06:39.840 --> 01:06:46.580
der Projektmotivation war.

01:06:46.960 --> 01:06:47.880
Also irgendwann hat man halt gesagt,

01:06:48.080 --> 01:06:49.500
naja, okay, wir haben das jetzt,

01:06:49.580 --> 01:06:50.660
aber warum sollte man das machen?

01:06:51.460 --> 01:06:53.620
Und wir machen jetzt halt auch noch ganz, ganz viel Aufwand,

01:06:54.000 --> 01:06:57.960
also welchen Aufwand, da sage ich gleich noch ein bisschen was dazu.

01:06:58.720 --> 01:07:00.100
Wir machen halt ganz, ganz viel Aufwand,

01:07:00.100 --> 01:07:01.780
um das dann doch irgendwie auch schnell zu kriegen.

01:07:02.860 --> 01:07:04.180
So, und vielleicht können wir da auch einfach

01:07:04.180 --> 01:07:05.060
wirklich historisch vorgehen.

01:07:05.340 --> 01:07:08.840
die erste Idee, um das jetzt schneller zu kriegen,

01:07:08.920 --> 01:07:10.860
also man hat dann jetzt irgendwie so eine Python-Implementierung,

01:07:10.940 --> 01:07:12.620
die ist in Python geschrieben und die ist schön und elegant,

01:07:12.700 --> 01:07:14.660
man kann das lesen, aber das bringt einem halt einfach gar nichts.

01:07:15.060 --> 01:07:16.800
Weil man braucht ja einfach immer noch darunter

01:07:16.800 --> 01:07:18.700
einen Python-Interpreter, um

01:07:18.700 --> 01:07:20.720
das ausführen zu können. Und dann ist es

01:07:20.720 --> 01:07:22.620
halt einfach quasi ein Python-Interpreter,

01:07:22.700 --> 01:07:24.320
der auf C-Python läuft.

01:07:24.760 --> 01:07:26.080
Das ist halt einfach ganz, ganz langsam.

01:07:26.440 --> 01:07:28.780
Aber man kann natürlich dann viel über die Sprache

01:07:28.780 --> 01:07:30.800
vielleicht lernen. Genau, man kann dann was lernen und man kann

01:07:30.800 --> 01:07:31.760
da bestimmt auch irgendwie dann

01:07:31.760 --> 01:07:34.380
schön einfach Experimente durchführen.

01:07:34.740 --> 01:07:36.240
Aber das ist jetzt nichts, was man irgendwie

01:07:36.240 --> 01:07:37.720
im Produktiv-Einsatz haben

01:07:37.720 --> 01:07:40.220
wollte. Es wäre halt dann wirklich einfach

01:07:40.220 --> 01:07:42.240
eher so ein, es wäre halt

01:07:42.240 --> 01:07:44.200
vielleicht so ein cooler Blogpost oder so, oder? Ein cooles Buch.

01:07:44.560 --> 01:07:46.200
Okay, ja, genau. Aber halt vielmehr

01:07:46.200 --> 01:07:48.140
auch nicht. Und die erste Idee

01:07:48.140 --> 01:07:49.480
ist quasi, dass man jetzt sagt,

01:07:51.140 --> 01:07:54.220
wir machen einen Prozess, den man

01:07:54.220 --> 01:07:56.380
halt irgendwie Bootstrapping nennen kann.

01:07:57.020 --> 01:07:57.960
Wir nehmen jetzt

01:07:57.960 --> 01:08:00.080
diesen Python-Interpreter, der in Python geschrieben

01:08:00.080 --> 01:08:01.300
ist, und

01:08:01.300 --> 01:08:03.940
übersetzen den,

01:08:04.540 --> 01:08:06.460
also wir schreiben einen Compiler, der jetzt diesen Code

01:08:06.460 --> 01:08:07.960
nehmen kann und den nach C übersetzen kann.

01:08:09.460 --> 01:08:09.740
Und

01:08:09.740 --> 01:08:12.320
das geht halt nicht

01:08:12.320 --> 01:08:14.360
für allgemeinen Python-Code, also man kann Python-Code

01:08:14.360 --> 01:08:15.820
halt nicht nach C kompilieren, das

01:08:15.820 --> 01:08:17.980
bringt nicht viel, aber

01:08:17.980 --> 01:08:20.320
deswegen beschränken wir uns auf eine Teilmenge von

01:08:20.320 --> 01:08:20.640
Python

01:08:20.640 --> 01:08:24.460
in dem Code, den wir in der Implementierung

01:08:24.460 --> 01:08:25.340
des Interpreters verwenden.

01:08:26.200 --> 01:08:28.240
Also der Interpreter ist quasi in einer Teilmenge geschrieben

01:08:28.240 --> 01:08:30.340
und die ist so gewählt, dass man

01:08:30.340 --> 01:08:32.100
diese Teilmenge gut nach C übersetzen kann.

01:08:32.780 --> 01:08:33.920
Und dann wird man quasi dieses

01:08:33.920 --> 01:08:36.380
Interpreter-Turm

01:08:36.380 --> 01:08:38.260
problemlos. Also dann kann man quasi

01:08:38.260 --> 01:08:40.360
den Python-Interpreter nehmen,

01:08:40.420 --> 01:08:42.260
der ist nicht mehr in Python geschrieben, sondern in

01:08:42.260 --> 01:08:44.240
ich sag jetzt gleich den Namen, in

01:08:44.240 --> 01:08:46.100
R-Python. Das ist eine

01:08:46.100 --> 01:08:48.160
Teilmenge der Sprache und die ist so

01:08:48.160 --> 01:08:49.580
gewählt, dass man sie nach C übersetzen kann.

01:08:50.300 --> 01:08:51.700
Und R-Python heißt es halt, weil es

01:08:51.700 --> 01:08:54.300
Restricted Python ist, weil man halt

01:08:54.300 --> 01:08:56.320
einfach so ein bisschen die ganz

01:08:56.320 --> 01:08:57.920
dynamischen Sachen, die man in Python machen

01:08:57.920 --> 01:09:00.320
kann, die macht man halt einfach nicht.

01:09:01.080 --> 01:09:02.020
Um eben das

01:09:02.020 --> 01:09:03.780
übersetzen, nach C zu ermöglichen. Also man

01:09:03.780 --> 01:09:05.900
ändert keinen Typ einer Variable irgendwie on the fly.

01:09:06.440 --> 01:09:08.120
Ganz genau. Also das ist, glaube ich,

01:09:08.140 --> 01:09:10.020
sogar noch nicht mal ganz so schlimm. Also man

01:09:10.020 --> 01:09:11.780
macht halt so Sachen, man fügt einer Klasse

01:09:11.780 --> 01:09:13.500
keine neuen Methoden zur Laufzeit hinzu.

01:09:14.360 --> 01:09:14.720
Oder

01:09:14.720 --> 01:09:18.100
in Python gilt ja alle möglichen komischen Sachen. Man kann halt ja auch

01:09:18.100 --> 01:09:19.220
bei einer Instanz

01:09:19.220 --> 01:09:21.180
dann der Class zuweisen und so.

01:09:22.140 --> 01:09:23.860
So dieses ganze ganz dynamische

01:09:23.860 --> 01:09:25.860
Metaprogrammierungszeug, das ist halt einfach verboten,

01:09:25.960 --> 01:09:27.260
weil da ist halt

01:09:27.260 --> 01:09:29.720
nicht so klar, wie der C-Code dann aussähe,

01:09:29.800 --> 01:09:31.840
den man da generieren würde. Also das ist der

01:09:31.840 --> 01:09:32.820
erster Schritt. Der erste Schritt ist,

01:09:33.960 --> 01:09:35.700
das ist nicht mehr Python

01:09:35.700 --> 01:09:37.720
in beliebigem Python-Code, sondern das ist

01:09:37.720 --> 01:09:39.740
eine Implementierung für die

01:09:39.740 --> 01:09:41.400
Sprache Python in einer Teilmenge von Python

01:09:41.400 --> 01:09:43.400
und wir haben dazu noch ein anderes Tool,

01:09:43.780 --> 01:09:46.120
was jetzt diese Teilmenge nimmt und daraus C-Code erzeugt.

01:09:46.440 --> 01:09:47.640
Und so wird man C-Python erstmal

01:09:47.640 --> 01:09:49.260
los. Also danach,

01:09:49.660 --> 01:09:51.560
du drückst dann auf den Knopf und dann

01:09:51.560 --> 01:09:53.700
nimmt der halt den Interpreter, der in der Teilmenge

01:09:53.700 --> 01:09:55.220
geschrieben ist, erzeugt C-Code daraus,

01:09:55.700 --> 01:09:57.260
dann startest du den C-Compiler

01:09:57.260 --> 01:09:59.520
und der nimmt den C-Code und macht daraus halt eben

01:09:59.520 --> 01:10:01.660
wieder ein Binary, über das wir ja vorhin

01:10:01.660 --> 01:10:03.760
schon gesprochen haben, dass das runtergeladen

01:10:03.760 --> 01:10:05.660
werden kann. Und das ist

01:10:05.660 --> 01:10:07.620
halt dann quasi einfach ein etwas

01:10:07.620 --> 01:10:09.480
merkwürdiges, also

01:10:09.480 --> 01:10:11.640
geschriebenes, aber das

01:10:11.640 --> 01:10:13.720
verhält sich jetzt, also es ist quasi

01:10:13.720 --> 01:10:15.720
noch näher dran an dem, was man von Python.org

01:10:15.720 --> 01:10:17.320
runterladen kann. Es ist halt

01:10:17.320 --> 01:10:19.760
ein nicht in Hand geschriebener C-Code,

01:10:19.840 --> 01:10:21.340
sondern generierter C-Code, aber

01:10:21.340 --> 01:10:23.540
es ist halt einfach dann ein Interpreter für Python

01:10:23.540 --> 01:10:25.500
in C, letztlich.

01:10:26.800 --> 01:10:27.160
Und

01:10:27.160 --> 01:10:29.640
das bringt halt schon

01:10:29.640 --> 01:10:30.540
dann mal die ersten

01:10:30.540 --> 01:10:32.460
also vorher

01:10:32.460 --> 01:10:34.780
so, um mal so eine Größenordnung zu nennen,

01:10:35.320 --> 01:10:36.700
wenn man das, wenn man

01:10:36.700 --> 01:10:38.740
dann PiPi auf C-Python ausführt, dann hat man halt

01:10:38.740 --> 01:10:40.660
irgendwie so einen Interpreter, der vielleicht 2000 Mal

01:10:40.660 --> 01:10:42.860
langsamer ist als C-Python.

01:10:43.020 --> 01:10:44.380
Also dann ist das halt wirklich, das ist nur

01:10:44.380 --> 01:10:46.480
ein Spielzeug. Und wenn man dann

01:10:46.480 --> 01:10:48.540
diesen Bootstrapping-Trick macht,

01:10:48.600 --> 01:10:50.580
dass man eben wieder C-Code erzeugt, dann gewinnt

01:10:50.580 --> 01:10:51.400
man halt von diesen

01:10:51.400 --> 01:10:54.620
2000 Mal langsamer, gewinnt man halt

01:10:54.620 --> 01:10:55.760
1000 Mal zurück.

01:10:56.480 --> 01:10:58.240
Dann hat man quasi einen Interpreter, der ist

01:10:58.240 --> 01:11:00.060
Nur 1000 Mal langsamer.

01:11:00.120 --> 01:11:01.060
Nee, nee, nur zweimal langsamer.

01:11:02.020 --> 01:11:03.980
Also Faktor 1000 kriegt man wieder.

01:11:04.700 --> 01:11:07.000
Aber Faktor 2 hat man halt immer noch.

01:11:07.260 --> 01:11:08.360
Und das ist natürlich immer noch nicht gut.

01:11:09.120 --> 01:11:10.900
Also warum sollte man das machen?

01:11:14.860 --> 01:11:16.760
Weil es halt in Python geschrieben ist

01:11:16.760 --> 01:11:17.740
und wir alle Python so toll finden.

01:11:17.880 --> 01:11:19.480
Das reicht halt irgendwie als Motivation nicht.

01:11:20.000 --> 01:11:21.220
Und jetzt ist so ein bisschen die Frage,

01:11:21.220 --> 01:11:25.200
wo kommt eigentlich wirklich die Speed her?

01:11:25.940 --> 01:11:27.860
Und da wird es halt dann so ein bisschen akademisch.

01:11:28.180 --> 01:11:31.180
das ist quasi

01:11:31.180 --> 01:11:32.540
der Forschungsanteil,

01:11:32.680 --> 01:11:35.260
also ich habe da meine Doktorarbeit drüber geschrieben,

01:11:35.360 --> 01:11:36.160
das ist quasi wirklich

01:11:36.160 --> 01:11:38.800
so ein bisschen

01:11:38.800 --> 01:11:42.860
ein, ja, also war wirklich so

01:11:42.860 --> 01:11:45.380
ein ganz klassisches akademisches Forschungsprojekt,

01:11:45.480 --> 01:11:47.220
da war ja währenddessen auch gar nicht so klar,

01:11:47.320 --> 01:11:49.180
ob das wirklich klappen kann, so von der Idee her

01:11:49.180 --> 01:11:51.300
und hat auch, sag ich mal,

01:11:51.580 --> 01:11:51.960
vielleicht

01:11:51.960 --> 01:11:54.940
fünf, sechs Jahre gedauert, bis es dann

01:11:54.940 --> 01:11:56.940
klarer wurde, dass es halt wirklich geht

01:11:56.940 --> 01:12:07.060
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.

01:12:07.380 --> 01:12:12.780
Also wenn man halt irgendwie eine dynamische Programmiersprache schnell ausführen will, dann braucht man einen Just-in-Time-Compiler.

01:12:13.200 --> 01:12:19.920
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.

01:12:19.920 --> 01:12:26.460
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.

01:12:26.700 --> 01:12:28.840
Also die dürfen ja auch falsch sein.

01:12:31.400 --> 01:12:32.660
Also vergessen wir die erst mal.

01:12:32.660 --> 01:12:35.140
Also das Problem ist, wenn man einfach Python-Code anschaut,

01:12:35.760 --> 01:12:40.040
dann kann man den halt nicht unbedingt jetzt kompilieren.

01:12:40.580 --> 01:12:43.280
Wenn man halt eine Funktion hat, die A und B als Argumente nimmt

01:12:43.280 --> 01:12:47.200
und die Funktion macht irgendwie Return A mal 2 plus B,

01:12:48.280 --> 01:12:51.660
dann kann man diese Funktion nicht nach Maschinen-Code übersetzen,

01:12:52.520 --> 01:12:55.320
weil man weiß halt gar nicht, was das mal macht.

01:12:56.140 --> 01:12:58.200
Also man kann die Funktion halt mit ins

01:12:58.200 --> 01:13:00.140
aufrufen, man kann die mit floats aufrufen,

01:13:00.220 --> 01:13:02.060
man kann die mit strings aufrufen oder

01:13:02.060 --> 01:13:04.000
man kann die halt mit einer

01:13:04.000 --> 01:13:05.440
Klasse aufrufen, die halt

01:13:05.440 --> 01:13:07.860
ein unterstrich unterstrich add Methode hat und

01:13:07.860 --> 01:13:09.940
eine unterstrich unterstrich mul Methode und

01:13:09.940 --> 01:13:11.580
die halt irgendwas super weirdes macht.

01:13:12.160 --> 01:13:13.880
Das muss quasi die Anwendungsfälle

01:13:13.880 --> 01:13:16.000
kennen, in denen das aufgerufen wird

01:13:16.000 --> 01:13:17.760
irgendwann in diesem Programmablauf und dann

01:13:17.760 --> 01:13:19.860
daraus jeweils unterschiedliche Implementierungen

01:13:19.860 --> 01:13:22.020
im Machine Code zu schreiben, die man dann

01:13:22.020 --> 01:13:23.900
verabschiedet. Ja, ganz genau. Und das kann man aber

01:13:23.900 --> 01:13:25.980
halt quasi nicht ohne weiteres statisch machen.

01:13:26.140 --> 01:13:51.600
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.

01:13:52.280 --> 01:14:20.080
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.

01:14:20.720 --> 01:14:35.020
Und der Grund, warum ein Just-In-Time-Compiler eben funktioniert, ist, weil er einen ganz krassen Informationsvorteil hat. Der Just-In-Time-Compiler, der kann halt einfach gucken, mit was für Typen von Argumenten die Funktion aufgerufen wird.

01:14:35.860 --> 01:14:55.840
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.

01:14:56.600 --> 01:15:23.040
Und dann irgendwann sehe ich halt, na gut, das sind immer zwei Floats. Und dann kann ich halt auch guten Maschinencode erzeugen, weil wenn ich weiß, dass es Floats sind, dann kann ich halt das mal, also ich hatte A mal 2 plus B gesagt, dann kann ich halt das mal 2 durch eine Maschineninstruktion darstellen, die halt Doubles auf der CPU direkt multipliziert.

01:15:23.380 --> 01:15:52.440
Und das Plus kann ich eben auch dann durch eine Maschineninstruktion abbilden, die halt Doubles addiert. Und dieser Maschinencode, der funktioniert halt genau nur für den Spezialfall, dass A und B halt wirklich auch float sind. Und wenn dann irgendwann später im Verlauf des Programms halt diese Funktion jemand mit zwei Ins aufruft, dann ist das kein Problem, weil der Code wurde ja sowieso zur Laufzeit erzeugt. Und dann kann ich halt quasi auch neuen Code für diese sich ändernde Situation erzeugen.

01:15:53.380 --> 01:16:20.320
Und diese Flexibilität, die mir die Tatsache, dass ich den Maschinencode eben erst zur Laufzeit erzeuge, dadurch kriege ich halt sehr viel Flexibilität und kann halt die extra Informationen, die ich zur Laufzeit habe, auch benutzen, um quasi die ganze Dynamizität, die man in Python halt theoretisch verwenden kann, aber in der Praxis nicht unbedingt verwendet, die kann ich dann halt auch quasi wieder weg optimieren.

01:16:20.320 --> 01:16:41.160
Aber das kann ich eben nur, weil ich eben das zur Laufzeit mache und mir die Typen anschauen kann und halt auch reagieren kann, wenn sich dann die Umstände ändern. Das ist halt auch so ein bisschen die andere Eigenschaft des Dustin-Time-Copilers, der kann halt dann auch darauf reagieren, dass du nach einer halben Stunde Programmlaufzeit plötzlich den Debugger anmachen willst.

01:16:41.160 --> 01:17:08.200
Also, dann muss man nämlich anfangen, quasi wieder alles zurückzupacken und das nennt man wirklich Deoptimierung, dann muss man wirklich quasi wieder die Frame-Objekte erzeugen, die man halt braucht, um dann, dass der Debugger auch funktioniert, also der Debugger, der introspeziert ja diese Frame-Objekte, die es in Python gibt und die würde der JIT-Compiler natürlich gar nicht benutzen, weil die braucht er nicht.

01:17:08.200 --> 01:17:09.900
Aber wenn man die Bagger anschaltet,

01:17:10.020 --> 01:17:12.440
dann muss man die halt jederzeit wieder herzaubern können.

01:17:13.560 --> 01:17:15.520
Okay, das ist die Idee des Jits.

01:17:16.720 --> 01:17:21.480
Das ist quasi in gewisser Weise heutzutage relativ akzeptiert,

01:17:21.540 --> 01:17:22.760
weil jeder Browser das halt macht.

01:17:23.520 --> 01:17:24.400
Also Java macht das.

01:17:25.120 --> 01:17:27.480
Und insbesondere machen das halt die Browser für JavaScript.

01:17:27.680 --> 01:17:30.200
Und die Browser Wars haben halt dazu geführt,

01:17:30.300 --> 01:17:31.940
dass quasi alle großen Browser

01:17:31.940 --> 01:17:36.420
sehr, sehr, sehr, sehr, sehr viel Geld da reingesteckt haben.

01:17:38.200 --> 01:17:42.500
halt Just-in-Time-Compiler für JavaScript zu schreiben,

01:17:42.760 --> 01:17:46.320
die halt wirklich extrem aggressiv zur Laufzeit

01:17:46.320 --> 01:17:48.140
den JavaScript-Code optimieren

01:17:48.140 --> 01:17:51.180
und zur Laufzeit nach Machine-Code übersetzen können.

01:17:51.700 --> 01:17:53.780
Und deswegen ist JavaScript halt inzwischen,

01:17:55.260 --> 01:17:57.060
jetzt sage ich mal nicht ganz so schnell wie C,

01:17:57.220 --> 01:18:00.160
aber halt irgendwie vielleicht nur zwei oder dreimal langsamer als C.

01:18:00.720 --> 01:18:04.720
Und einfach weil da halt einfach viele Millionen Dollar

01:18:04.720 --> 01:18:06.900
in jeder von diesen Implementierungen reingesteckt wurde.

01:18:08.160 --> 01:18:11.520
so, deswegen inzwischen weiß halt jeder

01:18:11.520 --> 01:18:12.640
so ein bisschen, was ein JIT ist.

01:18:13.960 --> 01:18:15.440
Das war aber halt, als das Projekt

01:18:15.440 --> 01:18:17.500
anfing, nicht ganz so

01:18:17.500 --> 01:18:19.520
sehr so. Es gab halt damals,

01:18:19.960 --> 01:18:21.480
ich weiß nicht, sagt euch Psycho

01:18:21.480 --> 01:18:23.120
was? Ja, klar.

01:18:25.260 --> 01:18:25.600
Und das ist

01:18:25.600 --> 01:18:27.660
so ein bisschen, jetzt sind wir stark in der

01:18:27.660 --> 01:18:29.060
Ancient Python History drin.

01:18:29.440 --> 01:18:31.320
Also das war so ein Extension-Module

01:18:31.320 --> 01:18:33.900
für Python 2.2.

01:18:36.200 --> 01:18:37.100
Jetzt kommt raus,

01:18:37.560 --> 01:18:38.360
dass ich alt bin.

01:18:40.540 --> 01:18:41.860
Und das war

01:18:41.860 --> 01:18:43.660
quasi ein sehr, sehr schlauer

01:18:43.660 --> 01:18:45.720
promovierter Mathematiker, der hat

01:18:45.720 --> 01:18:47.260
dieses Extension-Modul geschrieben

01:18:47.260 --> 01:18:49.760
und das war quasi ein JIT für

01:18:49.760 --> 01:18:50.820
CPython.

01:18:51.820 --> 01:18:53.500
Wenn man das Extension-Modul

01:18:53.500 --> 01:18:55.580
geladen hat, dann hat halt

01:18:55.580 --> 01:18:57.540
Zyko angefangen, zur Laufzeit aus

01:18:57.540 --> 01:18:59.960
den Python-Funktionen halt irgendwie Maschinencode zu erzeugen.

01:19:00.440 --> 01:19:01.540
Und das hat halt auch gut

01:19:01.540 --> 01:19:02.660
funktioniert an vielen Stellen.

01:19:03.400 --> 01:19:05.060
Und das große Problem von Zyko war jetzt aber,

01:19:05.760 --> 01:19:09.020
dass jede neue Python-Version, die rauskam,

01:19:09.060 --> 01:19:10.100
hat das komplett kaputt gemacht.

01:19:11.440 --> 01:19:14.860
Also weil, sobald ein neues Sprachfeature dazukam,

01:19:15.740 --> 01:19:18.480
musste der Armin, Armin Rigo heißt das,

01:19:18.780 --> 01:19:22.340
musste dieses Extension-Modul halt wieder im Wesentlichen

01:19:22.340 --> 01:19:24.420
jetzt nicht von Null schreiben,

01:19:24.580 --> 01:19:27.900
aber halt quasi jede Zeile nochmal neu überdenken.

01:19:28.180 --> 01:19:30.080
Weil es halt quasi immer so Interaktionen

01:19:30.080 --> 01:19:32.960
zwischen den neuen Sprachfeaturen und den alten Sprachfeaturen gibt.

01:19:33.420 --> 01:19:34.740
Und die waren halt nicht zu übersehen.

01:19:35.720 --> 01:19:37.580
Also da, ich weiß nicht, was kam in 2.3

01:19:37.580 --> 01:19:39.540
dazu? Vielleicht Generatoren

01:19:39.540 --> 01:19:40.000
oder so?

01:19:41.220 --> 01:19:43.180
Gab es da nicht auch irgendwelche Scoping-Änderungen?

01:19:43.880 --> 01:19:45.440
Weiß es nicht, ja kann sein, ich weiß es

01:19:45.440 --> 01:19:46.700
nicht mehr genau, ja, aber...

01:19:46.700 --> 01:19:49.200
Ja, krass, ne, also krass.

01:19:50.080 --> 01:19:51.440
Auf jeden Fall, die haben

01:19:51.440 --> 01:19:52.880
halt dann immer nicht funktioniert in Psycho

01:19:52.880 --> 01:19:55.040
und Armin hat halt irgendwann dann auch aufgegeben.

01:19:55.200 --> 01:19:56.640
Also Psycho ist, glaube ich, seit 2.4

01:19:56.640 --> 01:19:59.120
oder 2.5 einfach auch tot.

01:20:00.840 --> 01:20:01.200
Und

01:20:01.200 --> 01:20:03.200
er hat halt aus

01:20:03.200 --> 01:20:05.420
dieser Frustration raus dann angefangen

01:20:05.420 --> 01:20:07.500
sich in PyPy, also

01:20:07.500 --> 01:20:09.500
war einer der Projektgründer von PyPy

01:20:09.500 --> 01:20:11.100
und hat halt

01:20:11.100 --> 01:20:13.560
aus dieser Frustration

01:20:13.560 --> 01:20:15.020
raus, dass man den JIT

01:20:15.020 --> 01:20:17.440
aus Psycho für jede Version von Hand

01:20:17.440 --> 01:20:18.280
dann anpassen muss,

01:20:19.340 --> 01:20:21.500
sich so eine, sag ich mal,

01:20:21.600 --> 01:20:23.340
relativ gewagte akademische Idee

01:20:23.340 --> 01:20:24.660
ausgesucht,

01:20:25.120 --> 01:20:26.940
die er gerne auf PyPy anwenden wollte.

01:20:27.880 --> 01:20:29.360
Und das ist eben die Idee, dass man den JIT

01:20:29.360 --> 01:20:31.080
über, also JIT heißt,

01:20:31.560 --> 01:20:32.900
das ist die Abkürzung Justin Timecubiler,

01:20:33.540 --> 01:20:34.940
dass man den überhaupt nicht von Hand schreibt.

01:20:35.420 --> 01:20:50.060
Und eben weil Python eine Sprache ist, die sich ständig ändert. Also einmal im Jahr oder vielleicht damals war es alle anderthalb Jahre, kommt eine neue Python-Version raus, da gibt es neue Sprachfeature und das Anpassen des JIT-Compilers an die neuen Sprachfeatures, das ist zu nervig.

01:20:51.020 --> 01:20:52.740
Insbesondere, wenn man halt nicht irgendwie

01:20:52.740 --> 01:20:54.820
Google-Geld hat. Wenn man Google-Geld hat,

01:20:54.880 --> 01:20:56.700
dann kann man halt einfach 20 Ingenieure

01:20:56.700 --> 01:20:58.580
auf das Problem reißen und

01:20:58.580 --> 01:21:00.800
die haben dann halt keinen Spaß, die schreiben ganz, ganz

01:21:00.800 --> 01:21:02.820
viel komplizierten C++-Code und sind halt

01:21:02.820 --> 01:21:04.820
jede Woche

01:21:04.820 --> 01:21:05.560
sehr traurig.

01:21:06.840 --> 01:21:08.740
Aber wenn man dieses Budget halt nicht hat,

01:21:09.240 --> 01:21:11.060
dann ist es einfach zu anstrengend,

01:21:11.280 --> 01:21:12.800
mit C-Python mitzuhalten, also mit der

01:21:12.800 --> 01:21:14.720
Sprachentwicklung mitzuhalten. Und deswegen hatte

01:21:14.720 --> 01:21:16.120
er eben die Idee, dass es

01:21:16.120 --> 01:21:18.540
doch irgendwie möglich sein sollte,

01:21:18.540 --> 01:21:20.480
den JIT-Compiler automatisch

01:21:20.480 --> 01:21:21.080
zu generieren.

01:21:22.660 --> 01:21:24.500
Und das ist

01:21:24.500 --> 01:21:26.180
so ein bisschen so eine alte,

01:21:27.820 --> 01:21:28.760
sehr akademische

01:21:28.760 --> 01:21:29.620
Idee, also

01:21:29.620 --> 01:21:31.360
da gibt es halt irgendwie

01:21:31.360 --> 01:21:34.380
in den, ich glaube in den Ende der 70er

01:21:34.380 --> 01:21:36.280
gab es so einen Aufsatz von Futamura,

01:21:37.260 --> 01:21:38.520
irgendwie, weiß nicht

01:21:38.520 --> 01:21:40.400
genau wie der Titel ist, Compiler, Compiler,

01:21:40.880 --> 01:21:42.400
da gab es eben schon mal die Idee,

01:21:42.500 --> 01:21:44.480
dass es theoretisch eben sein sollte, möglich sein

01:21:44.480 --> 01:21:46.220
sollte, einen Compiler für eine Sprache

01:21:46.220 --> 01:21:48.400
automatisch zu erzeugen, aus

01:21:48.400 --> 01:21:49.700
einem Interpreter für die Sprache.

01:21:50.480 --> 01:21:53.600
Und das war aber halt ein sehr akademischer Ansatz.

01:21:53.600 --> 01:21:57.620
Ich meine, ein Compiler-Compiler und so, das ist ja Jack und so.

01:21:57.900 --> 01:21:59.980
Ja, aber da ist der Input halt kein Interpreter.

01:22:00.180 --> 01:22:01.260
Nee, nee, das ist Grammatik, ja.

01:22:03.720 --> 01:22:06.820
Aber die Idee von der Mura-Projektion ist eben wirklich,

01:22:06.880 --> 01:22:08.040
man hat einen Interpreter für eine Sprache

01:22:08.040 --> 01:22:10.320
und erzeugt mit einem komplizierten Prozess

01:22:10.320 --> 01:22:12.060
aus dem Interpreter automatisch einen Compiler.

01:22:12.880 --> 01:22:14.760
Und das gab es quasi als akademische Idee,

01:22:14.840 --> 01:22:16.080
da gab es auch ein ganzes Forschungsfeld

01:22:16.080 --> 01:22:19.320
und ganz unglaublich viele Aufsätze zu.

01:22:20.480 --> 01:22:22.320
Aber das hat sich halt in der Praxis

01:22:22.320 --> 01:22:24.240
nicht so richtig umgesetzt. Und Armin

01:22:24.240 --> 01:22:26.240
hat halt die Idee gehabt, wir machen das jetzt

01:22:26.240 --> 01:22:28.220
wir machen das jetzt einmal

01:22:28.220 --> 01:22:30.200
richtig. Also wir machen das jetzt

01:22:30.200 --> 01:22:31.220
halt, also

01:22:31.220 --> 01:22:34.260
das war, der hat sich in gewisser Weise auch sehr viel

01:22:34.260 --> 01:22:36.020
getraut. Er hat gesagt, ich hab jetzt diese Vision,

01:22:36.460 --> 01:22:38.200
das müsste doch irgendwie gehen und wir

01:22:38.200 --> 01:22:40.040
wollen das jetzt für eine echte Sprache halt auch

01:22:40.040 --> 01:22:42.060
wirklich dann mal anwenden. Und

01:22:42.060 --> 01:22:44.000
in gewisser Weise ist das Problem natürlich auch noch

01:22:44.000 --> 01:22:46.260
erstmal schwieriger, weil er nicht nur einen Compiler

01:22:46.260 --> 01:22:47.680
wollte, er wollte halt einen JIT-Compiler.

01:22:49.260 --> 01:22:49.620
Und

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

01:23:06.260 --> 01:23:20.900
Und das haben wir dann halt in den verschiedenen PyPi-Research-Projekten auch dann gemacht. Das ging auch ganz schön lange nicht. Also es hat halt wirklich dann auch ein paar Jahre gedauert, bis es dann wirklich auch funktioniert hat.

01:23:20.900 --> 01:23:22.960
Also PyPy ist ein Compiler-Compiler.

01:23:23.640 --> 01:23:27.060
Also PyPy hat so ein paar Komponenten,

01:23:27.120 --> 01:23:31.340
aber eine der Komponenten ist wirklich quasi ein JIT-Compiler-Generator.

01:23:32.280 --> 01:23:36.540
Und du steckst quasi einen Interpreter in diesen JIT-Compiler-Generator raus

01:23:36.540 --> 01:23:41.300
und der Output davon ist ein JIT-Compiler für die Sprache,

01:23:41.920 --> 01:23:46.840
die von deinem Interpreter spezifiziert wird.

01:23:47.660 --> 01:23:49.960
Und das hat riesen Vorteile, weil nämlich,

01:23:50.880 --> 01:23:55.220
Wenn, also nehmen wir mal sowas Konkretes wie Pattern Matching.

01:23:55.760 --> 01:23:57.960
Pattern Matching kommt jetzt raus in 3.10.

01:23:58.900 --> 01:24:01.920
Dann implementieren wir das in unserem Interpreter.

01:24:03.120 --> 01:24:04.720
Also PyPy ist ein Interpreter für Python.

01:24:05.600 --> 01:24:07.820
Und wir müssen das Feature halt implementieren,

01:24:07.920 --> 01:24:10.420
weil unser Interpreter, der kann das erstmal nicht.

01:24:10.500 --> 01:24:11.760
Also ihr implementiert das aber in C?

01:24:12.360 --> 01:24:12.840
Nee.

01:24:13.380 --> 01:24:13.920
In R-Python.

01:24:13.940 --> 01:24:14.780
In R-Python, genau.

01:24:14.980 --> 01:24:15.520
Das ist alles in R-Python.

01:24:16.040 --> 01:24:20.120
Aber wir interpretieren das quasi in dem in R-Python geschriebenen Interpreter.

01:24:20.800 --> 01:24:34.840
Und dann drücken wir auf den Knopf und dann kommt der JIT-Compiler-Generator und der nimmt den Interpreter mit dem neuen Feature und dann haben wir plötzlich einen JIT-Compiler, der quasi Pattern-Matching versteht und richtig guten Maschinen-Code für Pattern-Matching erzeugt.

01:24:37.220 --> 01:24:52.000
Und der JIT-Compiler-Generator, der kennt Pattern-Matching halt gar nicht, sondern der lernt die Semantik von Pattern-Matching halt wirklich, indem er sich anschaut, was der Interpreter macht, um die Patterns auszuführen.

01:24:53.120 --> 01:25:09.360
Aber das heißt eben, wir müssen nicht, wenn so eine neue Version rauskommt, müssen wir nicht jedes Mal den JIT-Compiler anfassen, weil der JIT-Compiler, der kann halt überhaupt kein Python, sondern der kriegt halt die Semantik von Python ab, indem er sich diesen Interpreter für Python anschaut.

01:25:09.360 --> 01:25:19.000
Und wenn man in den Interpreter für Python neue Features einbaut, dann hat man immer automatisch auch noch, kann man eben für diese neuen Features dann auch den JIT generieren.

01:25:20.060 --> 01:25:22.440
Aber ein weiterer Vorteil, den man damit dann eventuell

01:25:22.440 --> 01:25:24.400
hätte, ist, man kann dann damit ja

01:25:24.400 --> 01:25:25.960
einen JIT-Compiler für jede Sprache

01:25:25.960 --> 01:25:28.480
erzeugen, für die man

01:25:28.480 --> 01:25:30.420
in R-Prize einen Interpreter schreiben kann.

01:25:30.800 --> 01:25:32.180
Das geht ja dann wahrscheinlich für viele Sprachen.

01:25:32.180 --> 01:25:34.360
Ja, zum Beispiel, wir hatten da schon ein Beispiel vorhin,

01:25:34.440 --> 01:25:35.180
für reguläre Ausdrücke.

01:25:36.640 --> 01:25:38.200
Also wir hatten ja vorhin gesagt, dass wir halt

01:25:38.200 --> 01:25:40.400
relativ gut darin sind, reguläre Ausdrücke auszuführen

01:25:40.400 --> 01:25:41.620
und das liegt halt einfach daran, dass

01:25:41.620 --> 01:25:43.820
in Python ist das auch schon so,

01:25:44.180 --> 01:25:46.260
reguläre Ausdrücke, die werden in so

01:25:46.260 --> 01:25:48.320
einen kleinen Bytecode erzeugt,

01:25:48.360 --> 01:25:51.640
übersetzt. Das ist ein anderer Bytecode

01:25:51.640 --> 01:25:53.400
als der Python-Bytecode. Und dafür

01:25:53.400 --> 01:25:55.280
gibt es dann einen Interpreter, der Teil von

01:25:55.280 --> 01:25:57.160
C-Python ist. Also C-Python hat halt

01:25:57.160 --> 01:25:59.340
den Interpreter für Python,

01:25:59.420 --> 01:26:00.980
aber eben auch noch einen anderen Interpreter für

01:26:00.980 --> 01:26:02.920
die regulären Ausdrücke Bytecodes.

01:26:03.580 --> 01:26:05.120
Und den haben wir halt auch in R-Python geschrieben.

01:26:05.820 --> 01:26:07.400
Und das heißt, wir können halt auch zur Laufzeit

01:26:07.400 --> 01:26:09.420
dann die regulären Ausdrücke nach Machine Code

01:26:09.420 --> 01:26:11.340
übersetzen. Weil

01:26:11.340 --> 01:26:12.960
wir halt quasi für diesen

01:26:12.960 --> 01:26:15.240
anderen Interpreter, der auch in R-Python

01:26:15.240 --> 01:26:17.300
geschrieben ist, auch ein JIT erzeugen.

01:26:18.360 --> 01:26:37.500
Und tatsächlich gibt es halt so einen ganzen Haufen an Research-Quality-Sprachimplementierung, die halt diese ganze Maschinerie auch benutzen, um alle möglichen Experimente zu machen. Also wir haben halt auch mal eine Ruby-Implementierung geschrieben und eine PHP-Implementierung geschrieben und eine Prolog geschrieben, das war meine Bachelorarbeit.

01:26:38.500 --> 01:26:59.220
Und die sind jetzt alle nicht so cool, ja, also da wurde halt einfach nicht der Aufwand reingesteckt, den man betreiben müsste, um da jetzt wirklich, sag ich mal, eine Production-Ruby-Implementierung dann rauszukriegen, ja, aber also das war halt eher so dann der Versuch zu gucken, ob das mit Ruby auch geht oder mit Prolog auch geht.

01:27:00.660 --> 01:27:29.180
Ich habe zum Beispiel auch mal, also auch nur Research Quality, ich habe zum Beispiel auch mal eine Datenbank darin implementiert. Also ich habe halt eine SQLite-kompatible, also SQLite kompiliert halt den SQL-Code auch in so ein Bytecode. Dafür habe ich halt auch einen Interpreter in Erpreisen geschrieben. Und damit kann man halt dann auch ganz interessante Performance-Gewinne sich dann irgendwie abholen.

01:27:29.180 --> 01:27:31.740
Ja, die Datenbank muss das ja auch

01:27:31.740 --> 01:27:33.260
interpretieren, was da an Queries so kommt.

01:27:33.440 --> 01:27:35.300
Und das ist ja auch, ich meine,

01:27:35.680 --> 01:27:37.500
das weiß man ja auch immer so ein bisschen, dass

01:27:37.500 --> 01:27:39.720
das SQLite mit den

01:27:39.720 --> 01:27:41.800
Typen der

01:27:41.800 --> 01:27:43.000
Spalten auch nicht so ernst nimmt.

01:27:43.200 --> 01:27:45.360
Ja, da kann man ja, oder

01:27:45.360 --> 01:27:47.620
String beides. Das heißt, es ist auch noch eine dynamische

01:27:47.620 --> 01:27:49.780
Sprache, eine dynamisch zivilisierte Programmiersprache.

01:27:49.960 --> 01:27:51.700
Also da gibt es halt dann schon ganz schön viele Ähnlichkeiten

01:27:51.700 --> 01:27:53.760
zur Ausführung

01:27:53.760 --> 01:27:55.040
von Python, in gewisser Weise.

01:27:56.140 --> 01:27:56.920
Naja, auf jeden Fall

01:27:56.920 --> 01:27:58.680
diese Idee, dass wir halt quasi ein

01:27:58.680 --> 01:28:00.200
JIT-Generator haben

01:28:00.200 --> 01:28:02.600
und diese

01:28:02.600 --> 01:28:05.140
Architektur sorgt dafür, dass wir halt

01:28:05.140 --> 01:28:07.000
mit einem relativ kleinen

01:28:07.000 --> 01:28:09.000
Team halt

01:28:09.000 --> 01:28:11.040
mit CPython trotzdem ganz gut mithalten

01:28:11.040 --> 01:28:13.020
können, weil wir die Features halt

01:28:13.020 --> 01:28:15.140
eben nicht in den JIT-Compiler

01:28:15.140 --> 01:28:16.900
reinschreiben, reinprogrammieren

01:28:16.900 --> 01:28:19.180
müssen, sondern halt quasi

01:28:19.180 --> 01:28:21.080
nur in einen Interpreter

01:28:21.080 --> 01:28:23.020
und der JIT-Compiler, der kriegt

01:28:23.020 --> 01:28:24.180
die Features dann automatisch.

01:28:24.820 --> 01:28:27.080
Das war jetzt, so ein paar Verallgemeinerungen

01:28:27.080 --> 01:28:29.100
waren jetzt, also so ein paar Ungenauigkeiten

01:28:29.100 --> 01:28:30.360
waren in meiner Story jetzt noch drin.

01:28:31.540 --> 01:28:33.040
Es gibt dann noch so extra

01:28:33.040 --> 01:28:35.040
Annotationen, die nennen wir ja irgendwie

01:28:35.040 --> 01:28:37.060
Hints. Man kann halt quasi dem

01:28:37.060 --> 01:28:38.860
JIT-Compiler dann noch so ein paar Tipps geben.

01:28:39.300 --> 01:28:41.020
Ja, weil wahrscheinlich manchmal wird das halt dann

01:28:41.020 --> 01:28:42.760
überraschend nicht gut funktionieren.

01:28:42.760 --> 01:28:45.000
Ganz genau. Und man

01:28:45.000 --> 01:28:46.880
kriegt halt dann einen Maschinencode und der ist

01:28:46.880 --> 01:28:48.340
vielleicht noch nicht so gut, wie man den gerne hätte.

01:28:48.620 --> 01:28:50.980
Und dann fügt man halt noch so ein paar Annotationen ein und kann

01:28:50.980 --> 01:28:53.480
dann dem JIT-Compiler-Generator

01:28:53.480 --> 01:28:54.900
helfen, doch noch

01:28:54.900 --> 01:28:56.260
einen besseren JIT zu generieren.

01:28:56.920 --> 01:28:57.880
Und das muss man dann

01:28:57.880 --> 01:29:00.700
an verschiedenen Stellen auch immer mal machen. Also zum Beispiel

01:29:00.700 --> 01:29:02.940
ich würde jetzt meine Hand nicht ins Feuer legen,

01:29:03.040 --> 01:29:04.720
dass Pattern Matching halt jetzt

01:29:04.720 --> 01:29:06.720
schon ultra schnell ist. Also wir haben halt

01:29:06.720 --> 01:29:08.800
ein JIT für Pattern Matching, aber ich weiß noch

01:29:08.800 --> 01:29:10.840
nicht, ich habe es noch nicht gemessen, ob es wirklich ein ganz

01:29:10.840 --> 01:29:12.760
toller JIT ist. Ja, das ist eh ziemlich

01:29:12.760 --> 01:29:13.280
langsam, ne?

01:29:14.700 --> 01:29:16.580
In Zebraten ist es nicht so toll, oder?

01:29:16.700 --> 01:29:18.800
Ich weiß nicht, was... Ich glaube, also habe ich gehört, dass es nicht so

01:29:18.800 --> 01:29:20.120
schnell ist. Ich weiß es nicht, ja.

01:29:20.660 --> 01:29:22.480
Also ob das jetzt bei uns...

01:29:22.480 --> 01:29:24.760
Wir würden halt dann wirklich aus

01:29:24.760 --> 01:29:26.260
dem Pattern Matching Maschinencode erzeugen

01:29:26.260 --> 01:29:28.520
und ich weiß halt noch nicht so richtig, ob das

01:29:28.520 --> 01:29:30.520
richtig guter Maschinencode ist oder ob das halt einfach nur

01:29:30.520 --> 01:29:32.620
irgendwie so ein bisschen leicht schrottiger

01:29:32.620 --> 01:29:34.440
Maschinencode ist. Und wenn man das

01:29:34.440 --> 01:29:35.640
verbessern will, dann würde man halt

01:29:35.640 --> 01:29:38.640
hergehen und sagen, na gut, was für extra

01:29:38.640 --> 01:29:39.980
Hilfen können wir dem Jit noch geben?

01:29:40.320 --> 01:29:41.660
Das habe ich jetzt halt noch nicht gemacht, weil

01:29:41.660 --> 01:29:44.600
ich meine, das ist

01:29:44.600 --> 01:29:46.520
halt immer so ein bisschen, das kommt halt als

01:29:46.520 --> 01:29:48.360
letztes. Du musst ja quasi aber immer den

01:29:48.360 --> 01:29:50.500
Generator anlehnen, du kannst halt quasi nie richtig in der Hand

01:29:50.500 --> 01:29:52.380
was wirklich da liegt an C-Code, der hinterher

01:29:52.380 --> 01:29:53.160
ausgeführt wird.

01:29:55.220 --> 01:29:56.040
Also indirekt.

01:29:56.260 --> 01:29:59.060
Moment, warum C-Code?

01:29:59.960 --> 01:30:01.640
Ja, weil du doch dem Generator

01:30:01.640 --> 01:30:03.480
sagst, was er tun soll, der den C-Code

01:30:03.480 --> 01:30:05.140
generiert, der dann hinterher ausgeführt wird.

01:30:05.160 --> 01:30:07.040
Ja, der C-Code ist dir eigentlich so ein bisschen egal.

01:30:07.540 --> 01:30:09.260
Also wichtig ist halt, du generierst einmal

01:30:09.260 --> 01:30:11.280
C-Code, aber du generierst halt auch

01:30:11.280 --> 01:30:12.520
noch einen

01:30:12.520 --> 01:30:15.400
JIT. Und der JIT,

01:30:15.460 --> 01:30:17.340
der übersetzt den Python-Code nicht

01:30:17.340 --> 01:30:19.360
nach C-Code, sondern wirklich direkt nach Machine-Code.

01:30:20.260 --> 01:30:21.400
Also wir erzeugen dann

01:30:21.400 --> 01:30:23.280
wirklich, wir nehmen den Python-Code, führen den aus

01:30:23.280 --> 01:30:25.180
und nach einer Weile sagen wir halt, oh, okay,

01:30:25.280 --> 01:30:27.200
diese Schleife hier, die scheint irgendwie wichtig

01:30:27.200 --> 01:30:29.300
zu sein. Und dann nehmen wir wirklich diese Schleife

01:30:29.300 --> 01:30:31.080
und erzeugen daraus halt

01:30:31.080 --> 01:30:33.220
wirklich direkt ins RAM

01:30:33.220 --> 01:30:35.200
Maschinen-Code-Instruktionen. Und das geht

01:30:35.200 --> 01:30:36.480
halt nicht mehr den Umweg über C.

01:30:36.720 --> 01:30:39.060
Den Umweg über C brauchen wir nur, um einmal

01:30:39.060 --> 01:30:41.100
das Binary zu erzeugen. Das machen

01:30:41.100 --> 01:30:42.460
halt wir einmal auf unserem Server.

01:30:43.060 --> 01:30:44.260
Und das passiert aber dann quasi

01:30:44.260 --> 01:30:46.840
nach dem Deployment auf

01:30:46.840 --> 01:30:49.220
die Produktivumgebung nicht mehr.

01:30:49.340 --> 01:30:50.420
Sondern da wird halt wirklich direkt

01:30:50.420 --> 01:30:52.960
ins RAM werden halt

01:30:52.960 --> 01:30:54.160
die Maschinen-Instruktionen für

01:30:54.160 --> 01:30:56.840
die aktuelle CPU-Architektur

01:30:56.840 --> 01:30:58.400
emittet

01:30:58.400 --> 01:30:59.900
und dann führen wir das halt direkt raus.

01:31:01.120 --> 01:31:02.380
Also sprich, wenn du das halt

01:31:02.380 --> 01:31:04.460
auf irgendwie so einem

01:31:04.460 --> 01:31:06.180
x86-Server laufen lässt,

01:31:06.520 --> 01:31:08.340
dann schnappen wir uns halt einfach

01:31:08.340 --> 01:31:10.160
vom Betriebssystem so einen großen Buffer

01:31:10.160 --> 01:31:12.040
an RAM

01:31:12.040 --> 01:31:14.340
und da

01:31:14.340 --> 01:31:16.080
kommen halt dann irgendwelche Instruktionen rein

01:31:16.080 --> 01:31:18.180
und dann wird der Buffer

01:31:18.180 --> 01:31:20.180
als ausführbar markiert und dann

01:31:20.180 --> 01:31:21.720
springen wir einfach hin.

01:31:22.020 --> 01:31:35.460
Und dann von da an läuft halt wirklich der Machine Code und der, also wenn man Glück hat, ist der halt einfach dann auch sehr, sehr schnell, weil der das ganze teure Zeug, was in Python halt normalerweise die ganze Zeit passieren muss, halt nicht mehr macht.

01:31:36.020 --> 01:31:37.300
Und den ganzen Overhead von den ganzen Sachen.

01:31:37.300 --> 01:32:00.140
Ja, also man hat halt dann die Frame-Objekte nicht mehr, man hat die ganzen Typ-Überprüfungen nicht mehr, idealerweise. Also Python alloziert ja auch die ganze Zeit Speicher. Also jeder Integer ist ja so ein bisschen Heap-Memory. Also jede Addition macht halt einen Merlock-Aufruf. Und das ist ja eigentlich absurd teuer.

01:32:00.140 --> 01:32:02.160
also ein malloc-Aufruf und

01:32:02.160 --> 01:32:03.980
es wird eben

01:32:03.980 --> 01:32:06.400
der Reference-Count auch noch immer manipuliert

01:32:06.400 --> 01:32:07.560
also

01:32:07.560 --> 01:32:10.140
vielleicht auch nochmal ganz kurz für die Leute, die ja nicht ganz so tief sind

01:32:10.140 --> 01:32:12.060
ein malloc-Aufruf, also eine Memory-Location ist

01:32:12.060 --> 01:32:14.280
ein C, eine Funktion, die auf dem

01:32:14.280 --> 01:32:15.700
Heap was macht, vielleicht nochmal ganz kurz

01:32:15.700 --> 01:32:18.360
ganz tief rein erklären wir was Heap steckt

01:32:18.360 --> 01:32:20.360
vielleicht kann man

01:32:20.360 --> 01:32:22.540
das einfach nochmal so ein bisschen den Kontrast herstellen

01:32:22.540 --> 01:32:24.040
wir schreiben jetzt wirklich ein Programm in C

01:32:24.040 --> 01:32:26.040
und wenn du da halt irgendwie

01:32:26.040 --> 01:32:27.940
eine Integer-Variable, also

01:32:27.940 --> 01:32:29.540
Long A und Long B hast

01:32:29.540 --> 01:32:31.220
und dann machst du A plus B,

01:32:32.140 --> 01:32:34.160
dann sind A und B halt nicht

01:32:34.160 --> 01:32:35.780
auf dem Heap, sondern

01:32:35.780 --> 01:32:37.800
irgendwie direkt in CPU-Registern

01:32:37.800 --> 01:32:39.880
und die werden dann

01:32:39.880 --> 01:32:42.280
direkt von CPU-Instruktionen

01:32:42.280 --> 01:32:43.780
addiert und mit dem Ergebnis

01:32:43.780 --> 01:32:44.600
wird halt irgendwas gemacht.

01:32:46.300 --> 01:32:47.700
Wenn du den gleichen, wenn du irgendwie

01:32:47.700 --> 01:32:49.620
so ein Ausdruck wie A und B in Python

01:32:49.620 --> 01:32:51.680
hinschreibst und das in C-Python

01:32:51.680 --> 01:32:53.440
ausführst, dann ist das halt nicht,

01:32:54.000 --> 01:32:55.760
also die Integer-Werte, die sind dann

01:32:55.760 --> 01:32:57.380
nicht in CPU-Registern, sondern die sind

01:32:57.380 --> 01:32:58.920
quasi im RAM.

01:32:59.880 --> 01:33:01.820
Und um dann wirklich das Ergebnis berechnen zu können,

01:33:01.940 --> 01:33:03.860
musst du die Werte erstmal aus

01:33:03.860 --> 01:33:05.860
dem RAM, also erstmal musst du gucken,

01:33:06.680 --> 01:33:07.680
sind das überhaupt Integers,

01:33:07.740 --> 01:33:09.800
die ich da addiere. Und dann musst

01:33:09.800 --> 01:33:10.240
du gucken,

01:33:11.020 --> 01:33:13.940
dann musst du quasi die Werte

01:33:13.940 --> 01:33:15.720
der Integer aus dem Integer-Objekt

01:33:15.720 --> 01:33:17.880
vom RAM ins CPU-Register laden.

01:33:18.460 --> 01:33:19.800
Dann machst du wirklich die

01:33:19.800 --> 01:33:21.920
Addition. Dann musst du gucken,

01:33:22.060 --> 01:33:23.500
ob das Ergebnis immer noch

01:33:23.500 --> 01:33:25.660
klein genug ist, um in einen

01:33:25.660 --> 01:33:27.440
Maschinenwert reinzupassen. Das könnte ja auch

01:33:27.440 --> 01:33:29.520
irgendwie ein Overflow geben und dann brauchst du irgendwie

01:33:29.520 --> 01:33:30.880
ein komplizierteres Objekt.

01:33:31.440 --> 01:33:33.780
Und dann brauchst du Speicher

01:33:33.780 --> 01:33:35.740
für das Ergebnisobjekt, weil das Ergebnis ist

01:33:35.740 --> 01:33:37.520
ja auch wieder ein Integerobjekt. Das heißt, du rufst einmal

01:33:37.520 --> 01:33:39.800
Malog auf. Dann kriegst du ein neues

01:33:39.800 --> 01:33:41.720
Stück RAM zugewiesen

01:33:41.720 --> 01:33:43.700
von dem in C geschriebenen

01:33:43.700 --> 01:33:45.740
Allokator. Und

01:33:45.740 --> 01:33:47.880
dann packst du den Ergebnis

01:33:47.880 --> 01:33:49.660
Zahlenwert in dieses neue Stück

01:33:49.660 --> 01:33:51.760
RAM rein, erhöhst den

01:33:51.760 --> 01:33:53.380
Reference Count von diesem Stück RAM

01:33:53.380 --> 01:33:55.680
und das ist dann dein

01:33:55.680 --> 01:33:57.680
Ergebnisobjekt. Und das passiert

01:33:57.680 --> 01:33:59.420
aber halt bei jeder arithmetischen Operation

01:33:59.420 --> 01:34:01.700
und deswegen ist halt Arithmetik

01:34:01.700 --> 01:34:03.620
und wir haben auch noch so ein paar Schritte

01:34:03.620 --> 01:34:05.880
weggelassen, also deswegen ist Arithmetik

01:34:05.880 --> 01:34:07.220
halt in Python klassischerweise

01:34:07.220 --> 01:34:09.300
wirklich sehr, sehr ineffizient.

01:34:10.420 --> 01:34:11.420
Weil du halt wirklich

01:34:11.420 --> 01:34:13.860
ständig malloc aufrufst

01:34:13.860 --> 01:34:15.520
und auch ständig wieder free aufrufst. Zum Beispiel, wenn du

01:34:15.520 --> 01:34:17.520
jetzt so einen komplizierteren Ausdruck hast, wenn du

01:34:17.520 --> 01:34:19.560
halt sowas wie a mal 2 plus b

01:34:19.560 --> 01:34:21.440
das war ja unser Standard

01:34:21.440 --> 01:34:23.740
unser Standard

01:34:23.740 --> 01:34:24.920
arithmetischer Ausdruck schon die ganze Zeit,

01:34:25.400 --> 01:34:27.380
dann hast du halt das Zwischenergebnis

01:34:27.380 --> 01:34:28.100
A mal 2.

01:34:29.220 --> 01:34:30.420
Das brauchst du ja gar nicht lang.

01:34:31.640 --> 01:34:33.240
Das brauchst du ja quasi nur

01:34:33.240 --> 01:34:35.000
Das verfällt ja beim nächsten Aufruf.

01:34:35.440 --> 01:34:37.140
Das heißt, beim nächsten Aufruf, wenn du

01:34:37.140 --> 01:34:38.660
dann das Plus rechnest,

01:34:39.280 --> 01:34:41.160
dann verringerst du den

01:34:41.160 --> 01:34:43.380
Reference Count von dem Zwischenergebnis

01:34:43.380 --> 01:34:45.360
und dann sagst du, oh, das ist

01:34:45.360 --> 01:34:47.320
ja jetzt 0. Das brauche ich ja gar nicht mehr.

01:34:47.600 --> 01:34:48.600
Und dann rufst du Free auf.

01:34:49.280 --> 01:34:51.080
Das ist wieder quasi so ein teurer

01:34:51.080 --> 01:34:53.120
Aufruf zu dem

01:34:53.120 --> 01:34:55.020
Memory-Subsystem.

01:34:55.200 --> 01:34:57.120
Wie genau schreibt der Null den Speicher oder löscht der einfach

01:34:57.120 --> 01:34:59.160
die Speicheradresse aus, dem wir

01:34:59.160 --> 01:35:01.160
benutzen das? Genau, und dann kannst du

01:35:01.160 --> 01:35:03.220
quasi den Speicher wiederverwenden, das nächste Mal,

01:35:03.340 --> 01:35:05.140
wenn jemand mehr drauf hat. Aber der schreibt dann nicht vorher irgendwie

01:35:05.140 --> 01:35:07.020
was rein? Doch,

01:35:07.140 --> 01:35:08.360
der muss das dann schon halt,

01:35:08.900 --> 01:35:11.180
der muss sich schon irgendwie merken, dass der Speicher jetzt verwendet

01:35:11.180 --> 01:35:12.360
werden kann. Also es gibt halt so ein bisschen,

01:35:13.020 --> 01:35:14.300
es gibt quasi so ein bisschen

01:35:14.300 --> 01:35:17.020
Overhead-Datenstrukturen, die

01:35:17.020 --> 01:35:18.560
verwendet werden, um

01:35:18.560 --> 01:35:20.960
ja, um sich zu merken, dass

01:35:20.960 --> 01:35:22.400
dass das jetzt ein Stück freier Speicher ist.

01:35:22.700 --> 01:35:24.820
Am Anfang von einem Speicherblock schreibt der irgendwie

01:35:24.820 --> 01:35:26.540
so ein... Das ist

01:35:26.540 --> 01:35:28.680
glaube ich gar nicht so wichtig. Das funktioniert

01:35:28.680 --> 01:35:30.600
auch sehr unterschiedlich, je nach Betriebsstil und

01:35:30.600 --> 01:35:31.280
je nach

01:35:31.280 --> 01:35:34.620
verwendetem

01:35:34.620 --> 01:35:36.640
Allokator. Also da gibt es halt auch

01:35:36.640 --> 01:35:38.660
verschiedene C-Bibliotheken, die man da verwenden kann.

01:35:40.280 --> 01:35:40.880
C-Python

01:35:40.880 --> 01:35:42.760
hat da auch so ein bisschen seine eigenen Algorithmen,

01:35:42.900 --> 01:35:43.020
die

01:35:43.020 --> 01:35:46.600
für den typischen Use Case, der

01:35:46.600 --> 01:35:48.640
halt in Python besonders oft auftritt,

01:35:48.840 --> 01:35:49.560
dann optimiert ist.

01:35:50.520 --> 01:35:52.420
Also da ist quasi dann ganz, ganz viel

01:35:52.420 --> 01:35:53.320
Engineering und

01:35:53.320 --> 01:35:56.620
das ist kompliziert und wir müssen

01:35:56.620 --> 01:35:57.600
das hoffentlich nicht verstehen.

01:35:57.840 --> 01:35:59.980
Also das ist quasi,

01:36:00.740 --> 01:36:01.860
da kenne ich mich dann irgendwann

01:36:01.860 --> 01:36:03.140
ziemlich schnell halt auch nicht aus.

01:36:04.480 --> 01:36:06.000
Ja, aber letztlich,

01:36:06.160 --> 01:36:07.360
das Problem ist halt, dass es halt,

01:36:08.000 --> 01:36:10.480
Speicheralluzien

01:36:10.480 --> 01:36:12.060
ist halt eine relativ komplexe,

01:36:12.160 --> 01:36:14.100
weil man halt auch das Betriebssystem, den Kernel,

01:36:14.140 --> 01:36:15.060
fragen muss letztlich.

01:36:15.540 --> 01:36:18.360
Nicht jedes Mal, aber irgendwann schon.

01:36:18.580 --> 01:36:20.460
Letztlich. Und dann, das ist natürlich alles sauteuer.

01:36:20.520 --> 01:36:22.440
Ja. Und dieser ganze

01:36:22.440 --> 01:36:24.320
Overhead fällt halt weg, wenn du A plus B

01:36:24.320 --> 01:36:26.660
mal C mit ins ausführst

01:36:26.660 --> 01:36:28.440
und der JIT ging da drüber,

01:36:28.980 --> 01:36:30.240
dann hast du halt wirklich auch,

01:36:30.740 --> 01:36:32.420
dann allozierst du dieses Zwischenergebnis auch nicht.

01:36:33.180 --> 01:36:34.480
Sondern dann sagst du halt einfach

01:36:34.480 --> 01:36:35.760
na gut, A

01:36:35.760 --> 01:36:37.520
kommt in den Maschinenregister,

01:36:38.560 --> 01:36:40.440
das mal zwei, zwei ist halt irgendwie

01:36:40.440 --> 01:36:41.740
so ein Intermediate in deiner

01:36:41.740 --> 01:36:44.400
Maschineninstruction

01:36:44.400 --> 01:36:46.440
und dann hast du noch eine zweite Maschineninstruction,

01:36:46.600 --> 01:36:48.120
um die Addition zu machen

01:36:48.120 --> 01:36:50.420
und das Ergebnis ist auch in dem Register, je nachdem

01:36:50.420 --> 01:36:51.480
was mit dem Ergebnis passiert,

01:36:52.300 --> 01:36:53.100
kann es da auch bleiben.

01:36:55.000 --> 01:36:56.160
Wenn du dann

01:36:56.160 --> 01:36:58.080
einen Return hast, dann kann das quasi

01:36:58.080 --> 01:36:59.480
im

01:36:59.480 --> 01:37:02.240
Return-Register der CPU halt auch dann

01:37:02.240 --> 01:37:04.360
einfach weiterverwendet werden

01:37:04.360 --> 01:37:05.580
vom Aufrufer, so ein bisschen,

01:37:06.640 --> 01:37:07.820
wenn alles genau richtig ist,

01:37:08.240 --> 01:37:10.240
wenn alles genau richtig läuft. Und dann

01:37:10.240 --> 01:37:12.060
fällt halt einfach ganz, ganz, ganz viel overhead,

01:37:12.400 --> 01:37:14.460
die normale

01:37:14.460 --> 01:37:16.220
Python-Implementierung halt immer machen

01:37:16.220 --> 01:37:17.100
muss, fällt halt weg.

01:37:19.880 --> 01:37:20.320
Ja.

01:37:20.420 --> 01:37:22.040
Und ich meine, so ein bisschen die

01:37:22.040 --> 01:37:24.140
Einsicht, also warum man halt Python

01:37:24.140 --> 01:37:26.160
überhaupt optimieren kann, ist,

01:37:27.180 --> 01:37:28.120
es ist theoretisch

01:37:28.120 --> 01:37:30.100
alles sehr dynamisch, aber in der

01:37:30.100 --> 01:37:32.340
Praxis nicht. Also die

01:37:32.340 --> 01:37:34.260
dynamischen Möglichkeiten, die werden

01:37:34.260 --> 01:37:36.060
halt... Sehr, sehr eng genutzt, tatsächlich.

01:37:36.580 --> 01:37:37.460
Ja, jetzt nicht selten,

01:37:38.200 --> 01:37:39.560
aber halt nicht immer.

01:37:40.420 --> 01:37:41.800
Also ich glaube halt,

01:37:41.940 --> 01:37:43.920
jedes Programm ist schon an irgendeiner Stelle dynamisch,

01:37:44.000 --> 01:37:44.780
aber nicht die ganze Zeit.

01:37:46.940 --> 01:37:48.160
Es ist zum Beispiel relativ oft

01:37:48.160 --> 01:37:50.100
so, dass man beim Importen halt ganz

01:37:50.100 --> 01:37:52.260
viel Zeug macht, aber danach nicht mehr.

01:37:53.020 --> 01:37:53.780
Das ist so ein

01:37:53.780 --> 01:37:55.800
Muster an Dynamischkeit.

01:37:56.540 --> 01:37:58.100
Also du importierst halt

01:37:58.100 --> 01:38:00.120
eine Bibliothek, beim Importieren machst du die ganz

01:38:00.120 --> 01:38:02.020
merkwürdige Sachen und machst halt so ein bisschen

01:38:02.020 --> 01:38:03.800
Metaprogrammierung und schreibst irgendwelche Sachen

01:38:03.800 --> 01:38:04.840
in das Globals-Dictionary

01:38:04.840 --> 01:38:08.340
mit einem Globals-Aufruf

01:38:08.340 --> 01:38:10.060
oder sowas, schreibst es da rein, aber dann

01:38:10.060 --> 01:38:12.180
ist fertig. Und danach ist alles

01:38:12.180 --> 01:38:12.820
quasi

01:38:12.820 --> 01:38:16.120
harmloser Python-Code,

01:38:16.120 --> 01:38:17.420
wo die Typen relativ fix sind.

01:38:18.200 --> 01:38:19.060
Also das ist so ein

01:38:20.040 --> 01:38:21.620
Eine Sache, die wir immer wieder sehen, da gibt es auch

01:38:21.620 --> 01:38:22.680
Aussätze zu, die das studieren.

01:38:22.900 --> 01:38:25.680
Das findet sich halt

01:38:25.680 --> 01:38:27.640
recht häufig wieder, dass man komische, dynamische Sachen

01:38:27.640 --> 01:38:29.720
am Anfang des Programms macht,

01:38:29.800 --> 01:38:30.600
aber dann irgendwann nicht mehr.

01:38:32.100 --> 01:38:33.680
Also so ein ORM ist

01:38:33.680 --> 01:38:35.700
halt auch so ein Beispiel. Man generiert

01:38:35.700 --> 01:38:36.820
halt dann so ein bisschen Klassen,

01:38:37.560 --> 01:38:39.840
aber das macht man halt nicht die ganze Zeit,

01:38:39.920 --> 01:38:40.440
sondern halt...

01:38:40.440 --> 01:38:45.840
Ja, oder halt so ein Debugger

01:38:45.840 --> 01:38:47.680
ist halt auch ein... Also ein Debugger braucht

01:38:47.680 --> 01:38:49.080
quasi ganz, ganz viele dynamische Features.

01:38:50.340 --> 01:38:51.860
Aber der ist halt meistens nicht an.

01:38:52.680 --> 01:38:53.700
Und du musst

01:38:53.700 --> 01:38:55.560
quasi die Möglichkeit haben, dass du den

01:38:55.560 --> 01:38:57.460
zu einem beliebigen Zeitpunkt

01:38:57.460 --> 01:38:59.440
anschalten kannst. Aber

01:38:59.440 --> 01:39:01.540
du solltest nicht die ganze Zeit den Preis dafür

01:39:01.540 --> 01:39:03.680
bezahlen müssen. Aber du willst dich halt

01:39:03.680 --> 01:39:05.100
auch nicht vorher entscheiden müssen.

01:39:06.500 --> 01:39:07.440
Ja, also du willst halt quasi

01:39:07.440 --> 01:39:09.360
trotzdem immer die Möglichkeit haben zu sagen,

01:39:09.480 --> 01:39:10.260
jetzt brauche ich den aber.

01:39:10.800 --> 01:39:13.480
Wenn es zu unterschiedlich ist, dann

01:39:13.480 --> 01:39:14.360
kann man nicht mehr debuggen.

01:39:15.860 --> 01:39:17.840
Du möchtest es ja dann machen können,

01:39:17.960 --> 01:39:19.140
wenn es eigentlich normal läuft.

01:39:19.140 --> 01:39:21.080
Und selbst wenn es jetzt halt nicht um den Debugger geht,

01:39:21.200 --> 01:39:22.960
also selbst halt sowas wie schöne

01:39:22.960 --> 01:39:25.020
Tracebacks, die dir halt auch noch die Locals rausschreiben

01:39:25.020 --> 01:39:26.600
oder so. Wenn halt

01:39:26.600 --> 01:39:28.980
dein Web-Server dann wirklich crasht, dann

01:39:28.980 --> 01:39:30.400
willst du diese Information halt haben.

01:39:31.200 --> 01:39:32.820
Und dann zu sagen, ja,

01:39:32.960 --> 01:39:35.120
ups, jetzt haben wir das aber so doll

01:39:35.120 --> 01:39:37.020
optimiert, dass wir, wir wissen halt gar

01:39:37.020 --> 01:39:38.080
nicht mehr, was die Locals sind.

01:39:39.080 --> 01:39:40.820
Also das kann dir halt passieren in so einem Compiler.

01:39:41.720 --> 01:39:43.040
Also in C gibt es

01:39:43.040 --> 01:39:44.880
das ja immer mal. Da musst du ja wirklich sagen, will ich

01:39:44.880 --> 01:39:46.660
jetzt Debugge-Informationen haben oder nicht.

01:39:47.140 --> 01:39:48.340
Und wenn du die nicht hast, dann kriegst du,

01:39:48.540 --> 01:39:50.760
dann sagt dir halt keiner mehr,

01:39:50.820 --> 01:39:52.460
was jetzt gerade in deiner Variable drinsteht.

01:39:53.500 --> 01:39:53.720
Und

01:39:53.720 --> 01:39:57.000
das, also

01:39:57.000 --> 01:39:58.800
meiner Ansicht nach gehört das halt zur

01:39:58.800 --> 01:40:00.980
Philosophie von Python auch dazu, dass man

01:40:00.980 --> 01:40:02.220
halt zu jedem Zeitpunkt

01:40:02.220 --> 01:40:04.960
das auch dann machen kann, wenn man

01:40:04.960 --> 01:40:06.900
halt in einer Situation landet, wo man

01:40:06.900 --> 01:40:08.980
die Informationen braucht.

01:40:10.800 --> 01:40:11.200
Ja.

01:40:12.320 --> 01:40:12.720
Genau.

01:40:14.880 --> 01:40:33.720
So, jetzt haben wir glaube ich so ein bisschen alle Ideen. Also historisch gesehen, Python in Python, also historisch gab es diese Verständigkeitsidee, die verschwindet ein bisschen. Also es gibt jetzt schon ganz viele Stellen, wo wir Sachen halt quasi komplizierter machen, um Performance zu kriegen.

01:40:34.100 --> 01:40:46.040
Also es ist jetzt nicht mehr nur so ein architektonisch reines Ding, womit man halt irgendwie die Sprache ganz toll verstehen kann, sondern halt wirklich viel pragmatischer und wir wollen halt auch wirklich schnell einen Code machen.

01:40:49.360 --> 01:40:51.440
Aber stattdessen kam halt diese andere Idee dazu.

01:40:51.560 --> 01:40:54.120
Wir wollen einen Just-in-Time-Copiler für die Sprache haben.

01:40:54.740 --> 01:40:58.080
Und weil sich die Sprache eben einmal im Jahr ändert,

01:40:59.020 --> 01:41:00.420
können wir den nicht von Hand schreiben,

01:41:00.780 --> 01:41:02.500
weil wir halt nicht Google-Geld haben,

01:41:02.600 --> 01:41:04.120
sondern irgendwie ein Open-Source-Projekt sind.

01:41:04.760 --> 01:41:07.260
Und stattdessen wurde halt dann dieser Forschungsansatz gewählt.

01:41:07.340 --> 01:41:08.580
Wir erzeugen den Just-in-Time-Copiler.

01:41:09.440 --> 01:41:11.720
Und das hat geklappt.

01:41:12.200 --> 01:41:14.040
Also das hätte auch schiefgehen können,

01:41:14.040 --> 01:41:16.820
aber die Kernidee funktioniert ganz gut.

01:41:17.520 --> 01:41:22.600
Und jetzt sind wir quasi so ein bisschen auf dem Plateau der Produktivität,

01:41:22.780 --> 01:41:26.900
dass die ganze Kerntechnologie, den DIT-Compiler zu erzeugen,

01:41:26.960 --> 01:41:28.260
die ist halt relativ stabil.

01:41:28.960 --> 01:41:30.820
Es gibt jetzt schon irgendwie da noch so ein paar Features,

01:41:30.940 --> 01:41:33.000
die wir gerne irgendwie mal machen würden,

01:41:33.120 --> 01:41:36.820
wenn wir mal ganz motiviert sind oder ganz viel Zeit haben.

01:41:36.820 --> 01:41:41.820
Aber so die ganzen Kernideen sind halt einfach jetzt inzwischen auch drin

01:41:42.300 --> 01:41:44.180
und stabil und halt über viele Jahre

01:41:44.180 --> 01:41:45.100
halt auch wirklich

01:41:45.100 --> 01:41:48.240
so ganz gut

01:41:48.240 --> 01:41:50.380
stabilisiert.

01:41:50.960 --> 01:41:52.260
Und jetzt sind wir halt an dem Punkt,

01:41:52.440 --> 01:41:52.680
dass wir,

01:41:53.960 --> 01:41:56.100
dass die Hauptarbeit, die wir

01:41:56.100 --> 01:41:57.680
wirklich machen, ist halt zu versuchen,

01:41:58.480 --> 01:42:00.200
von C-Python nicht komplett abgehängt zu werden.

01:42:01.380 --> 01:42:02.320
Ist A-Python,

01:42:02.400 --> 01:42:03.860
hat das Type Annotations zum Beispiel auch?

01:42:04.100 --> 01:42:05.040
Ja, jetzt kommen wir so,

01:42:05.260 --> 01:42:08.360
jetzt kommen wir zu ein paar der dunklen Geheimnisse.

01:42:10.540 --> 01:42:10.980
Also,

01:42:12.140 --> 01:42:17.880
PyPy ist so alt, dass es gegründet wurde, als Python 2.2, glaube ich, gerade aktuell war oder 2.3.

01:42:19.180 --> 01:42:25.320
Das heißt, R-Python ist leider tatsächlich noch komplett Python 2 basiert.

01:42:26.620 --> 01:42:41.160
Und wir haben halt leider auch sehr, sehr wenig Motivation, das zu ändern, weil wir haben halt leider sowas wie, sage ich mal, eine halbe Million Zeilen Code in diesem blöden Python 2 Dialekt.

01:42:42.140 --> 01:42:43.740
Und wir könnten uns jetzt hinsetzen und

01:42:43.740 --> 01:42:45.620
einfach so, um jetzt mal eine Schätzung

01:42:45.620 --> 01:42:47.460
abzugeben, zwei

01:42:47.460 --> 01:42:49.560
Person-Years reinstecken, das nach

01:42:49.560 --> 01:42:50.540
Python 3 zu portieren.

01:42:51.420 --> 01:42:53.440
Aber das wäre halt wirklich, ich denke,

01:42:53.560 --> 01:42:55.480
wirklich zwei Jahre Arbeit. Und danach

01:42:55.480 --> 01:42:57.560
hätten wir einfach kein einziges neues Feature.

01:42:58.540 --> 01:42:59.520
Das heißt, da hat

01:42:59.520 --> 01:43:01.420
halt einfach niemand so wirklich Lust drauf.

01:43:02.680 --> 01:43:03.680
Und das ist natürlich,

01:43:04.180 --> 01:43:05.560
wir sind da natürlich so ein bisschen in so einer,

01:43:05.880 --> 01:43:07.480
also Falle wäre jetzt viel gesagt, aber

01:43:07.480 --> 01:43:09.440
ein bisschen

01:43:09.440 --> 01:43:10.800
in so einer blöden Situation.

01:43:11.200 --> 01:43:12.820
Weil das ist halt nix,

01:43:14.140 --> 01:43:14.940
wofür momentan

01:43:14.940 --> 01:43:16.660
sind das halt wirklich eher so Open-Source

01:43:16.660 --> 01:43:18.780
Modell. Da ist jetzt keiner,

01:43:19.780 --> 01:43:20.900
der dafür wirklich

01:43:20.900 --> 01:43:22.480
jetzt bezahlt wird, sag ich mal.

01:43:23.120 --> 01:43:25.200
Und jetzt so eine Portierungs

01:43:25.200 --> 01:43:27.180
Aktion zu starten,

01:43:28.360 --> 01:43:28.760
ist halt

01:43:28.760 --> 01:43:29.660
einfach nur so,

01:43:30.940 --> 01:43:32.580
also mir würde das halt nicht so viel Spaß machen.

01:43:32.580 --> 01:43:33.100
Ja, klar.

01:43:34.100 --> 01:43:36.740
Aber das ist natürlich trotzdem in gewisser Weise auch kein Zustand.

01:43:36.980 --> 01:43:37.600
Also weil irgendwie,

01:43:39.520 --> 01:43:39.900
also

01:43:39.900 --> 01:43:43.660
man will halt auch

01:43:43.660 --> 01:43:45.860
letztlich dann irgendwie auch nicht komplett abgehängt

01:43:45.860 --> 01:43:47.400
werden. Also ich meine,

01:43:47.600 --> 01:43:49.780
das wird dann wahrscheinlich irgendwann auch ein Problem,

01:43:50.120 --> 01:43:51.260
da neue Leute

01:43:51.260 --> 01:43:53.660
ranzuführen, weil man denen dann ja irgendwie

01:43:53.660 --> 01:43:54.880
ein 2 beibringen muss.

01:43:55.380 --> 01:43:56.920
Das hattest du jetzt schon vergessen.

01:43:57.660 --> 01:43:59.960
Aber das Print hat keine Klappern.

01:44:00.200 --> 01:44:00.480
So genau.

01:44:02.160 --> 01:44:03.800
Ich meine, das andere, so ein bisschen

01:44:03.800 --> 01:44:05.680
doofe Problem ist halt, dass

01:44:05.680 --> 01:44:07.940
so ein Interpreter,

01:44:08.060 --> 01:44:09.800
der benutzt halt an keiner Stelle Unicode.

01:44:09.900 --> 01:44:12.760
das heißt so halt eines der Hauptargumente

01:44:12.760 --> 01:44:14.560
warum, wo Python 3 halt ein paar Sachen

01:44:14.560 --> 01:44:16.520
so richtig schön gemacht hat, die fallen

01:44:16.520 --> 01:44:18.600
weg, weil wir halt einfach immer nur Byte-Strings

01:44:18.600 --> 01:44:20.320
benutzen und

01:44:20.320 --> 01:44:22.480
deswegen

01:44:22.480 --> 01:44:24.460
das wäre halt, das ist halt quasi auch nochmal

01:44:24.460 --> 01:44:25.360
so ein Grund, warum

01:44:25.360 --> 01:44:28.600
Python 3 jetzt halt

01:44:28.600 --> 01:44:30.400
auch letztlich jetzt

01:44:30.400 --> 01:44:32.480
nicht so wirklich so eine Verbesserung ist, sondern halt

01:44:32.480 --> 01:44:34.560
wir würden das wirklich machen

01:44:34.560 --> 01:44:36.520
um halt nicht abgehängt zu werden, aber nicht weil wir

01:44:36.520 --> 01:44:38.480
weil wir jetzt

01:44:38.480 --> 01:44:40.420
wirklich von den Python 3 Features

01:44:40.420 --> 01:44:41.880
so mega motiviert werden.

01:44:42.060 --> 01:44:43.400
Und das ist halt so ein bisschen doof.

01:44:45.020 --> 01:44:46.460
Würde denn irgendwie diese

01:44:46.460 --> 01:44:48.480
keine Ahnung, TypePins oder andere Features

01:44:48.480 --> 01:44:50.220
von Python 3

01:44:50.220 --> 01:44:51.460
jetzt für die

01:44:51.460 --> 01:44:54.440
Annotation von dem Compiler irgendwas bringen?

01:44:55.620 --> 01:44:56.320
Nicht so richtig.

01:44:56.520 --> 01:44:58.440
Also man könnte ja sich, klar, man kann dann so ein paar

01:44:58.440 --> 01:45:00.220
der APIs vielleicht ein bisschen schöner machen.

01:45:00.700 --> 01:45:02.360
Aber wir haben jetzt halt Dekoratoren und die sind jetzt

01:45:02.360 --> 01:45:03.720
auch nicht so schrecklich. Ich meine,

01:45:05.300 --> 01:45:06.080
ob du jetzt halt

01:45:06.080 --> 01:45:07.640
das dann mit Doppelpunkt

01:45:07.640 --> 01:45:10.060
direkt hinter die Argumente schreiben kannst

01:45:10.060 --> 01:45:11.860
oder in der Zeile drüber mit dem Dekorator,

01:45:11.940 --> 01:45:13.280
den wir uns selber ausgedacht haben.

01:45:14.800 --> 01:45:16.000
Ja, das wäre schon ein bisschen

01:45:16.000 --> 01:45:17.400
netter, aber das wäre jetzt nicht

01:45:17.400 --> 01:45:20.080
also das wäre jetzt halt für mich

01:45:20.080 --> 01:45:22.140
nicht so eine ganz ausreichende Motivation,

01:45:22.260 --> 01:45:24.020
um halt irgendwie so ein riesen

01:45:24.020 --> 01:45:25.260
Refactoring-Projekt zu starten.

01:45:26.140 --> 01:45:27.940
Ich denke halt so ein

01:45:27.940 --> 01:45:29.180
also

01:45:29.180 --> 01:45:32.040
das wird halt stattfinden,

01:45:32.200 --> 01:45:34.040
wenn wir irgendjemand

01:45:34.040 --> 01:45:35.940
finden, der da mega Bock drauf hat oder

01:45:35.940 --> 01:45:36.760
wenn wir halt Geld finden.

01:45:37.640 --> 01:45:39.980
Und ich glaube, wenn beides nicht stattfindet,

01:45:40.100 --> 01:45:40.360
dann

01:45:40.360 --> 01:45:43.860
vielleicht bin ich

01:45:43.860 --> 01:45:45.600
da zu pessimistisch, aber dann sehe ich das

01:45:45.600 --> 01:45:46.260
im Moment halt nicht.

01:45:47.400 --> 01:45:48.180
Ja gut, klar.

01:45:49.600 --> 01:45:51.820
Also ich persönlich,

01:45:51.880 --> 01:45:53.240
ich kann nur über mich sprechen, ich persönlich

01:45:53.240 --> 01:45:54.780
hätte da halt keinen Spaß dran.

01:45:56.520 --> 01:45:57.420
Ja, aber ich meine,

01:45:57.560 --> 01:45:59.580
ist es dann, wenn man tatsächlich keinen Unicode hat,

01:45:59.580 --> 01:46:00.320
sondern nur ByteStrings?

01:46:01.260 --> 01:46:03.520
Ich meine, es gibt ja da so automatische

01:46:03.520 --> 01:46:05.820
Geschichten. Könnte man das nicht eventuell auch automatisch

01:46:05.820 --> 01:46:06.320
irgendwie?

01:46:06.980 --> 01:46:09.580
Und man da halt einfach

01:46:09.580 --> 01:46:11.500
einmal so zwei, two to three

01:46:11.500 --> 01:46:12.100
draufschmeißt.

01:46:15.020 --> 01:46:15.740
Irgendwann müssen wir

01:46:15.740 --> 01:46:17.620
das mal gucken und wir haben noch nicht so ganz

01:46:17.620 --> 01:46:19.500
wir haben noch nicht so ganz den

01:46:19.500 --> 01:46:21.420
pragmatischen Weg gefunden,

01:46:21.600 --> 01:46:22.540
den man halt gehen kann.

01:46:23.040 --> 01:46:25.360
Weil es ist halt auch so die Frage, macht man dann einmal

01:46:25.360 --> 01:46:27.360
einen Cut und sagt, Leute,

01:46:27.560 --> 01:46:29.400
halt, niemand macht mir

01:46:29.400 --> 01:46:30.780
neue Features für sechs Monate.

01:46:31.520 --> 01:46:32.620
Das ist halt auch doof.

01:46:32.620 --> 01:46:32.940
Also,

01:46:33.460 --> 01:46:36.600
ja, aber wir sind ja auch nicht

01:46:36.600 --> 01:46:38.600
die einzigen. Also es gibt ja auch wirklich

01:46:38.600 --> 01:46:40.380
leider noch ganz viele Firmen, die

01:46:40.380 --> 01:46:42.640
große Mengen

01:46:42.640 --> 01:46:43.540
an Python 2 gut haben.

01:46:45.120 --> 01:46:46.360
Aber ja, es ist halt,

01:46:46.840 --> 01:46:48.560
also man will das jetzt halt keine 10 Jahre so

01:46:48.560 --> 01:46:48.940
weitermachen.

01:46:51.160 --> 01:46:52.460
Aber so den idealen Weg,

01:46:52.520 --> 01:46:53.960
wie wir da jetzt wieder rauskommen aus der Geschichte,

01:46:53.960 --> 01:46:55.840
den wissen wir halt

01:46:55.840 --> 01:46:57.920
im Moment halt auch nicht. Außer wir finden jetzt jemanden, der

01:46:57.920 --> 01:46:59.940
sagt, hier habt

01:46:59.940 --> 01:47:01.480
ihr eine Million Dollar und

01:47:01.480 --> 01:47:03.480
macht doch bitte mal. Dann

01:47:03.480 --> 01:47:05.800
ist sowas halt auch wieder. Also ihr könnt hier schreien.

01:47:06.600 --> 01:47:12.720
Ja, also das ist,

01:47:13.200 --> 01:47:14.940
bei Django-Projekten gibt es sowas ähnliches

01:47:14.940 --> 01:47:15.680
mit dem Admin,

01:47:17.380 --> 01:47:20.160
mit dem Django-Admin,

01:47:20.440 --> 01:47:21.360
das ist halt auch so ein Ding,

01:47:21.480 --> 01:47:23.700
das ist über Django-Projekte auch halt 15 Jahre,

01:47:23.900 --> 01:47:25.240
das ist halt über die Zeit gewachsen.

01:47:25.800 --> 01:47:27.520
Teilweise ist da halt auch Geld reingesteckt worden,

01:47:27.600 --> 01:47:29.480
das zu entwickeln und inzwischen ist es halt auch so,

01:47:29.780 --> 01:47:31.180
die Schätzung ist ähnlich,

01:47:31.640 --> 01:47:32.840
etwa Leute, die sich damit auskennen,

01:47:32.840 --> 01:47:35.200
sagen halt so, ja, das jetzt mal so richtig neu zu schreiben

01:47:35.200 --> 01:47:37.220
und natürlich, wir wissen inzwischen, was wir alles gerne

01:47:37.220 --> 01:47:39.360
lieber machen würden, würde wahrscheinlich so eine Million

01:47:39.360 --> 01:47:41.200
kosten und tja, die haben wir halt nicht.

01:47:41.720 --> 01:47:43.240
Naja, so ist es halt ein bisschen auch.

01:47:43.440 --> 01:47:45.080
Und ich meine, das sieht man ja auch wirklich

01:47:45.080 --> 01:47:47.500
ganz konkret bei C-Python. Also C-Python

01:47:47.500 --> 01:47:49.420
3.11 und 3.10 sind

01:47:49.420 --> 01:47:51.160
halt einfach auch

01:47:51.160 --> 01:47:53.320
wirklich viel schneller geworden und

01:47:53.320 --> 01:47:54.620
das ist halt einfach eine Geldfrage.

01:47:55.080 --> 01:47:57.480
Also wenn du halt plötzlich fünf Leute hast, die einfach

01:47:57.480 --> 01:47:58.560
fulltime

01:47:58.560 --> 01:48:01.240
bezahlt werden und das sind ja auch jetzt nicht

01:48:01.240 --> 01:48:03.320
irgendwelche Leute, sondern halt auch gute Leute,

01:48:03.800 --> 01:48:04.920
dann passiert halt auch was.

01:48:05.200 --> 01:48:26.520
Und wir können halt quasi so ein bisschen durch schlaue Architektur, die wir vor zehn Jahren halt quasi geschrieben haben, dadurch können wir halt irgendwie ziemlich gut mithalten, weil der DIT-Generator halt da ist und gut funktioniert.

01:48:29.220 --> 01:48:30.500
Aber halt alles, was

01:48:30.500 --> 01:48:32.280
jetzt mal so irgendwie so

01:48:32.280 --> 01:48:34.420
in Anführungszeichen, also Bonus-Values ist schon

01:48:34.420 --> 01:48:36.380
zu negativ, aber alles, was jetzt halt irgendwie

01:48:36.380 --> 01:48:38.360
so eine ganz tiefgreifende Veränderung

01:48:38.360 --> 01:48:40.560
bräuchte,

01:48:41.060 --> 01:48:42.160
das kriegen wir halt

01:48:42.160 --> 01:48:44.040
mit dem jetzigen Funding-Stand

01:48:44.040 --> 01:48:46.020
nicht hin.

01:48:46.660 --> 01:48:48.140
Weil das kriegst du halt nicht durch,

01:48:48.960 --> 01:48:50.340
also wir haben halt auch schon so ein

01:48:50.340 --> 01:48:51.840
Open Collective-Dings und wir kriegen auch

01:48:51.840 --> 01:48:54.440
Donations und da, wir sind da auch

01:48:54.440 --> 01:48:56.400
super dankbar dafür, da kommt auf jeden Fall auch

01:48:56.400 --> 01:48:57.660
irgendwie immer wieder

01:48:57.660 --> 01:48:59.520
gut was

01:48:59.520 --> 01:49:01.560
zusammen, aber es ist halt was anderes, wenn du

01:49:01.560 --> 01:49:02.760
plötzlich fünf Leute anstellen kannst.

01:49:03.220 --> 01:49:04.120
Und da sind wir halt nicht.

01:49:05.940 --> 01:49:07.560
Und da haben wir halt auch gerade nicht so

01:49:07.560 --> 01:49:09.080
richtig die Person, die da

01:49:09.080 --> 01:49:10.180
hinterher wäre,

01:49:10.460 --> 01:49:13.620
diese Gelder dann auch zu suchen.

01:49:13.620 --> 01:49:14.000
Also

01:49:14.000 --> 01:49:17.600
hatten wir ja vorhin schon kurz drüber geredet,

01:49:17.640 --> 01:49:19.440
wir hatten halt irgendwie zweimal so

01:49:19.440 --> 01:49:21.840
wirklich große Forschungsförderungsprojekte,

01:49:22.040 --> 01:49:23.840
also beides mal EU-finanziert.

01:49:24.540 --> 01:49:25.660
Das eine war von 2004

01:49:25.660 --> 01:49:27.460
bis 2006.

01:49:27.660 --> 01:49:29.760
das andere von 2008

01:49:29.760 --> 01:49:31.120
bis 2010 so ungefähr

01:49:31.120 --> 01:49:33.540
und da hatten wir halt dann

01:49:33.540 --> 01:49:35.600
wirklich einige Vollzeitleute, die da

01:49:35.600 --> 01:49:37.440
einfach wirklich dann über diese Zeiträume halt auch

01:49:37.440 --> 01:49:39.480
wirklich immer nur an diesem ganzen Zeug

01:49:39.480 --> 01:49:41.500
gearbeitet haben und da

01:49:41.500 --> 01:49:43.620
kam halt dann auch wirklich was raus

01:49:43.620 --> 01:49:43.940
so

01:49:43.940 --> 01:49:47.960
und dann danach hatten wir halt viel so

01:49:47.960 --> 01:49:51.400
immer wieder Funding auch von Firmen, die halt

01:49:51.400 --> 01:49:52.900
dann bestimmte Features gerne haben wollten

01:49:52.900 --> 01:49:54.300
aber

01:49:54.300 --> 01:49:57.280
seit

01:49:57.280 --> 01:50:00.060
einer Weile gibt es halt niemand,

01:50:00.380 --> 01:50:02.300
der jetzt Bock auf, es ist halt

01:50:02.300 --> 01:50:03.660
nochmal so ein ganz eigener Task,

01:50:03.880 --> 01:50:05.280
für Open-Source Geld zu finden.

01:50:06.160 --> 01:50:08.160
Und man braucht halt da so ein bisschen

01:50:08.160 --> 01:50:08.980
ganz

01:50:08.980 --> 01:50:11.160
eigene Skills auch.

01:50:11.720 --> 01:50:14.000
Und so eine Person haben wir jetzt nicht mehr.

01:50:14.700 --> 01:50:16.200
Und das ist in gewisser

01:50:16.200 --> 01:50:17.680
Weise nicht so ein

01:50:17.680 --> 01:50:18.780
perfekter Zustand.

01:50:19.960 --> 01:50:21.260
Ja, und ich meine, selbst für

01:50:21.260 --> 01:50:24.080
Projekte, die halt sehr viel

01:50:24.080 --> 01:50:26.040
genutzt werden, also sowas wie Pandas, mich wundert das immer,

01:50:26.160 --> 01:50:27.820
es gibt ja diverse, es gibt ja ganz viele,

01:50:28.400 --> 01:50:29.720
wo die Basis für

01:50:29.720 --> 01:50:32.600
die Menge...

01:50:32.600 --> 01:50:34.480
Genau, das ist die Basis

01:50:34.480 --> 01:50:36.380
für Milliardenumsätze irgendwie

01:50:36.380 --> 01:50:37.880
in der Industrie, aber trotzdem

01:50:37.880 --> 01:50:40.380
gibt es da eigentlich für die

01:50:40.380 --> 01:50:41.620
Entwicklung nicht so richtig viel Geld.

01:50:42.640 --> 01:50:43.340
Also der andere

01:50:43.340 --> 01:50:46.580
momentan sehr aktive PiPi-Entwickler

01:50:46.580 --> 01:50:48.400
der Matipikus, der ist

01:50:48.400 --> 01:50:49.280
tatsächlich bei

01:50:49.280 --> 01:50:52.600
einer Firma angestellt, die darauf spezialisiert

01:50:52.600 --> 01:50:53.260
ist, halt

01:50:53.260 --> 01:50:55.980
NumPy voranzubringen

01:50:55.980 --> 01:50:56.840
und halt dann da

01:50:56.840 --> 01:50:59.840
einer der Leute, die halt wirklich auch

01:50:59.840 --> 01:51:01.020
quasi finanziert

01:51:01.020 --> 01:51:03.560
NumPy-Bugs fix,

01:51:03.640 --> 01:51:05.700
das ist auch Teil, heißt das auch Steering Council

01:51:05.700 --> 01:51:06.840
bei NumPy, weißt du das zufällig?

01:51:07.220 --> 01:51:09.220
Nee, keine Ahnung. Also der ist auch quasi Teil

01:51:09.220 --> 01:51:11.060
des Komitees, das halt NumPy

01:51:11.060 --> 01:51:13.600
verwaltet und ist da

01:51:13.600 --> 01:51:15.420
sehr aktiv. Deswegen geht NumPy auch

01:51:15.420 --> 01:51:17.520
gut auf PyPy, weil er sich halt da drauf auch kümmert.

01:51:17.900 --> 01:51:18.080
Achso.

01:51:18.540 --> 01:51:22.020
Ja, also

01:51:22.020 --> 01:51:40.540
Also bei NumPy passiert es langsam eben schon. Also sowas wie Jupiter hat halt auch Funding und da gibt es halt inzwischen in den USA schon auch halt Firmen und Foundations, die halt erkannt haben, dass es einfach so ein wichtiges Stück Infrastruktur ist, dass es halt vielleicht doch auch eine gute Idee ist.

01:51:40.540 --> 01:51:42.480
Wenn du das ganze Internet an so einem kleinen Faden aufhängst.

01:51:42.480 --> 01:51:59.640
Ja, ich habe gehört, also die Idee fand ich auch ganz charmant, dass man sagt, ja, also eigentlich müsste man das Firmen so verkaufen, dass es halt eine Versicherung ist, wenn sie da nichts, also sie zahlen sozusagen eine Art Versicherungspolizei dafür, dass es das halt auch in Zukunft gibt, weil wenn es das nicht mehr geben sollte, haben sie ein großes Problem.

01:51:59.980 --> 01:52:14.660
Ich weiß nicht, was da die Antwort ist. Ich finde halt auch letztlich, in gewisser Weise ist das wirklich auch was, was man über Steuern machen könnte. Und passiert ja ein Stück weit auch. Also halt sowas wie, ich glaube es ist ja.

01:52:14.660 --> 01:52:15.920
Man muss halt Projektanträge schreiben, ne?

01:52:16.400 --> 01:52:17.920
Müsste man halt Projektanträge schreiben, ja.

01:52:18.340 --> 01:52:19.880
Und da ist es halt dann so ein bisschen so,

01:52:20.140 --> 01:52:22.200
da ist halt PyPy dann letztlich

01:52:22.200 --> 01:52:23.820
auch vielleicht nicht wichtig genug, ne?

01:52:24.480 --> 01:52:26.240
Also bei PyPy kann man halt nicht sagen,

01:52:26.360 --> 01:52:28.160
das ist jetzt eine absolut die

01:52:28.160 --> 01:52:30.300
grundlegende Technologie wie

01:52:30.300 --> 01:52:31.340
NumPy, weil

01:52:31.340 --> 01:52:34.200
so viele Leute

01:52:34.200 --> 01:52:35.680
benutzen es halt dann irgendwie doch nicht.

01:52:36.180 --> 01:52:38.180
Und klar, wir finden halt auch

01:52:38.180 --> 01:52:40.320
immer ganz tolle Bugs in CPython und ich glaube

01:52:40.320 --> 01:52:42.140
schon, dass jetzt unser Wert

01:52:42.140 --> 01:52:43.920
halt jetzt auch, selbst wenn man das nicht

01:52:43.920 --> 01:52:46.020
einsetze, es ist halt nicht null, da haben wir

01:52:46.020 --> 01:52:47.300
vorhin über ein paar Beispiele geredet,

01:52:48.000 --> 01:52:49.820
aber es ist halt auch nicht klar,

01:52:49.980 --> 01:52:51.260
ob wir jetzt das Projekt sind,

01:52:52.060 --> 01:52:53.680
für das irgendjemand

01:52:53.680 --> 01:52:55.940
ein paar Vollzeitentwickler dann bezahlen sollte.

01:52:56.220 --> 01:52:57.600
Also ich meine, klar, wir könnten die,

01:52:58.260 --> 01:52:59.980
wenn wir die hätten, dann könnten wir ganz, ganz tolle Sachen

01:52:59.980 --> 01:53:01.500
machen. Auf jeden Fall, ich habe

01:53:01.500 --> 01:53:03.940
eine ganz lange Liste, also

01:53:03.940 --> 01:53:05.920
schickt das

01:53:05.920 --> 01:53:07.200
Geld gerne zu mir, aber

01:53:07.200 --> 01:53:10.020
wenn man dann so einen Antrag schreibt,

01:53:10.100 --> 01:53:11.900
ist mir halt nicht so klar, ob man sagen kann, wir sind so

01:53:11.900 --> 01:53:13.740
wichtig wie, was weiß ich,

01:53:13.840 --> 01:53:15.800
OpenSSL sind wir halt nicht. Offensichtlich

01:53:15.800 --> 01:53:17.820
nicht. Und ja.

01:53:18.280 --> 01:53:19.660
Aber das viel grundlegende Problem ist halt,

01:53:19.880 --> 01:53:21.520
wir haben im Moment keinen, der da Lust drauf hat.

01:53:22.000 --> 01:53:23.860
Oder in dessen

01:53:23.860 --> 01:53:25.860
Expertise das halt liegt. Und das

01:53:25.860 --> 01:53:27.900
ist nicht so gut.

01:53:27.900 --> 01:53:29.840
Und es kann schon sein, dass ich da auch vielleicht

01:53:29.840 --> 01:53:31.920
irgendwann dann auch nochmal drin besser werden muss.

01:53:32.360 --> 01:53:33.900
Aber wenn ihr Lust drauf habt, dann

01:53:33.900 --> 01:53:34.620
sagt Bescheid.

01:53:36.140 --> 01:53:37.660
Wir nehmen gerne

01:53:37.660 --> 01:53:39.840
Freiwillige an. Also ich finde es zum Beispiel

01:53:39.840 --> 01:53:41.820
Read the Rocks finde ich auch einen sehr interessanten Fall.

01:53:42.860 --> 01:53:43.260
Weil

01:53:43.260 --> 01:53:45.520
das ja auch letztlich

01:53:45.520 --> 01:53:46.100
halt

01:53:46.100 --> 01:53:49.580
einen sehr guten

01:53:49.580 --> 01:53:51.240
Weg gefunden hat für ein

01:53:51.240 --> 01:53:53.740
für die Community ultra

01:53:53.740 --> 01:53:55.680
wichtiges Problem, nämlich wo wird

01:53:55.680 --> 01:53:56.820
eigentlich die Dokumentation gehostet

01:53:56.820 --> 01:53:59.480
und wer bezahlt dafür, halt eine Lösung zu finden.

01:54:00.120 --> 01:54:01.060
Und die Lösung ist halt,

01:54:01.280 --> 01:54:03.220
wir finanzieren das einmal durch

01:54:03.220 --> 01:54:05.600
akzeptable Werbung und eben durch

01:54:05.600 --> 01:54:07.680
Firmen, die dann damit selber ihre Dokumentation

01:54:07.680 --> 01:54:09.340
hosten. Und da gibt es auch coole

01:54:09.340 --> 01:54:11.500
Podcasts, ich muss mal gucken, ob mir die

01:54:11.500 --> 01:54:13.100
Folge einfällt, wo der

01:54:13.100 --> 01:54:14.760
Read-the-Docs-Gründer halt auch

01:54:14.760 --> 01:54:16.820
so ein bisschen über seine Philosophie von

01:54:16.820 --> 01:54:17.960
Open-Software-Funding redet.

01:54:19.080 --> 01:54:20.980
Und ja, ich finde das

01:54:20.980 --> 01:54:22.700
auch einen ganz

01:54:22.700 --> 01:54:24.780
coolen Weg eigentlich. Also weil

01:54:24.780 --> 01:54:26.720
die haben ja wirklich jetzt auch

01:54:26.720 --> 01:54:28.860
einige Entwickler, die halt da

01:54:28.860 --> 01:54:29.820
an der Infrastruktur arbeiten,

01:54:30.480 --> 01:54:31.780
die Sphinx voranbringen,

01:54:32.040 --> 01:54:34.480
die Docutales-Patches

01:54:34.480 --> 01:54:36.020
schicken und

01:54:36.020 --> 01:54:37.600
da ist ja wirklich, also

01:54:37.600 --> 01:54:40.160
da sind wir ja, da ist die Python-Community ja auch

01:54:40.160 --> 01:54:41.200
wirklich ziemlich gut aufgestellt.

01:54:42.740 --> 01:54:44.320
Ich finde es auch sehr interessant,

01:54:44.420 --> 01:54:46.300
es gibt wirklich auch an einigen Stellen

01:54:46.300 --> 01:54:48.160
halt dann Projekte in ganz

01:54:48.160 --> 01:54:50.260
anderen Sprachen, die halt dann trotzdem

01:54:50.260 --> 01:54:52.040
Read the Docs nehmen, weil es halt einfach wirklich

01:54:52.040 --> 01:54:52.820
auch cool ist.

01:54:54.440 --> 01:54:56.300
Wie heißt das, ist das Eric Holscher?

01:54:56.500 --> 01:54:57.980
Ja. Genau, ich glaube,

01:54:58.040 --> 01:55:00.180
da gab es ein Django-Chat-Episode, die gar nicht so

01:55:00.180 --> 01:55:02.020
sagen, er ist vor ein paar Monaten zu Gast war

01:55:02.020 --> 01:55:04.180
und da hat er da einiges. Ich packe die auch mal

01:55:04.180 --> 01:55:05.420
in die Schotter und zwar nichts, wenn ich mich daran erinnere.

01:55:06.060 --> 01:55:06.180
Ja.

01:55:07.680 --> 01:55:10.180
Und ja, das ist ein großartiges Beispiel.

01:55:11.620 --> 01:55:12.180
Naja und

01:55:12.180 --> 01:55:13.700
ansonsten ist es halt so,

01:55:14.520 --> 01:55:15.780
ich habe jetzt halt, also

01:55:15.780 --> 01:55:18.100
wir haben halt in gewisser Weise einen ganz guten Vorteil,

01:55:18.180 --> 01:55:20.260
weil ich kann das halt als Teil

01:55:20.260 --> 01:55:22.180
meiner Arbeit machen. Ich bin an der Uni

01:55:22.180 --> 01:55:24.220
angestellt, ich bin

01:55:24.220 --> 01:55:26.120
für die Lehre bezahlt, aber wenn die Lehre

01:55:26.120 --> 01:55:27.920
zu Ende ist, dann darf ich quasi

01:55:27.920 --> 01:55:28.820
forschen, was ich will.

01:55:30.180 --> 01:55:48.520
Ich bin in eine Forschungsgruppe eingebettet, die zumindest irgendwie was mit Compilern zu tun auch hat. Insofern bin ich da jetzt auch nicht, bin da so ein bisschen der Einzige, der ganz konkret was mit Compilern macht im Moment, aber ich bin da jetzt quasi thematisch auch nicht fehl am Platz und mein Chef freut sich da auch, wenn ich da dann was dann mache.

01:55:49.080 --> 01:56:09.280
Insofern passieren halt durch das Level, was durch meine halbe Stelle, das ist jetzt nicht, sind jetzt nicht ultra viele Stunden, aber halt zumindest schon so ein paar Stunden, die sind halt da und die werden halt auch, solange aus meiner Ansicht nach da halt es interessante Forschungsfragen gibt, werden die halt auch für das Projekt auch weiter verwendet werden.

01:56:10.200 --> 01:56:15.000
Und das ist halt so ein Basislevel, naja, das muss man halt auch erstmal haben.

01:56:15.000 --> 01:56:31.320
Ja, aber das reicht halt nicht, um jetzt irgendwie so eine ganz krasse neue Idee für eine neue DIT-Optimierung sich auszudenken.

01:56:31.880 --> 01:56:35.540
Also manchmal läuft es dann über Abschlussarbeiten ganz gut.

01:56:35.660 --> 01:56:40.620
Also ich hatte gerade eine unglaublich coole Bachelorarbeit betreut, das ist jetzt noch nicht gemerged,

01:56:40.620 --> 01:56:44.440
Aber der hat echt eine sehr interessante neue Optimierung

01:56:44.440 --> 01:56:45.660
für den JIT-Compiler auch geschrieben,

01:56:45.800 --> 01:56:48.740
die auch gerade bei Programmen, die viel mit Integern machen,

01:56:48.920 --> 01:56:51.580
wirklich nochmal ganz anders Sachen optimieren kann.

01:56:53.280 --> 01:56:54.920
Also echt ein super Student.

01:56:56.480 --> 01:56:58.040
Nico Rittinghaus heißt der.

01:56:59.340 --> 01:57:02.140
Der hat dann auch so die Originalliteratur aus den 70ern gelesen

01:57:02.140 --> 01:57:03.740
und meinte so, hier in diesem Paper,

01:57:04.300 --> 01:57:07.740
was mit Schreibmaschine geschrieben wurde, steht das hier drin.

01:57:07.740 --> 01:57:10.120
In eurem Code ist das doch ganz anders,

01:57:10.240 --> 01:57:11.340
sag doch mal.

01:57:13.200 --> 01:57:14.160
Genau so, ja.

01:57:16.420 --> 01:57:16.820
Und

01:57:16.820 --> 01:57:18.340
er hat dann dabei halt

01:57:18.340 --> 01:57:20.220
auch immer recht, also das war

01:57:20.220 --> 01:57:22.780
sehr, sehr cool mit dem.

01:57:22.860 --> 01:57:24.340
Ich hoffe auch, dass er quasi weitermacht

01:57:24.340 --> 01:57:26.780
und vielleicht irgendwie auch noch

01:57:26.780 --> 01:57:28.580
eine Masterarbeit schreibt, aber

01:57:28.580 --> 01:57:30.540
manchmal passieren halt dann so Sachen, aber

01:57:30.540 --> 01:57:32.860
bei so Abschlussarbeiten

01:57:32.860 --> 01:57:34.560
ist das halt schon so, dass die Leute halt dann

01:57:34.560 --> 01:57:36.520
tendenziell auch wieder weg sind. Ja, und dann muss man das

01:57:36.520 --> 01:57:38.500
mal entdecken. Nee, das ist eigentlich okay.

01:57:39.800 --> 01:57:42.100
Ja stimmt, wir schreiben ja dann auch

01:57:42.100 --> 01:57:43.880
Wir schreiben halt Tests

01:57:43.880 --> 01:57:44.920
und ich bin halt dann schon

01:57:44.920 --> 01:57:48.060
ich gehe dann schon auf die Nerven, dass sie jetzt halt auch keinen Scheiß schreiben

01:57:48.060 --> 01:57:49.460
also so qualitätsmäßig

01:57:49.460 --> 01:57:53.980
Ja, also wir stecken schon auch

01:57:53.980 --> 01:57:55.260
ich meine

01:57:55.260 --> 01:57:57.020
Wir machen ein bisschen Review und Kultur

01:57:57.020 --> 01:57:59.680
Review und Kultur und wir wollen halt schon

01:57:59.680 --> 01:58:01.940
wir sind halt jetzt nicht so ein normales

01:58:01.940 --> 01:58:03.120
Forschungsprojekt, was halt eigentlich

01:58:03.120 --> 01:58:05.820
Code zum Weg, also viele Forschungsprojekte sind halt so

01:58:05.820 --> 01:58:07.740
Code zum Wegschmeißen. Man schreibt Code

01:58:07.740 --> 01:58:08.900
man schreibt ein Paper und dann ist man

01:58:08.900 --> 01:58:11.620
mit dem Thema durch, sondern wir sind

01:58:11.620 --> 01:58:13.600
halt so ein bisschen, in gewisser Weise

01:58:13.600 --> 01:58:15.600
so ein bisschen ein schlechtes Forschungsprojekt in dem Sinne,

01:58:15.720 --> 01:58:17.720
dass wir halt versuchen, halt auch

01:58:17.720 --> 01:58:19.480
Code zu schreiben, den Leute benutzen können und

01:58:19.480 --> 01:58:21.640
deswegen haben wir halt Aufwand, der sich aus

01:58:21.640 --> 01:58:23.460
Forschungssicht halt irgendwie auch nicht lohnt.

01:58:24.400 --> 01:58:25.620
Deswegen bin ich halt

01:58:25.620 --> 01:58:27.440
vielleicht auch kein Professor, sondern

01:58:27.440 --> 01:58:29.560
weil mein Forschungsoutput halt auch

01:58:29.560 --> 01:58:31.060
nicht, also

01:58:31.060 --> 01:58:33.360
weil ich diesen Job auch gar nicht haben wollte,

01:58:33.500 --> 01:58:35.640
also das, aber weil

01:58:35.640 --> 01:58:37.800
halt so der Output an Pippen aufsetzen

01:58:37.800 --> 01:58:39.980
bei mir vielleicht halt nicht so ganz

01:58:39.980 --> 01:58:40.900
stimmt. Also

01:58:40.900 --> 01:58:44.000
ich schreibe schon Aufsätze und die sind halt zum Teil

01:58:44.000 --> 01:58:44.840
dann auch ganz gut

01:58:44.840 --> 01:58:47.220
rezipiert und werden zitiert und so, aber

01:58:47.220 --> 01:58:49.740
vielleicht jetzt nicht mit dem

01:58:49.740 --> 01:58:51.880
Nachdruck, den man bräuchte, wenn man jetzt halt

01:58:51.880 --> 01:58:53.120
so ein

01:58:53.120 --> 01:58:55.680
reiner Akademiker sein wollte.

01:58:57.340 --> 01:58:57.740
Naja.

01:58:58.380 --> 01:58:59.760
Ja, das ist auch

01:58:59.760 --> 01:59:01.800
eine faszinierende Geschichte. Ich meine, tatsächlich ist es

01:59:01.800 --> 01:59:03.920
ja dann doch oft so, dass dann Sachen wiederverwendet werden.

01:59:04.800 --> 01:59:05.780
Also wenn man

01:59:05.780 --> 01:59:07.640
und dann, also in der Physik

01:59:07.640 --> 01:59:10.180
manche Leute kommen, sieht man das dann häufig,

01:59:10.320 --> 01:59:11.620
dass dann doch irgendwie so

01:59:11.620 --> 01:59:13.880
sich Sachen aufeinandertürmen, die halt

01:59:13.880 --> 01:59:16.040
irgendwie man vielleicht dann doch mal, wenn man gewusst hätte,

01:59:16.400 --> 01:59:17.820
wo man hinterher rauskommt,

01:59:18.180 --> 01:59:18.980
hätte man das auch mal,

01:59:19.100 --> 01:59:21.640
hätte man das vielleicht anders bauen können.

01:59:22.680 --> 01:59:24.540
Das ist meine absolute Lieblingsgeschichte,

01:59:24.620 --> 01:59:25.540
die werde ich jetzt hier noch anbringen.

01:59:25.820 --> 01:59:27.400
Oh ja, sehr gerne. Ich habe tatsächlich,

01:59:28.260 --> 01:59:29.380
also ursprünglich habe ich mal

01:59:29.380 --> 01:59:31.580
Mathe und Physik studiert und dann habe ich das abgebrochen,

01:59:31.740 --> 01:59:33.460
um an, um bei einem

01:59:33.460 --> 01:59:35.500
der PiPi-Firmen, die halt von

01:59:35.500 --> 01:59:36.460
der EU Geld gekriegt haben,

01:59:36.640 --> 01:59:38.680
mitzuarbeiten für eine Weile.

01:59:39.640 --> 01:59:41.180
Aber vorher habe ich quasi

01:59:41.180 --> 01:59:43.180
bei den Teilchenphysikern halt immer so

01:59:43.180 --> 01:59:44.860
Semesterferien,

01:59:45.160 --> 01:59:46.340
Hiwi-Jobs gehabt.

01:59:47.460 --> 01:59:49.220
Und die Teilchenphysiker, die haben

01:59:49.220 --> 01:59:50.860
so CERN und so, die haben halt

01:59:50.860 --> 01:59:53.360
ein ganz interessantes Stück Technologie,

01:59:53.900 --> 01:59:55.680
nämlich die haben einen C++-Interpreter.

01:59:57.120 --> 01:59:57.400
Ach,

01:59:57.560 --> 01:59:57.960
weil,

01:59:59.100 --> 02:00:01.060
dann muss man ja nur eine Sprache lernen.

02:00:02.680 --> 02:00:02.800
Also,

02:00:03.600 --> 02:00:05.200
wir müssen ja, die Physiker, die müssen ja

02:00:05.200 --> 02:00:07.020
eh zu C++ zu lernen, um halt schnell

02:00:07.020 --> 02:00:09.080
einen Code zu schreiben, aber die wollen ja auch Skripting

02:00:09.080 --> 02:00:10.980
machen. Und wenn wir jetzt halt so

02:00:10.980 --> 02:00:12.580
einen C++-Interpreter haben,

02:00:13.120 --> 02:00:14.960
dann können die ja mit der Sprache, die die eh

02:00:14.960 --> 02:00:17.020
schon können, halt auch ihre Skripte

02:00:17.020 --> 02:00:17.360
schreiben.

02:00:18.560 --> 02:00:20.300
Und das war halt so

02:00:20.300 --> 02:00:23.020
2003 rum, war das halt echt

02:00:23.020 --> 02:00:24.820
noch irgendwie so ein Stück Technologie,

02:00:24.920 --> 02:00:26.580
was die halt einfach wirklich benutzt haben

02:00:26.580 --> 02:00:28.760
in der Teilchenphysik.

02:00:29.560 --> 02:00:30.700
Und so nach und nach

02:00:30.700 --> 02:00:32.780
kam halt dann die Erkenntnis, dass das doch

02:00:32.780 --> 02:00:33.560
irgendwie vielleicht

02:00:33.560 --> 02:00:35.900
halt so ein bisschen

02:00:35.900 --> 02:00:37.240
so eine merkwürdige Idee ist.

02:00:38.000 --> 02:00:39.740
Und inzwischen nehmen die halt auch

02:00:39.740 --> 02:00:41.120
einfach Python für Skipping, ja.

02:00:42.220 --> 02:00:43.760
Aber das ist halt für mich immer so

02:00:43.760 --> 02:00:45.740
ein Beispiel, wenn man, also

02:00:45.740 --> 02:00:48.100
einer, so ein Lieblingsaufreger

02:00:48.100 --> 02:00:49.620
von mir ist, wenn Leute halt von

02:00:49.620 --> 02:00:51.700
interpretierten Sprachen reden. Man sagt halt gerne,

02:00:51.840 --> 02:00:53.100
Python ist eine interpretierte Sprache.

02:00:53.620 --> 02:00:55.740
Und das ist halt eigentlich eine Aussage, die meiner Ansicht nach

02:00:55.740 --> 02:00:57.240
semantisch keinen Sinn macht, also

02:00:57.240 --> 02:00:58.480
sinnleer, weil

02:00:58.480 --> 02:01:01.720
es ist halt eine Eigenschaft einer Implementierung,

02:01:01.820 --> 02:01:02.880
ob sie interpretiert ist oder nicht.

02:01:03.560 --> 02:01:18.640
Also C-Python ist ein Interpreter, das stimmt, und PyPy ist halt ein Dit-Compiler, das stimmt. Aber man kann jetzt eben nicht sagen, dass C++ eine kompilierte Sprache ist, weil es gibt ja Cint und das ist halt eine Implementierung von C++, die das interpretiert.

02:01:19.540 --> 02:01:35.700
Und deswegen kann man halt nur sagen, na gut, wenn man halt GCC benutzt, dann hat man eine kompilierte Implementierung von C++. Das ist quasi so ein Randfall, den ich dann gerne anbringe, um zu demonstrieren, dass es halt ein Konzept ist, das keinen Sinn macht, von einer kompilierten Sprache zu sprechen.

02:01:36.500 --> 02:01:39.300
Naja, also zum Glück ist das Ding inzwischen, glaube ich, tot.

02:01:43.220 --> 02:01:45.240
Ja, ne, interessant.

02:01:47.060 --> 02:01:47.180
Ja.

02:01:48.500 --> 02:01:49.420
Ja, ich weiß nicht,

02:01:50.040 --> 02:01:51.020
spielt eigentlich diese,

02:01:51.540 --> 02:01:53.660
da gab es ja auch so Geschichten mit

02:01:53.660 --> 02:01:56.080
Software Transactional Memory und so,

02:01:56.660 --> 02:01:57.840
spielt das noch eine Rolle?

02:01:58.020 --> 02:02:00.180
Also da gab es halt ein relativ langjähriges

02:02:00.180 --> 02:02:01.800
Forschungsprojekt, auch von dem Armin Rigo und

02:02:01.800 --> 02:02:03.720
einem Doktoranden, der

02:02:03.720 --> 02:02:06.140
in der ETH Zürich, glaube ich, promoviert hat.

02:02:06.880 --> 02:02:08.000
Und die hatten halt diese Idee,

02:02:08.000 --> 02:02:09.140
dass man halt irgendwie

02:02:09.140 --> 02:02:12.180
Software Transactional Memory benutzen

02:02:12.180 --> 02:02:13.620
können sollte, um

02:02:13.620 --> 02:02:16.080
den Overhead

02:02:16.080 --> 02:02:17.820
von einem

02:02:17.820 --> 02:02:19.920
Jill, also Global Interpreter

02:02:19.920 --> 02:02:21.340
Log-Free Multithreading

02:02:21.340 --> 02:02:23.600
für Python sehr klein zu halten.

02:02:25.120 --> 02:02:25.460
Und

02:02:25.460 --> 02:02:27.620
dieses Forschungsprojekt hat halt,

02:02:28.760 --> 02:02:29.780
also die haben da auch wirklich

02:02:29.780 --> 02:02:32.020
viele Jahre dran

02:02:32.020 --> 02:02:33.160
geforscht und rein

02:02:33.160 --> 02:02:35.960
Zeit investiert. Das hat halt

02:02:35.960 --> 02:02:37.720
am Schluss nicht so gut geklappt, wie sie sich

02:02:37.720 --> 02:02:39.480
erhofft hatten. Was ist das überhaupt?

02:02:39.660 --> 02:02:41.920
Vielleicht nochmal. Also ich bin

02:02:41.920 --> 02:02:42.860
da sehr schnell raus.

02:02:44.680 --> 02:02:50.000
Ich habe das halt immer so interessiert verfolgt

02:02:50.000 --> 02:02:51.760
und die hatten halt dann so einen Branch und haben da auch

02:02:51.760 --> 02:02:53.880
jahrelang auch wirklich

02:02:53.880 --> 02:02:55.520
sehr viel Aufwand reingesteckt.

02:02:56.360 --> 02:02:57.960
Aber am Schluss waren sie halt

02:02:57.960 --> 02:02:59.880
irgendwie mit den Ergebnissen nicht so

02:02:59.880 --> 02:03:01.320
zufrieden und halt auch

02:03:01.320 --> 02:03:04.060
also technische

02:03:04.060 --> 02:03:05.820
Details, wie gesagt, ist nicht so mein Ding.

02:03:07.040 --> 02:03:08.140
Was soll das denn theoretisch

02:03:08.140 --> 02:03:09.320
sein? Also ich habe gar nicht verstanden,

02:03:09.500 --> 02:03:11.920
gehen soll? Also die Idee

02:03:11.920 --> 02:03:13.840
von Source Transaction Memory ist, dass

02:03:13.840 --> 02:03:14.460
du quasi

02:03:14.460 --> 02:03:18.080
also du kannst

02:03:18.080 --> 02:03:19.540
halt dann mehrere Threads starten, die

02:03:19.540 --> 02:03:20.820
alle Python-Code ausführen

02:03:20.820 --> 02:03:23.760
und du machst so einen optimistischen

02:03:23.760 --> 02:03:25.460
Ansatz, so einen Datenbank-Ansatz.

02:03:26.160 --> 02:03:27.640
Jeder Thread hat eine

02:03:27.640 --> 02:03:29.840
eigene Transaktion und

02:03:29.840 --> 02:03:31.720
der Thread, der läuft

02:03:31.720 --> 02:03:33.280
so ein bisschen und dann versucht er zu committen.

02:03:33.800 --> 02:03:35.580
Committen heißt, dass seine

02:03:35.580 --> 02:03:37.540
Sicht der Welt, also seine Sicht

02:03:37.540 --> 02:03:38.960
des Zustands des Programms,

02:03:39.500 --> 02:03:44.200
mit der Sicht der Welt der anderen Threads

02:03:44.200 --> 02:03:45.780
irgendwie gemerged werden muss.

02:03:46.960 --> 02:03:48.080
Das ist die Transaction.

02:03:48.900 --> 02:03:51.100
Und das macht man aber nicht auf der Datenbank-Ebene,

02:03:51.260 --> 02:03:52.400
sondern wirklich auf der Sprachebene.

02:03:52.760 --> 02:03:55.020
Also das ist die Idee von Software Transaction Memory.

02:03:55.740 --> 02:03:57.300
Und da gibt es halt dann Techniken,

02:03:57.520 --> 02:04:00.500
um das effizient hinzukriegen.

02:04:01.400 --> 02:04:03.280
Und wenn das alles gut geht,

02:04:03.480 --> 02:04:05.560
also wenn die verschiedenen Threads

02:04:05.560 --> 02:04:07.540
sich nicht gegenseitig auf die Füße rumtrampeln,

02:04:08.200 --> 02:04:12.660
Dann führt das halt dazu, dass du wirklich sehr gut skalierenden Python-Code schreiben kannst.

02:04:12.860 --> 02:04:18.520
Also skalierend heißt, wenn du 16 Cores hast, dann kannst du halt dann auch 16 Mal schneller einen Code schreiben.

02:04:19.560 --> 02:04:23.440
Das Problem ist jetzt, was machst du, wenn das nicht so gut klappt mit den Transaktionen?

02:04:23.440 --> 02:04:29.160
Und du hast halt einen Thread, der versucht, seine Transaktion zu committen und einen anderen Thread und da gibt es einen Konflikt.

02:04:29.640 --> 02:04:36.220
Dann bedeutet das immer, der eine Thread, der wirft die ganze Arbeit, die er gemacht hat, weg und fängt halt nochmal ein bisschen weiter hinten an.

02:04:36.660 --> 02:04:38.080
Wer ist denn der eine? Wer wirft den weg?

02:04:38.700 --> 02:04:39.780
Es gewinnt halt einer von denen.

02:04:39.800 --> 02:04:40.160
Zufällig.

02:04:40.400 --> 02:04:41.460
Nee, nicht so richtig zufällig.

02:04:41.520 --> 02:04:43.780
Du musst natürlich schon dann nach außen hin

02:04:43.780 --> 02:04:46.880
die Python-Semantik dann bewahren.

02:04:47.060 --> 02:04:49.060
Das darf quasi nicht beobachtbar sein.

02:04:50.260 --> 02:04:51.820
Und da wird es halt dann auch technisch sehr kompliziert.

02:04:51.960 --> 02:04:52.840
Da weiß ich auch nichts zu.

02:04:54.540 --> 02:04:56.880
Aber von außen ist halt die Idee,

02:04:57.540 --> 02:05:01.400
es gewinnt einer und die Semantik ist erhalten.

02:05:02.860 --> 02:05:03.940
Das Problem ist jetzt nicht,

02:05:04.660 --> 02:05:05.760
dass sich das merkwürdig verhält.

02:05:05.760 --> 02:05:07.920
Das Problem ist halt, wenn du Pech hast,

02:05:08.200 --> 02:05:14.340
dann sind alle deine 16 Cores irgendwie busy,

02:05:15.040 --> 02:05:16.760
aber dein Programm ist nur zweimal so schnell.

02:05:18.480 --> 02:05:20.340
Und das ist quasi so ein Performance-Bug.

02:05:21.560 --> 02:05:25.320
Und ich glaube, letztlich war das Problem,

02:05:25.420 --> 02:05:27.840
dass sie nicht so richtig die Werkzeuge gefunden haben,

02:05:27.840 --> 02:05:30.520
um an dieser Stelle dann weiterzukommen.

02:05:31.080 --> 02:05:32.200
Du hast halt diesen Performance-Bug.

02:05:32.520 --> 02:05:34.920
Irgendwo gibt es einen Konflikt zwischen den Threads.

02:05:35.320 --> 02:05:36.660
Aber was machst du jetzt als Programmierer?

02:05:37.400 --> 02:05:38.720
wenn du halt Performance-Probleme

02:05:38.720 --> 02:05:40.500
in Python-Code hast, dann gibt es halt Tools, so Profiler

02:05:40.500 --> 02:05:42.500
und so. Und dann kannst du die

02:05:42.500 --> 02:05:44.460
benutzen, um rauszufinden, wo du vielleicht was optimieren könntest.

02:05:44.860 --> 02:05:45.600
Aber für dieses,

02:05:46.500 --> 02:05:48.600
wir haben jetzt zu viele Konflikte-Probleme,

02:05:48.660 --> 02:05:49.700
da gibt es halt keine Tools.

02:05:50.700 --> 02:05:52.460
Und da wussten die halt zum Teil dann auch

02:05:52.460 --> 02:05:54.600
selber nicht, wo jetzt die Zeit bleibt.

02:05:55.200 --> 02:05:56.160
Und die sind halt dann,

02:05:57.500 --> 02:05:58.420
ich habe so ein bisschen

02:05:58.420 --> 02:06:00.300
das Gefühl, irgendwann ist ihnen so dann

02:06:00.300 --> 02:06:02.280
die Prüste ausgegangen,

02:06:02.280 --> 02:06:03.120
vielleicht, also nach

02:06:03.120 --> 02:06:04.980
sechs, sieben Jahren.

02:06:06.540 --> 02:06:06.660
Ja.

02:06:07.400 --> 02:06:24.440
Und es ist ja jetzt auch ganz interessant, ich finde es halt interessant, dass es jetzt diesen Prototypen von Facebook gibt, wo halt in gewisser Weise so ein ganz klassischer Ansatz, also das ist halt immer Amins Idee.

02:06:24.440 --> 02:06:37.260
Amins Ansatz war ja mit dem Budgetgenerator auch schon so, der hat eine Vision, die ist technisch irgendwie elegant und dann versucht er das umzusetzen und bei Budgetgenerator hat es geklappt und bei Software Transactional Memory hat es halt leider nicht geklappt.

02:06:37.400 --> 02:06:39.320
Und vielleicht, wenn er noch ein paar Jahre weitergemacht hätte,

02:06:39.380 --> 02:06:40.340
hätte es auch irgendwann geklappt, aber

02:06:40.340 --> 02:06:43.340
momentan arbeitet er da halt nicht mehr

02:06:43.340 --> 02:06:43.680
daran weiter.

02:06:45.600 --> 02:06:47.220
Aber jetzt, der Facebook-Code, der ist ja quasi

02:06:47.220 --> 02:06:48.800
in gewisser Weise ganz klassisches

02:06:48.800 --> 02:06:51.500
Engineering. Also die haben halt quasi

02:06:51.500 --> 02:06:53.440
wirklich

02:06:53.440 --> 02:06:55.100
ganz klassisch, so wie man halt

02:06:55.100 --> 02:06:57.220
irgendwie Shared-Memory-Multiprocessing

02:06:57.760 --> 02:06:59.160
macht, das

02:06:59.160 --> 02:07:00.760
implementiert mit einer

02:07:00.760 --> 02:07:02.920
sehr coolen neuen Einsicht.

02:07:03.620 --> 02:07:05.080
Da haben wir vorhin auch schon ganz kurz drüber gesprochen.

02:07:05.440 --> 02:07:05.920
Nämlich,

02:07:06.680 --> 02:07:08.660
also wie gesagt, das ist überhaupt nicht mein

02:07:08.660 --> 02:07:10.120
Gebiet, ich kenne mich da nur sehr schlecht aus,

02:07:10.540 --> 02:07:12.280
aber die Idee ist, glaube ich, dieses Biased Locking, oder?

02:07:14.220 --> 02:07:14.620
Genau,

02:07:14.800 --> 02:07:16.320
Biased Reference Counting.

02:07:16.660 --> 02:07:18.100
Genau, also die Idee ist quasi, dass

02:07:18.100 --> 02:07:20.360
ein Objekt meistens

02:07:20.360 --> 02:07:22.020
in dem Thread benutzt wird,

02:07:22.440 --> 02:07:23.520
in dem es auch erzeugt wurde.

02:07:24.180 --> 02:07:26.540
Und es gibt halt dann so ein Fast Path,

02:07:27.020 --> 02:07:28.360
solange das Objekt nur in diesem

02:07:28.360 --> 02:07:30.380
Thread benutzt wird, sind die Zugriffe

02:07:30.380 --> 02:07:31.580
auf dieses Objekt

02:07:31.580 --> 02:07:34.160
sehr schnell. Also da ist die

02:07:34.160 --> 02:07:36.560
Synchronisierung zwischen den Threads

02:07:36.560 --> 02:07:37.580
quasi umsonst.

02:07:39.220 --> 02:07:40.480
Und erst wenn man das wirklich dann

02:07:40.480 --> 02:07:42.600
in einem anderen Thread auch benutzen will,

02:07:43.380 --> 02:07:44.360
wird es halt dann

02:07:44.360 --> 02:07:45.600
performance-mäßig teurer.

02:07:46.960 --> 02:07:48.720
Und das ist quasi

02:07:48.720 --> 02:07:50.540
eine neue Einsicht. Die kommt jetzt in

02:07:50.540 --> 02:07:52.120
diesen klassischen Ansatz,

02:07:52.300 --> 02:07:54.380
Shared-Memory-Multiprocessing mit Logs und so zu machen,

02:07:54.560 --> 02:07:56.640
kommt das dazu. Und es hat sich halt herausgestellt,

02:07:56.720 --> 02:07:58.000
dass das quasi der richtige ist,

02:07:58.480 --> 02:07:59.860
um den Overhead für

02:07:59.860 --> 02:08:01.780
Single-Threaded-Code

02:08:01.780 --> 02:08:03.260
klein zu kriegen.

02:08:04.720 --> 02:08:05.320
Es gibt

02:08:05.320 --> 02:08:15.240
Es gibt auch so ein paar Tricks, also ein interessanter Trick ist, weil es gibt dann ja deutlich mehr so viele Sachen, die halt schon in allen Threads verwendet werden, also alles was irgendwie globale Ports und so Zeug.

02:08:15.480 --> 02:08:16.180
Also None zum Beispiel.

02:08:16.300 --> 02:08:26.920
Ja, None, True, False, sowas, genau. Und die erklärt man dann einfach zu unsterblichen Objekten, sozusagen macht kein Reference Counting, weil man sagt, das wird sowieso nie differenziert.

02:08:26.920 --> 02:08:28.800
Ja, aber was mir zum Beispiel noch nicht so ganz klar ist,

02:08:29.320 --> 02:08:30.740
man hat ja dann eigentlich

02:08:30.740 --> 02:08:33.340
oft auch an irgendeiner Stelle

02:08:33.340 --> 02:08:35.400
doch eine gesharete Datenstruktur. Also wenn du halt zum Beispiel

02:08:35.400 --> 02:08:37.400
irgendwie so ein Workstealing implementieren

02:08:37.400 --> 02:08:39.320
willst und du nimmst halt einfach eine Liste,

02:08:40.700 --> 02:08:41.560
geht

02:08:41.560 --> 02:08:43.380
das dann noch? Oder ist halt diese, ist

02:08:43.380 --> 02:08:45.120
dann zu viel Contention auf dieser Liste? Oder

02:08:45.120 --> 02:08:47.340
das, also diese Feinheiten,

02:08:47.800 --> 02:08:49.280
also wie da dann wirklich die Performance

02:08:49.280 --> 02:08:50.740
sich dann in der Praxis wirklich verhält.

02:08:50.900 --> 02:08:53.000
Was ist ein Workstealing? Ich glaube, das weiß halt keiner.

02:08:54.060 --> 02:08:54.840
Was ist ein Workstealing?

02:08:55.240 --> 02:08:57.060
Also bei Workstealing ist halt quasi, du hast

02:08:57.060 --> 02:08:58.540
verschiedene Arbeitspakete

02:08:58.540 --> 02:09:01.360
und verschiedene Threads, die die abarbeiten

02:09:01.360 --> 02:09:02.680
und

02:09:02.680 --> 02:09:05.480
du koordinierst

02:09:05.480 --> 02:09:07.380
diese Threads halt über irgendeinen

02:09:07.380 --> 02:09:09.420
Q. Und die Frage ist

02:09:09.420 --> 02:09:11.300
jetzt, welche Datenstruktur benutzt du, um

02:09:11.300 --> 02:09:11.820
diese Q

02:09:11.820 --> 02:09:15.580
zu

02:09:15.580 --> 02:09:16.300
repräsentieren?

02:09:17.340 --> 02:09:19.280
Und Workstealing ist einerseits, da hat

02:09:19.280 --> 02:09:21.260
jeder Thread seinen eigenen Q,

02:09:21.360 --> 02:09:23.120
glaube ich, und wenn ein Thread

02:09:23.120 --> 02:09:25.160
nichts mehr in seiner eigenen Q hat, dann klaut er was

02:09:25.160 --> 02:09:27.020
aus den Queues. Also ich stelle mir das immer so ein bisschen vor

02:09:27.020 --> 02:09:29.120
wie so eine Bank, wo irgendwelche Leute am Schalter stehen

02:09:29.120 --> 02:09:31.020
und warten, bis sie dran können. Und dann sind bestimmte

02:09:31.020 --> 02:09:32.700
Schalter halt auf, bestimmte Schalter halt nicht.

02:09:32.840 --> 02:09:34.820
Und da kann halt irgendwie sich Leute anstellen

02:09:34.820 --> 02:09:36.220
an verschiedenen Schaltern und wenn irgendwie

02:09:36.220 --> 02:09:38.300
eine gerade keine

02:09:38.300 --> 02:09:40.840
Kundin mehr vor sich hat, dann geht halt jemand drüber.

02:09:41.840 --> 02:09:43.160
Aber ich glaube, also wie da

02:09:43.160 --> 02:09:44.800
so, ich habe da kein gutes Modell.

02:09:44.880 --> 02:09:46.560
Also ich bin wirklich ein sehr

02:09:46.560 --> 02:09:47.740
single-threaded Mensch.

02:09:48.640 --> 02:09:50.460
Ich kann das auch nicht, aber

02:09:50.460 --> 02:09:52.800
ich habe mein mentales Modell,

02:09:52.800 --> 02:09:54.980
das existiert

02:09:54.980 --> 02:09:56.900
einfach noch nicht. Ich weiß halt nicht, was

02:09:56.900 --> 02:09:58.980
passiert mit der Performance, wenn man halt

02:09:58.980 --> 02:10:00.980
irgendwie 17 Threads hat, die auf

02:10:00.980 --> 02:10:03.020
17 Kurs laufen und die wollen alle auf eine

02:10:03.020 --> 02:10:05.000
Liste zugreifen. Also das ist auch etwas, was irgendwie

02:10:05.000 --> 02:10:07.000
sehr schlecht, also immer wenn ich mit

02:10:07.000 --> 02:10:09.060
sowas zu tun hatte, musste ich

02:10:09.060 --> 02:10:10.960
feststellen, wenn ich vorher nicht schon auch das

02:10:10.960 --> 02:10:13.120
Gefühl hatte, ich kann das gar nicht, dass ich es dann

02:10:13.120 --> 02:10:15.140
wenn, dachte ich, ich kann es theoretisch

02:10:15.140 --> 02:10:16.880
und dann praktisch aber feststellen muss ich ganz nicht, weil

02:10:16.880 --> 02:10:18.240
es ist wirklich

02:10:18.240 --> 02:10:20.960
und es mefft halt nicht auf die Art, wie Menschen denken

02:10:20.960 --> 02:10:22.940
gut. Und es ist auch ganz interessant, also

02:10:22.940 --> 02:10:25.080
es gibt ja zwei, mindestens

02:10:25.080 --> 02:10:27.120
zwei Implementierungen von Python, die halt auch

02:10:27.120 --> 02:10:28.580
keinen Dill haben, nämlich Jython.

02:10:29.600 --> 02:10:31.120
Jython ist, soweit ich

02:10:31.120 --> 02:10:32.280
das sehen kann, relativ tot, aber

02:10:32.280 --> 02:10:34.900
so in der 2.7 ist es ein sehr guter

02:10:34.900 --> 02:10:36.320
2.7 Interpreter, der halt

02:10:36.320 --> 02:10:38.140
Implementierung, der halt

02:10:38.140 --> 02:10:40.940
keinen Dill hat, der halt wirklich Multithreading kann.

02:10:41.760 --> 02:10:42.880
Das ist auch eine ganz, ganz

02:10:42.880 --> 02:10:44.960
fast, das war etwas, was ich jetzt bei dem

02:10:44.960 --> 02:10:47.100
Durchhören der Folgen, eine der Neuigkeiten,

02:10:47.100 --> 02:10:49.240
die ich da mitgenommen habe, die ich vorher echt gar nicht wusste

02:10:49.240 --> 02:10:51.020
und mich fragen, wie mir das entgegen konnte, aber

02:10:51.020 --> 02:10:53.440
dass halt, wohl wenn man einen JIT-Compiler

02:10:53.440 --> 02:10:54.920
hat, dass es viel besser geht mit dem

02:10:54.920 --> 02:10:57.180
Fine-Grain-Blocking, sozusagen, dass man

02:10:57.180 --> 02:10:59.160
gar nicht unbedingt ein JIT braucht, dass es

02:10:59.160 --> 02:10:59.740
halt mit einem

02:10:59.740 --> 02:11:03.180
Interpreter, der in C geschrieben ist und der statisch

02:11:03.180 --> 02:11:04.840
kompiliert ist, geht das gar nicht richtig.

02:11:05.200 --> 02:11:06.960
Aber Java, wenn er

02:11:06.960 --> 02:11:09.740
das von einem JIT-Compiler

02:11:09.740 --> 02:11:11.400
verwandelt, ist das kein Problem

02:11:11.400 --> 02:11:13.140
sozusagen und da kann man das dann ohne

02:11:13.140 --> 02:11:15.200
JIT mit Fine-Grain-Blocking machen und es wird halt nicht langsam

02:11:15.200 --> 02:11:16.680
dadurch. Ja, also

02:11:16.680 --> 02:11:19.160
das ist nicht so

02:11:19.160 --> 02:11:21.140
leicht, aber der JIT kann halt dann quasi

02:11:21.140 --> 02:11:23.140
der JIT macht dann

02:11:23.140 --> 02:11:24.960
so Reasoning über

02:11:24.960 --> 02:11:27.200
darüber, ob man gerade von einem

02:11:27.200 --> 02:11:28.720
Objekt den Log schon hat und dann

02:11:28.720 --> 02:11:30.600
muss man halt nicht bei jeder Operation

02:11:30.600 --> 02:11:33.220
versuchen, sich das Log zu holen, sondern macht das nur

02:11:33.220 --> 02:11:35.320
einmal in der Funktion

02:11:35.320 --> 02:11:37.160
oder nur an bestimmten Punkten oder also

02:11:37.160 --> 02:11:39.260
und man macht halt dann nicht bei jedem

02:11:39.260 --> 02:11:41.260
Field Read muss man sich das Log holen,

02:11:41.300 --> 02:11:43.200
sondern kann sagen, wir lesen hier 17

02:11:43.200 --> 02:11:44.760
verschiedene Felder und wir holen uns das nur einmal.

02:11:45.660 --> 02:11:47.320
Und das kann der JIT halt machen, das kann der Interpreter

02:11:47.320 --> 02:11:47.740
nicht machen.

02:11:49.160 --> 02:11:51.620
aber ja, also da sind wir noch nicht

02:11:51.620 --> 02:11:53.180
in Python, ja, genau, aber

02:11:53.180 --> 02:11:55.540
Jython konnte das halt und da hat sich aber

02:11:55.540 --> 02:11:57.040
interessanterweise halt dann rausgestellt, dass

02:11:57.040 --> 02:11:59.740
es halt unglaublich viele Bibliotheken

02:11:59.740 --> 02:12:01.640
gibt in Python, die

02:12:01.640 --> 02:12:03.600
halt einfach natürlich überhaupt nicht Threadsafe

02:12:03.600 --> 02:12:05.600
sind, natürlich nicht, weil

02:12:05.600 --> 02:12:07.600
wie soll denn die

02:12:07.600 --> 02:12:09.840
Bugs gefunden werden, wenn halt die Standard-Immunisierung

02:12:09.840 --> 02:12:11.380
halt einfach immer

02:12:11.380 --> 02:12:13.300
Single-Threaded ist und

02:12:13.300 --> 02:12:17.520
selbst in der Standard-Bibliothek hat halt

02:12:17.520 --> 02:12:19.720
Jython damals quasi

02:12:19.720 --> 02:12:20.760
einiges an Wachs gefunden,

02:12:21.660 --> 02:12:23.700
wo es halt Deadlocks und alles mögliche gab,

02:12:24.660 --> 02:12:25.820
weil der Code

02:12:25.820 --> 02:12:27.300
in der Standardbibliothek von

02:12:27.300 --> 02:12:28.740
Jython halt einfach

02:12:28.740 --> 02:12:31.680
den Gil präsent

02:12:31.680 --> 02:12:33.620
poniert. Und ich denke,

02:12:33.680 --> 02:12:34.880
das wird halt schon dann auch nochmal

02:12:34.880 --> 02:12:37.100
für die Community auch ein ganz schön

02:12:37.100 --> 02:12:39.640
langwieriger Prozess, bis man

02:12:39.640 --> 02:12:41.620
halt wirklich an dem Punkt ist, dass alle Bibliotheken dann auch

02:12:41.620 --> 02:12:42.040
gehen.

02:12:44.940 --> 02:12:45.460
Ich wollte

02:12:45.460 --> 02:12:47.980
noch eine Sache

02:12:47.980 --> 02:12:49.720
erwähnen, das kam noch gar nicht vor

02:12:49.720 --> 02:12:51.680
in unserer Geschichte. Es gibt

02:12:51.680 --> 02:12:53.440
tatsächlich noch einen Bereich, wo

02:12:53.440 --> 02:12:55.720
sehr, sehr viel Aktivität gerade noch stattfindet

02:12:55.720 --> 02:12:57.840
im so weiteren PyPy-Umfeld

02:12:57.840 --> 02:12:59.800
und da bin ich

02:12:59.800 --> 02:13:01.700
auch nicht ganz direkt beteiligt, aber der ist meiner Ansicht nach

02:13:01.700 --> 02:13:03.640
auch schon sehr interessant und das ist nämlich genau

02:13:03.640 --> 02:13:05.920
die Frage nach NC-geschriebenen

02:13:05.920 --> 02:13:06.920
Bibliotheken

02:13:06.920 --> 02:13:09.160
und das Projekt heißt

02:13:09.160 --> 02:13:11.460
H-Py und das ist

02:13:11.460 --> 02:13:13.400
ein relativ gut

02:13:13.400 --> 02:13:14.320
finanziertes

02:13:14.320 --> 02:13:15.960
eigenes

02:13:15.960 --> 02:13:18.000
Open-Source-Projekt, was quasi als

02:13:18.000 --> 02:13:19.860
Idee hat, dass sie eine

02:13:19.860 --> 02:13:22.480
Next-Generation-C-API

02:13:22.480 --> 02:13:23.240
für Python

02:13:23.240 --> 02:13:24.820
entwickeln.

02:13:26.100 --> 02:13:27.940
Und die C-API,

02:13:28.020 --> 02:13:29.600
die es eben jetzt bisher gibt,

02:13:30.320 --> 02:13:31.100
die ist halt

02:13:31.100 --> 02:13:34.040
in gewisser Weise so organisch gewachsen

02:13:34.040 --> 02:13:35.840
aus C-Python heraus.

02:13:36.440 --> 02:13:37.360
Weil das ist ja einfach,

02:13:38.340 --> 02:13:40.200
wenn man die C-API benutzt,

02:13:40.820 --> 02:13:41.020
dann

02:13:41.020 --> 02:13:44.100
greift man einfach direkt auf die Datenstrukturen

02:13:44.100 --> 02:13:46.180
zu, die C-Python halt einfach zufällig

02:13:46.180 --> 02:13:47.940
hat. Und wenn man eine andere Implementierung

02:13:47.940 --> 02:13:49.320
schreiben will und die ist anders,

02:13:49.920 --> 02:13:52.040
dann hat man ein Problem, weil dann passt das halt nicht zusammen.

02:13:53.080 --> 02:13:54.240
Und HPAI ist halt die Idee,

02:13:54.720 --> 02:13:55.500
wir fangen einfach so

02:13:55.500 --> 02:13:57.840
nicht ganz auf dem Reißpfeil, aber wir machen

02:13:57.840 --> 02:14:00.160
einfach nochmal drei Schritte zurück und wir überlegen uns,

02:14:00.520 --> 02:14:01.960
wie würde denn eine API

02:14:01.960 --> 02:14:02.980
in C aussehen,

02:14:04.140 --> 02:14:06.140
wenn man sie jetzt nochmal neu machen würde.

02:14:06.640 --> 02:14:08.100
Und da gibt es schon auch dann,

02:14:09.240 --> 02:14:10.060
also das ist jetzt,

02:14:10.060 --> 02:14:11.060
das ist quasi noch

02:14:11.060 --> 02:14:14.040
in der Mache, es ist irgendwie

02:14:14.040 --> 02:14:16.080
Version 0,04 raus oder so

02:14:16.080 --> 02:14:18.000
oder die wollen jetzt irgendwann bald mal

02:14:18.000 --> 02:14:19.700
zu einem 1.0 kommen. Aber

02:14:19.700 --> 02:14:21.880
da ist halt wirklich die Idee, wie würde man

02:14:21.880 --> 02:14:24.020
eine API designen, die für alle

02:14:24.020 --> 02:14:26.040
Implementierungen für Python gleichermaßen

02:14:26.040 --> 02:14:28.000
funktioniert. Und die hat

02:14:28.000 --> 02:14:29.720
ein paar sehr interessante Eigenschaften. Zum Beispiel

02:14:29.720 --> 02:14:31.480
die ist halt

02:14:31.480 --> 02:14:33.700
absolut ABI-kompatibel.

02:14:34.260 --> 02:14:35.900
Du musst, vorwärtskompatibel,

02:14:36.320 --> 02:14:38.140
du musst niemals neue

02:14:38.140 --> 02:14:40.180
Shared Libraries kompilieren.

02:14:41.100 --> 02:14:41.700
Du kannst die,

02:14:41.780 --> 02:14:43.340
die Idee ist, dass man quasi

02:14:43.340 --> 02:14:45.040
so ein bisschen Windows-mäßig

02:14:45.040 --> 02:14:46.880
unendlich lange in die Zukunft

02:14:46.880 --> 02:14:49.220
alle alten Share-Libraries

02:14:49.220 --> 02:14:51.160
weiter benutzen kann. Das ist

02:14:51.160 --> 02:14:53.180
eines der Designziele. Ein anderes

02:14:53.180 --> 02:14:54.220
Designziel ist, dass man

02:14:54.220 --> 02:14:57.180
den Debugging-Mode anschalten

02:14:57.180 --> 02:14:59.080
kann für den C-Code,

02:14:59.880 --> 02:15:00.860
ohne dass man

02:15:00.860 --> 02:15:03.280
neu kopieren muss. Sondern quasi

02:15:03.280 --> 02:15:04.980
zur Importzeit kannst du sagen,

02:15:05.580 --> 02:15:06.740
hier ist irgendein komischer Crash,

02:15:07.480 --> 02:15:09.040
mach mal bitte den Debugging-Mode an

02:15:09.040 --> 02:15:10.860
und dann findet er zum Beispiel

02:15:10.860 --> 02:15:12.960
Reference-Counting-Probleme

02:15:12.960 --> 02:15:15.120
in der CPU-Bibliothek,

02:15:15.240 --> 02:15:16.660
ohne dass man die neu kompilieren muss.

02:15:16.760 --> 02:15:18.920
Das ist ein anderes, finde ich, sehr interessanter Eigenschaft.

02:15:19.780 --> 02:15:21.180
Und also das Coole ist,

02:15:21.560 --> 02:15:23.080
dass Oracle

02:15:23.080 --> 02:15:24.780
hat auch eine Python-Implementierung, die heißt

02:15:24.780 --> 02:15:27.060
GraalPy. Und die haben jetzt

02:15:27.060 --> 02:15:28.880
quasi zwei ihrer Entwickler oder

02:15:28.880 --> 02:15:31.020
zweieinhalb ihrer Entwickler dafür angestellt,

02:15:31.420 --> 02:15:33.140
sich eben zu überlegen, wie man

02:15:33.140 --> 02:15:34.920
dieses H-Py-Ding designt. Und da

02:15:34.920 --> 02:15:36.540
passiert also quasi so richtig was.

02:15:37.260 --> 02:15:39.060
Und ich habe halt die Hoffnung, dass jetzt irgendwann

02:15:39.060 --> 02:15:40.140
in diesem 2023

02:15:40.140 --> 02:15:42.480
es da die ersten Releases gibt.

02:15:42.960 --> 02:16:04.840
Und das ist schon auch so, dass es quasi jetzt das Portieren von der existierenden API auf HBi nicht ganz automatisiert werden kann, aber vielleicht so ein bisschen. Also das ist jetzt auch an allen Stellen, wo man quasi an der alten API dranbleiben kann, haben sie versucht, sich an der existierenden API zu orientieren, um das Portieren eben möglich zu machen.

02:16:05.200 --> 02:16:07.140
Und nur an den Stellen, wo das eben nicht

02:16:07.140 --> 02:16:07.580
ging,

02:16:08.640 --> 02:16:11.120
ohne die Ziele

02:16:11.120 --> 02:16:13.080
zu gefährden, haben sie dann

02:16:13.080 --> 02:16:14.560
eben sich entschieden, davon abzuweichen.

02:16:15.680 --> 02:16:16.700
Naja, also auf jeden Fall,

02:16:17.360 --> 02:16:19.060
wie gesagt, ich bin da nicht mit involviert.

02:16:19.260 --> 02:16:20.140
Ich rede manchmal mit denen.

02:16:20.140 --> 02:16:21.420
Das ist einer der GraalPi.

02:16:21.620 --> 02:16:23.760
Der GraalPi-Tag-Lead ist ein guter Freund von mir.

02:16:23.860 --> 02:16:24.780
Wir telefonieren dann ab und zu.

02:16:25.940 --> 02:16:27.900
Aber ich bin halt sehr hoffnungsvoll, dass das

02:16:27.900 --> 02:16:30.080
bald mal ein Release gibt

02:16:30.080 --> 02:16:31.000
und vielleicht auch

02:16:31.000 --> 02:16:34.100
in Zeiten Supporter für eingebaut wird.

02:16:34.200 --> 02:16:34.980
Das wäre sehr, sehr cool.

02:16:35.200 --> 02:16:43.020
Und das würde eben dazu führen, dass in Zukunft Extensions, die H-Pi benutzen, halt auch wirklich schnell auf Pi-Pi sind.

02:16:43.600 --> 02:16:58.760
Und dann hätten wir unser, also es gibt dann ganz, ganz viele Fliegen, die mit einer Klappe geschlagen würden, unter anderem eben möglicherweise, dass es effizient in Pi-Pi ist, dass es effizient in Graal-Pi ist, trotzdem nicht langsamer ist auf C-Python.

02:17:00.440 --> 02:17:19.220
Und der Übergang zum vorigen Thema ist jetzt, dass sie gerade auch, soweit ich das verstehen kann, so ein bisschen anfangen darüber nachzudenken, ob man denn da auch die Jill-Änderungen, die nötig würden für die C-Extensions, auch noch mit unterbringen könnte. Und das wäre halt sehr, sehr cool.

02:17:19.640 --> 02:17:21.260
Weil das würde dann direkt funktionieren,

02:17:21.360 --> 02:17:22.680
ohne dass man da nochmal was ändern müsste.

02:17:22.680 --> 02:17:23.040
Ganz genau.

02:17:23.420 --> 02:17:26.940
Und wenn dann eine Extension quasi in der Situation kommt,

02:17:27.000 --> 02:17:28.640
dass sie jetzt ganz viel anpassen müsste,

02:17:29.140 --> 02:17:30.720
um mit dem Jail zu funktionieren,

02:17:31.380 --> 02:17:32.660
dann könnte die halt sagen,

02:17:32.740 --> 02:17:34.860
na gut, dann gehen wir halt vielleicht gleich zu dieser neuen API,

02:17:35.560 --> 02:17:37.740
nehmen noch einen ganzen Haufen andere Benefits mit

02:17:37.740 --> 02:17:41.200
und sind aber trotzdem auch kompatibel zu den neuen Jail-Features.

02:17:42.300 --> 02:17:44.540
Also ich bin mir nicht sicher, ob die das schaffen.

02:17:44.540 --> 02:17:45.640
Und ich weiß auch nicht,

02:17:47.000 --> 02:17:47.500
Also bei so

02:17:47.500 --> 02:17:50.560
Funding durch Firmen, da kann halt auch mal

02:17:50.560 --> 02:17:52.080
passieren, dass ein Manager sagt,

02:17:52.240 --> 02:17:53.600
brauchen wir nicht mehr.

02:17:55.140 --> 02:17:56.600
Aber das wäre halt cool.

02:17:57.160 --> 02:17:58.580
Also das ist ein Projekt, was ich

02:17:58.580 --> 02:18:01.580
sehr exciting finde und wo ich hoffe, dass

02:18:01.580 --> 02:18:02.660
da in diesem Jahr halt noch

02:18:02.660 --> 02:18:04.520
viel passieren wird. Wir haben leider

02:18:04.520 --> 02:18:06.460
also wir haben kein

02:18:06.460 --> 02:18:08.540
wir haben kein offizielles

02:18:08.540 --> 02:18:10.080
Buy-in von CPython.

02:18:10.560 --> 02:18:12.360
Also es gibt einige CPython-Entwickler, die

02:18:12.360 --> 02:18:14.360
quasi sehr

02:18:14.360 --> 02:18:16.480
wohlwollend sind, aber

02:18:16.480 --> 02:18:18.880
wir haben quasi kein offizielles

02:18:18.880 --> 02:18:19.520
Endorsement.

02:18:21.840 --> 02:18:22.680
Wir sind immer mal

02:18:22.680 --> 02:18:24.480
ein bisschen am überlegen, ob es

02:18:24.480 --> 02:18:26.540
ein sinnvolles PEP, also ich habe jetzt

02:18:26.540 --> 02:18:27.320
wie gesagt, ich bin dann

02:18:27.320 --> 02:18:30.420
ich als interessierter Beobachter bin nicht

02:18:30.420 --> 02:18:31.940
wirklich, also ich schreibe keinen Code dafür, aber

02:18:31.940 --> 02:18:34.440
die HP-Leute denken auch immer mal darüber

02:18:34.440 --> 02:18:36.360
nach, was man für ein PEP

02:18:36.360 --> 02:18:37.700
schreiben könnte und was da

02:18:37.700 --> 02:18:40.260
ist halt gar nicht so ganz klar, was man von C-Python

02:18:40.260 --> 02:18:42.460
wollen würde, weil

02:18:42.460 --> 02:18:44.300
es ist jetzt, die wollen halt

02:18:44.300 --> 02:18:46.300
nicht sagen, die wollen nicht, die

02:18:46.300 --> 02:18:48.100
Designverantwortung wieder an C-Python zurückgeben.

02:18:48.900 --> 02:18:49.540
Also eines der

02:18:49.540 --> 02:18:52.320
Vorteile ist eben gerade, dass es

02:18:52.320 --> 02:18:54.180
ein externes Team ist, was das komplett

02:18:54.180 --> 02:18:55.880
unabhängig von C-Python macht und

02:18:55.880 --> 02:18:58.480
deswegen, das soll jetzt nicht irgendwie

02:18:58.480 --> 02:19:02.160
wieder C-Python untergeordnet werden, so

02:19:02.160 --> 02:19:04.300
als Projekt, aber deswegen ist halt auch

02:19:04.300 --> 02:19:06.140
gar nicht so klar, was ist das

02:19:06.140 --> 02:19:07.820
Ergebnis dieses Peps, ist das irgendwie

02:19:07.820 --> 02:19:10.140
ein reines, also dieses hypothetische

02:19:10.140 --> 02:19:11.780
noch nicht geschriebene Peps, ist das ein reines

02:19:11.780 --> 02:19:13.820
Informationspapier, wir arbeiten daran,

02:19:14.420 --> 02:19:15.720
nehmt uns wahr und

02:19:15.720 --> 02:19:18.660
also ja, da denken wir halt

02:19:18.660 --> 02:19:20.300
bis zur Tour nach. Also es gibt den

02:19:20.300 --> 02:19:22.640
Lukasz Langer, der

02:19:22.640 --> 02:19:23.800
auch von

02:19:23.800 --> 02:19:26.780
Vollzeit an über die PSF

02:19:26.780 --> 02:19:28.380
an den Teamweizen arbeitet.

02:19:29.060 --> 02:19:30.320
Der war auch bei dem

02:19:30.320 --> 02:19:31.760
8-Pile-Sprint im

02:19:31.760 --> 02:19:33.740
September hier in Düsseldorf.

02:19:34.560 --> 02:19:35.960
Also der ist auch ein Core-Dev, der

02:19:35.960 --> 02:19:38.840
informiert

02:19:38.840 --> 02:19:39.940
und involviert und

02:19:39.940 --> 02:19:40.940
wohlwollend ist.

02:19:42.940 --> 02:19:44.160
Aber so von den

02:19:44.160 --> 02:19:47.380
Hardcore-Performance-Leuten

02:19:47.380 --> 02:19:51.380
gibt es jetzt quasi keine offizielle Aussage,

02:19:51.440 --> 02:19:52.280
dass sie das irgendwie toll finden.

02:19:52.600 --> 02:19:55.300
Aber ich hoffe halt, dass da

02:19:55.300 --> 02:19:57.580
in diesem Jahr noch ein paar interessante Sachen

02:19:57.580 --> 02:19:57.820
passieren.

02:20:00.580 --> 02:20:01.180
Interessant, ja.

02:20:02.420 --> 02:20:02.780
Ja, ich meine,

02:20:03.300 --> 02:20:05.340
mir sagt das gar nicht so viel.

02:20:05.500 --> 02:20:06.840
Ich glaube, ich habe es nicht mal

02:20:06.840 --> 02:20:08.940
gehört, dass es da noch einen Interpreter

02:20:08.940 --> 02:20:10.520
für Python gibt.

02:20:11.520 --> 02:20:12.680
So viele sind ja auch nicht mehr übrig.

02:20:12.860 --> 02:20:14.420
Jyton, Iron Python,

02:20:15.120 --> 02:20:17.380
das ist alles nicht mehr so

02:20:17.380 --> 02:20:19.140
richtig da. Unladen Swallow

02:20:19.140 --> 02:20:21.040
gab es auch. Ja, das ist lange tot.

02:20:22.580 --> 02:20:23.400
Ja, PyPy

02:20:23.400 --> 02:20:25.240
ist so eine der ganz

02:20:25.240 --> 02:20:27.060
wenigen, die

02:20:27.060 --> 02:20:29.160
überlebend sind. Ja, genau. Also GraalPy

02:20:29.160 --> 02:20:31.040
halt auch. Also GraalPy hat halt wirklich ein Team,

02:20:31.120 --> 02:20:32.720
die sind auch bezahlt und haben da

02:20:32.720 --> 02:20:34.780
von der Funding-Situation sind die ziemlich gut.

02:20:35.780 --> 02:20:36.660
Die haben so ein paar,

02:20:37.080 --> 02:20:39.120
deren JIT ist auch ziemlich gut, die können

02:20:39.120 --> 02:20:40.900
wirklich schnell einen Python-Code ausführen.

02:20:41.680 --> 02:20:42.720
Die haben so ein bisschen das Problem,

02:20:42.860 --> 02:20:48.180
dass ihre Warm-up-Zeit sehr lange dauert.

02:20:48.520 --> 02:20:50.960
Also der Code wird halt erst nach vielen Minuten schnell.

02:20:51.780 --> 02:20:55.220
Und das heißt, du brauchst halt die richtige Art von Anwendung.

02:20:55.360 --> 02:20:57.540
Also so Long-Running-Server-Processes funktionieren super.

02:20:58.000 --> 02:21:00.080
Aber wenn du alle fünf Minuten deployst,

02:21:00.920 --> 02:21:01.960
dann halt nicht mehr.

02:21:03.860 --> 02:21:05.060
Aber da kommen die auch noch hin.

02:21:05.180 --> 02:21:06.580
Also die haben halt Geld im Moment.

02:21:06.580 --> 02:21:09.180
Das ist halt für eine Implementierung

02:21:09.180 --> 02:21:10.160
eine sehr angenehme Situation.

02:21:10.440 --> 02:21:11.420
Und der Tim weiß auch, was er tut.

02:21:12.760 --> 02:21:14.180
Ist sehr, sehr gut.

02:21:14.780 --> 02:21:16.500
Also Tim Felgenkopf

02:21:16.500 --> 02:21:17.620
heißt der Taglet.

02:21:18.420 --> 02:21:18.760
Und

02:21:18.760 --> 02:21:21.600
die sind glaube ich auch 3.10

02:21:21.600 --> 02:21:23.080
kompatibel und

02:21:23.080 --> 02:21:26.160
supporten C-Extensions

02:21:26.160 --> 02:21:28.240
und also das ist schon eine sehr ernstzunehmende

02:21:28.240 --> 02:21:28.760
Infektion.

02:21:30.180 --> 02:21:30.880
Ja, cool.

02:21:32.680 --> 02:21:34.180
Warum schreibt man sich sowas dann direkt

02:21:34.180 --> 02:21:36.020
in Rust, wenn man das eh statt in C neu zu schreiben?

02:21:36.420 --> 02:21:37.480
Die schreiben das in Java neu.

02:21:38.280 --> 02:21:39.760
Also Graal,

02:21:40.000 --> 02:21:41.840
wir wollen da, ich glaube da steigen wir jetzt nicht ein, aber

02:21:41.840 --> 02:21:44.540
gerade ist so ein bisschen die Piper-Idee

02:21:44.540 --> 02:21:46.160
nochmal

02:21:46.160 --> 02:21:47.620
in mit Geld.

02:21:48.280 --> 02:21:49.920
Also halt von Oracle,

02:21:50.100 --> 02:21:51.960
deswegen haben die, die haben einen R-Java,

02:21:52.160 --> 02:21:53.980
also die können quasi ihren Java-Code nach C

02:21:53.980 --> 02:21:55.700
übersetzen und

02:21:55.700 --> 02:21:57.760
haben den JIT-Compiler in C geschrieben und die haben auch

02:21:57.760 --> 02:22:00.080
diesen selben, technisch funktioniert

02:22:00.080 --> 02:22:02.100
das ein bisschen anders, aber die haben auch so eine ähnliche Motivation,

02:22:02.200 --> 02:22:03.520
die haben so einen Meta-JIT-Ansatz,

02:22:04.060 --> 02:22:05.860
dass sie quasi keinen JIT schreiben, sondern

02:22:05.860 --> 02:22:07.680
den JIT auch generieren

02:22:07.680 --> 02:22:09.200
aus einem Interpreter

02:22:09.200 --> 02:22:11.360
mit einer anderen Technik, aber

02:22:11.360 --> 02:22:13.380
aber halt so von der Motivation her ist das

02:22:13.380 --> 02:22:15.120
recht ähnlich und

02:22:15.120 --> 02:22:17.160
die benutzen das, also die haben halt irgendwie

02:22:17.160 --> 02:22:19.000
einen schnellen JavaScript-Implementierung

02:22:19.000 --> 02:22:21.180
und ein schnelles Python und

02:22:21.180 --> 02:22:23.140
natürlich irgendwie auch ein schnelles Java

02:22:23.140 --> 02:22:24.060
und

02:22:24.060 --> 02:22:27.440
ja, und das ist, und ein riesen

02:22:27.440 --> 02:22:28.940
Team, das muss man halt auch, also die haben halt

02:22:28.940 --> 02:22:31.360
eine

02:22:31.360 --> 02:22:33.240
zweistellige Anzahl an Leuten, die halt an diesem

02:22:33.240 --> 02:22:34.520
Zeug arbeiten und

02:22:34.520 --> 02:22:37.020
ist in gewisser Weise auch

02:22:37.020 --> 02:22:37.500
irgendwie

02:22:37.500 --> 02:22:41.060
sehr forschungslastig, das Projekt, also auch eine große,

02:22:41.060 --> 02:22:43.140
also ich würde sagen, es ist von Oracle eine große Wette.

02:22:43.740 --> 02:22:44.820
Also mir ist

02:22:44.820 --> 02:22:46.780
nicht so, also ich glaube im Moment

02:22:46.780 --> 02:22:48.920
verdient das Team halt kein Geld.

02:22:49.180 --> 02:22:51.340
Also es ist halt die Hoffnung, dass es irgendwann mal

02:22:51.340 --> 02:22:53.100
dann

02:22:53.100 --> 02:22:54.900
vielleicht doch Geld verdient, aber ich glaube im Moment

02:22:54.900 --> 02:22:56.700
ist es halt wirklich eine Wette.

02:22:57.280 --> 02:22:59.000
Und die läuft auch schon lang, also das Projekt ist

02:22:59.000 --> 02:22:59.940
irgendwie zehn Jahre alt oder so.

02:23:00.640 --> 02:23:03.120
So irgendwie 30 Leute über zehn Jahre

02:23:03.120 --> 02:23:04.220
anzustellen, das ist halt

02:23:04.220 --> 02:23:05.700
richtig teuer.

02:23:08.420 --> 02:23:08.820
Naja,

02:23:08.820 --> 02:23:09.660
aber also da

02:23:09.660 --> 02:23:12.620
weiß ich, also

02:23:12.620 --> 02:23:14.520
was da die

02:23:14.520 --> 02:23:16.800
Motivationen von so einer Firma sind, das weiß man halt

02:23:16.800 --> 02:23:18.900
immer nicht. Kann man halt

02:23:18.900 --> 02:23:20.840
dann munter spekulieren, das mach ich

02:23:20.840 --> 02:23:22.020
natürlich auch immer gern, aber ja.

02:23:25.020 --> 02:23:26.940
Also das ist quasi so ein bisschen Friendly-Competition,

02:23:26.940 --> 02:23:29.020
aber mit Betonung auf Friendly.

02:23:31.200 --> 02:23:32.900
Aber nochmal die Frage, warum sowas nicht in Rust

02:23:32.900 --> 02:23:34.360
irgendwie geschrieben wird jetzt, so ein neuer Link?

02:23:35.320 --> 02:23:36.900
Mir ist noch nicht so ganz klar,

02:23:37.560 --> 02:23:39.020
also es ist

02:23:39.020 --> 02:23:41.260
so ein bisschen so eine grundsätzliche Frage, in welcher

02:23:41.260 --> 02:23:42.920
Sprache implementiert man

02:23:42.920 --> 02:23:45.060
sein JIT?

02:23:46.080 --> 02:23:46.980
Und die

02:23:46.980 --> 02:23:48.960
klassische Antwort ist halt C oder C++.

02:23:50.560 --> 02:23:50.820
Und

02:23:50.820 --> 02:23:52.980
es gibt jetzt

02:23:52.980 --> 02:23:53.960
verschiedene so

02:23:53.960 --> 02:23:56.380
forschungsaffine Projekte wie

02:23:56.380 --> 02:23:58.940
Squeak, ganz klassischerweise,

02:23:59.300 --> 02:24:00.500
oder eben PyPy oder

02:24:00.500 --> 02:24:03.000
GraalPy, die halt sagen,

02:24:03.000 --> 02:24:04.440
es ist doch eigentlich viel cooler,

02:24:04.900 --> 02:24:06.840
wenn man eine Implementierungssprache nimmt, die

02:24:06.840 --> 02:24:08.940
halt irgendwie ein höheres

02:24:08.940 --> 02:24:11.200
Abstraktionslevel hat als C. Weil C ist halt

02:24:11.200 --> 02:24:13.080
doof und nicht memory safe und stürzt die ganze Zeit ab

02:24:13.080 --> 02:24:15.340
und man kann auch nicht schön abstrahieren

02:24:15.340 --> 02:24:17.220
und deswegen ist C halt keine schöne Sprache.

02:24:18.500 --> 02:24:18.740
Und

02:24:18.740 --> 02:24:21.140
genau, das sind dann die genannten

02:24:21.140 --> 02:24:22.940
Projekte. Und jetzt ist so ein bisschen die Frage, ob

02:24:22.940 --> 02:24:24.620
Rust eine

02:24:24.620 --> 02:24:27.040
gut geeignete Sprache

02:24:27.040 --> 02:24:28.420
ist, um JIT-Compiler zu schreiben.

02:24:29.200 --> 02:24:30.580
Und ich glaube, das weiß einfach noch keiner.

02:24:31.660 --> 02:24:33.320
Also es gibt genau

02:24:33.320 --> 02:24:34.300
ein

02:24:34.300 --> 02:24:36.940
großes JIT-Projekt, was Rust

02:24:36.940 --> 02:24:38.900
benutzt. Das habt ihr auch, glaube ich,

02:24:38.900 --> 02:24:40.500
in einer Folge darüber geredet, das ist dieses,

02:24:40.920 --> 02:24:42.960
der neue JIT für Ruby, der von Shopify

02:24:42.960 --> 02:24:43.720
finanziert ist.

02:24:45.040 --> 02:24:46.860
Es gibt übrigens auch ein großes

02:24:46.860 --> 02:24:48.160
Graal

02:24:48.160 --> 02:24:50.860
Ruby-Projekt, also

02:24:50.860 --> 02:24:53.020
das heißt TruffleRuby, das auch

02:24:53.020 --> 02:24:54.640
von Shopify zum Teil finanziert wird.

02:24:55.400 --> 02:24:56.600
Also die leisten sich mehrere

02:24:56.600 --> 02:24:58.680
eigene Ruby-Impositionen.

02:25:02.460 --> 02:25:02.900
Und

02:25:02.900 --> 02:25:04.960
das eben, heißt das

02:25:04.960 --> 02:25:06.460
YJIT? YJIT heißt es, ne?

02:25:06.660 --> 02:25:08.800
Ja. Genau. Und der ist

02:25:08.800 --> 02:25:10.580
eben in Rust geschrieben. Und ich glaube,

02:25:11.260 --> 02:25:12.680
die Jury ist halt noch so ein bisschen

02:25:12.680 --> 02:25:14.080
out, ob das

02:25:14.080 --> 02:25:16.920
wirklich die richtige Sprache

02:25:16.920 --> 02:25:18.540
für den JIT ist. Und mit der

02:25:18.540 --> 02:25:21.080
Maxime Chevalier-Boisvert,

02:25:21.160 --> 02:25:23.200
die das gestartet hat,

02:25:23.260 --> 02:25:24.000
YJIT bei Shopify,

02:25:24.960 --> 02:25:26.240
mit der zoome ich auch auf und zu.

02:25:26.780 --> 02:25:28.380
Die ist auch extrem gut.

02:25:31.300 --> 02:25:32.260
Aber was da

02:25:32.260 --> 02:25:34.640
ihre Conclusion wäre, ist

02:25:34.640 --> 02:25:36.800
Rust die richtige Sprache, um so einen JIT-Compiler zu

02:25:36.800 --> 02:25:38.780
schreiben. Das weiß

02:25:38.780 --> 02:25:40.760
ich jetzt. Also, das weiß ich noch nicht.

02:25:40.880 --> 02:25:42.540
Ich glaube, das weiß man dann,

02:25:43.040 --> 02:25:44.420
das kann man erst so ein bisschen abschließen,

02:25:44.520 --> 02:25:46.460
beurteilen nach dem dritten Jet vielleicht.

02:25:46.720 --> 02:25:50.660
Also, wenn man halt

02:25:50.660 --> 02:25:52.560
dann Rust nimmt, dann muss man sich halt klar machen,

02:25:52.740 --> 02:25:53.000
dass man

02:25:53.000 --> 02:25:56.380
sich da auf

02:25:56.380 --> 02:25:58.440
noch nicht ganz verstandenes Terrain

02:25:58.440 --> 02:25:59.860
bewegt.

02:26:00.820 --> 02:26:01.200
Ich meine,

02:26:02.980 --> 02:26:04.760
C++ ist halt so die akzeptierteste

02:26:04.760 --> 02:26:06.200
Sprache, um

02:26:06.200 --> 02:26:08.180
virtuelle Maschinen zu schreiben. Und das

02:26:08.180 --> 02:26:10.180
muss man jetzt nicht gut finden. Also ich persönlich

02:26:10.180 --> 02:26:11.400
finde es halt vielleicht nicht so gut.

02:26:12.100 --> 02:26:14.080
Aber das ist halt die Sprache, ich meine, das ist auch die

02:26:14.080 --> 02:26:15.360
Sprache, in der man halt in der Regel

02:26:15.360 --> 02:26:16.720
einen Compiler schreibt.

02:26:19.400 --> 02:26:19.760
Und

02:26:19.760 --> 02:26:22.340
wenn man

02:26:22.340 --> 02:26:23.920
irgendwas anderes nimmt, dann muss man sich halt klar machen,

02:26:24.180 --> 02:26:25.660
dass man

02:26:25.660 --> 02:26:28.180
dann ist man plötzlich für sich selbst verantwortlich.

02:26:28.400 --> 02:26:30.000
Also da muss man

02:26:30.000 --> 02:26:31.740
mit seinen eigenen Konsequenzen leben.

02:26:35.200 --> 02:26:36.240
Also ja, ich weiß es nicht.

02:26:36.240 --> 02:26:39.400
Es ist halt so ein bisschen die Frage,

02:26:40.000 --> 02:26:46.260
an welcher Stelle würde die Extra-Safety von Rust

02:26:46.260 --> 02:26:50.340
die gewinnbringend im Compiler?

02:26:51.200 --> 02:26:58.200
Weil das, was an einem Diff-Compiler dangerous und scary ist,

02:26:58.900 --> 02:27:02.280
ist halt nicht, dass der selber in der unsafe Sprache geschrieben ist.

02:27:02.600 --> 02:27:03.700
Das ist natürlich auch ein Problem.

02:27:03.700 --> 02:27:05.340
Und das ist nicht das primäre Problem.

02:27:05.640 --> 02:27:07.620
Das primäre Problem ist, dass man selber Maschinencode

02:27:07.620 --> 02:27:09.120
erzeugt. Und der darf halt nicht falsch sein.

02:27:10.300 --> 02:27:11.240
Aber bei diesem Problem

02:27:11.240 --> 02:27:12.800
bringt einmal Rust auch nichts.

02:27:13.220 --> 02:27:15.220
Weil Rust, dann ist der Compiler,

02:27:15.460 --> 02:27:15.960
dann ist der

02:27:15.960 --> 02:27:19.640
das Ding, in dem man den JIT-Compiler

02:27:19.640 --> 02:27:21.700
schreibt, das geht halt nicht kaputt.

02:27:21.920 --> 02:27:23.700
Beim Interpretieren deines Interpreters,

02:27:23.820 --> 02:27:25.580
der was anderes geschrieben ist. Aber wenn

02:27:25.580 --> 02:27:27.520
der falschen Code erzeugt, dann ist er immer noch schlecht.

02:27:27.960 --> 02:27:29.480
Das ist halt gewisserweise

02:27:29.480 --> 02:27:31.640
ein Logik-Bug und kein

02:27:32.420 --> 02:27:33.420
Memory-Safety-Bug.

02:27:33.700 --> 02:27:34.720
Ja, testen.

02:27:35.660 --> 02:27:36.540
Genau, es gibt, also

02:27:36.540 --> 02:27:39.220
irgendwann werde ich den Teil 2

02:27:39.220 --> 02:27:41.020
Blogpost zu How is Pinefly Tested schreiben.

02:27:41.560 --> 02:27:42.500
Der ist auch deutlich länger.

02:27:43.080 --> 02:27:45.100
How is Digit Tested? Das ist

02:27:45.100 --> 02:27:46.220
nämlich wirklich auch nochmal

02:27:46.220 --> 02:27:48.900
so ein bisschen so ein, das ist ein richtig eigenes

02:27:48.900 --> 02:27:51.060
Forschungsfeld. Und ich lerne auch immer mal

02:27:51.060 --> 02:27:53.040
wieder was dazu. Also gerade

02:27:53.040 --> 02:27:54.840
so im LFM-Bereich, da wird ja auch dann

02:27:54.840 --> 02:27:56.360
unglaublich viel Fuzzing gemacht und

02:27:56.360 --> 02:27:58.940
da werden auf interessante Art und Weise

02:27:58.940 --> 02:28:00.280
Theorienbeweise eingesetzt.

02:28:00.900 --> 02:28:02.820
Und da gibt es halt wirklich dann Forschungsgruppen, die

02:28:02.820 --> 02:28:04.820
nichts anderes machen, als sich darüber Gedanken zu machen,

02:28:04.920 --> 02:28:06.040
wie man so einen Compiler testet.

02:28:06.680 --> 02:28:08.700
Und im Herbst habe ich halt dann wirklich so eine neue Technik

02:28:08.700 --> 02:28:10.760
dann mal ausprobiert, wie man mit

02:28:10.760 --> 02:28:12.520
so einem Theorienbeweiser halt Bugs findet und

02:28:12.520 --> 02:28:14.380
ja, da haben wir halt auch dann drei

02:28:14.380 --> 02:28:16.740
JIT-Bugs gefunden. Also das war echt ganz

02:28:16.740 --> 02:28:18.760
interessant. Und da gibt es halt so

02:28:18.760 --> 02:28:20.720
einen Prof in Utah, John Regge heißt der, der schreibt

02:28:20.720 --> 02:28:21.540
da Paper drüber und

02:28:21.540 --> 02:28:24.720
nachdem ich genügend Paper von dem gelesen und

02:28:24.720 --> 02:28:26.580
mit ihm lang genug auf Twitter geschrieben hatte,

02:28:27.320 --> 02:28:28.240
habe ich dann halt

02:28:28.240 --> 02:28:30.640
mal das auch selber ausprobiert

02:28:30.640 --> 02:28:32.480
und das hat halt wirklich dann Bugs gefunden.

02:28:32.740 --> 02:28:36.840
Ja, cool.

02:28:37.880 --> 02:28:38.360
Interessant.

02:28:39.360 --> 02:28:40.580
Ja, Pai Pai.

02:28:40.960 --> 02:28:42.840
Ja, sorry, da texte ich euch zu.

02:28:43.000 --> 02:28:44.860
Nee, das ist genau,

02:28:45.020 --> 02:28:45.940
deswegen sind wir ja da.

02:28:48.060 --> 02:28:49.300
Können wir jetzt bitte endlich

02:28:49.300 --> 02:28:49.880
schlafen gehen?

02:28:51.400 --> 02:28:52.380
Nein, ist auch nicht der Messer.

02:28:53.280 --> 02:28:55.020
Naja, Reden ist halt auch Teil

02:28:55.020 --> 02:28:56.400
meines Jobs und das...

02:28:56.400 --> 02:28:58.080
Ja, ich finde das total interessant.

02:28:58.660 --> 02:28:58.960
Ja, ich auch.

02:29:00.760 --> 02:29:02.600
Ja, ich überlege nur gerade, ob wir noch

02:29:02.600 --> 02:29:04.700
irgendwo ein großes Thema vergessen haben,

02:29:04.780 --> 02:29:06.540
aber ich glaube, wir haben tatsächlich das meiste

02:29:06.540 --> 02:29:08.560
so durch. Ich habe auch das Gefühl,

02:29:08.620 --> 02:29:09.900
wir haben einen guten Rundumschlag gemacht.

02:29:10.800 --> 02:29:12.680
Ja, vielen Dank, Karl, dass du da warst.

02:29:13.120 --> 02:29:14.380
Es macht mir natürlich auch wirklich

02:29:14.380 --> 02:29:15.260
Spaß.

02:29:16.580 --> 02:29:18.480
Merkt man auch. Merkt man sofort,

02:29:18.640 --> 02:29:20.580
dass das da ganz viel

02:29:20.580 --> 02:29:22.500
Also, falls ihr mitmachen wollt,

02:29:22.560 --> 02:29:22.920
wie gesagt.

02:29:23.520 --> 02:29:26.660
Ich mache jetzt hier mal so einen allgemeinen

02:29:26.660 --> 02:29:27.760
Aufruf. Es ist

02:29:27.760 --> 02:29:30.660
Also, es gibt natürlich schon so

02:29:30.660 --> 02:29:32.480
ein paar, ich will es jetzt nicht zu schlecht

02:29:32.480 --> 02:29:34.100
reden, es gibt schon ein paar Hürden. Wir haben Python 2,

02:29:34.480 --> 02:29:35.920
wir sind in Mercurial, wir sind nicht auf GitHub,

02:29:36.160 --> 02:29:38.340
wir sind am Fork von GitLab,

02:29:38.440 --> 02:29:39.680
der auch mit Mercurial geht.

02:29:40.340 --> 02:29:42.180
Also es gibt so ein paar Nervigkeiten

02:29:42.180 --> 02:29:43.320
beim Einstieg, aber

02:29:43.320 --> 02:29:46.480
es ist in gewisser Weise

02:29:46.480 --> 02:29:47.560
halt so ein bisschen auch

02:29:47.560 --> 02:29:50.200
die netteste Python-Implementierung, bei der man

02:29:50.200 --> 02:29:52.080
einsteigen kann, weil man halt Python schreibt.

02:29:52.740 --> 02:29:54.200
Und man nimmt halt PyTest

02:29:54.200 --> 02:29:56.320
und man schreibt PyTest und man kann halt

02:29:56.320 --> 02:29:57.540
irgendwie seinen Debugger nehmen

02:29:57.540 --> 02:29:59.880
und man kann halt die ganzen Tools, die man

02:29:59.880 --> 02:30:02.280
kennt, Python 2 ist da so ein bisschen

02:30:02.280 --> 02:30:03.920
doof, aber also die ganze

02:30:03.920 --> 02:30:06.360
Arbeitsweise, die man halt kennt, wenn man sowieso schon Python kann,

02:30:06.680 --> 02:30:08.380
die kann man benutzen, um

02:30:08.380 --> 02:30:10.280
da drin rumzuhacken.

02:30:10.540 --> 02:30:12.380
Und das macht halt auch ein Stück weit einfach

02:30:12.380 --> 02:30:14.140
Spaß. Also man ist halt nicht

02:30:14.140 --> 02:30:15.840
in GDB

02:30:15.840 --> 02:30:18.260
und man hat halt kein SecFault, sondern man kriegt halt

02:30:18.260 --> 02:30:20.140
erstmal einfach einen ganz normalen Python

02:30:20.140 --> 02:30:22.540
Stacktrace, der einem sagt, in deinem Interpreter

02:30:22.540 --> 02:30:23.740
hast du jetzt hier einen Fehler gemacht.

02:30:24.120 --> 02:30:26.340
Und man schreibt halt einen Unit-Test einfach in Python,

02:30:26.560 --> 02:30:28.160
der die Datenstrukturen des Interpreters halt auch

02:30:28.160 --> 02:30:30.300
einfach testen kann. Und das ist halt

02:30:30.300 --> 02:30:32.220
auch, also ich finde das

02:30:32.220 --> 02:30:34.440
immer noch auch sehr, sehr cool.

02:30:35.160 --> 02:30:36.840
Und deswegen, ich glaube so, wenn man sich halt

02:30:36.840 --> 02:30:38.720
für das Gebiet überhaupt

02:30:38.720 --> 02:30:40.720
so ein bisschen grob interessiert, wie

02:30:40.720 --> 02:30:42.380
funktioniert eine Programmiersprache oder

02:30:42.380 --> 02:30:44.820
wie funktioniert so ein Bytecode-Interpreter oder

02:30:44.820 --> 02:30:46.720
irgendwann dann auch, wie

02:30:46.720 --> 02:30:48.680
funktioniert so ein JIT, ist das schon auch

02:30:48.680 --> 02:30:50.700
ein Projekt, wo man halt

02:30:50.700 --> 02:30:52.600
im Vergleich zu, ich lerne jetzt erstmal

02:30:52.600 --> 02:30:54.780
C++ für ein Jahr und

02:30:54.780 --> 02:30:56.500
es ist ja dann auch vielleicht in so einer

02:30:56.500 --> 02:30:57.980
virtuellen Maschine auch komisches C++,

02:30:58.980 --> 02:31:00.560
wo man dann doch auch recht leicht irgendwie

02:31:00.560 --> 02:31:02.320
reinkommen kann und

02:31:02.320 --> 02:31:03.740
ich

02:31:03.740 --> 02:31:06.500
also ich sage das auch

02:31:06.500 --> 02:31:08.700
immer mal wieder, wenn sich da halt jemand für interessiert

02:31:08.700 --> 02:31:10.560
und dann da gerne was

02:31:10.560 --> 02:31:12.460
machen möchte, ich mache da auch gerne

02:31:12.460 --> 02:31:14.160
immer Mentoring, das ist halt auch

02:31:14.160 --> 02:31:16.480
Teil meines Jobs, ich betreue halt irgendwie

02:31:16.480 --> 02:31:18.280
Studenten, die da dann auch

02:31:18.280 --> 02:31:20.360
drin arbeiten, als Teil ihrer Arbeiten, also

02:31:20.360 --> 02:31:22.000
insofern weiß ich halt dann

02:31:22.000 --> 02:31:24.460
also habe ich quasi viel Übung in Onboarding

02:31:24.460 --> 02:31:26.480
und das ist auch was,

02:31:26.560 --> 02:31:28.460
was mir Spaß macht, also wenn sich jemand jetzt für irgendwas

02:31:28.460 --> 02:31:29.820
konkret interessiert, also es gibt

02:31:29.820 --> 02:31:33.000
Themen verschiedenster Art,

02:31:33.620 --> 02:31:34.220
dann

02:31:34.220 --> 02:31:37.040
kann man sich immer gerne

02:31:37.040 --> 02:31:38.780
bei uns melden und ich

02:31:38.780 --> 02:31:40.860
zoome dann immer gerne auch mit Leuten

02:31:40.860 --> 02:31:42.040
und mache so ein bisschen Pair-Programming

02:31:42.040 --> 02:31:45.060
beim Einstieg, damit man halt einfach so ein bisschen

02:31:45.060 --> 02:31:47.220
also

02:31:47.220 --> 02:31:48.940
die erste Stunde in einem neuen Projekt

02:31:48.940 --> 02:31:51.080
ist ja immer die schlimmste. Also man weiß halt nicht,

02:31:51.360 --> 02:31:52.380
man findet halt nichts.

02:31:52.560 --> 02:31:54.900
Wo ist man da jetzt gelandet? Ja genau, was ist denn das

02:31:54.900 --> 02:31:56.840
hier für ein Ordner und wie startet das

02:31:56.840 --> 02:31:58.920
eigentlich? Wo kriege ich eigentlich das Python 2 her,

02:31:58.980 --> 02:32:00.360
was ich brauche. Und wo geht es mit deinem Essen?

02:32:00.700 --> 02:32:02.960
Genau, ja. Und das ist halt, also da

02:32:02.960 --> 02:32:04.140
versuche ich halt dann immer auf jeden Fall

02:32:04.140 --> 02:32:06.060
deutlich den Leuten halt auch zu helfen.

02:32:07.240 --> 02:32:08.820
Und das ist auch was, was mir wirklich

02:32:08.820 --> 02:32:10.860
Spaß macht. Also meldet euch

02:32:10.860 --> 02:32:11.200
und

02:32:11.200 --> 02:32:13.280
ja.

02:32:14.640 --> 02:32:16.900
Ja, klingt auf jeden Fall sehr gut. Ja, vielen Dank.

02:32:17.600 --> 02:32:18.780
Ja, wollen wir vielleicht noch

02:32:18.780 --> 02:32:20.680
Pics machen? Möchtest du Pics machen? Ich hatte

02:32:20.680 --> 02:32:21.860
jetzt nur einen kleinen,

02:32:22.140 --> 02:32:24.700
der gar nichts mit sonst wie

02:32:24.700 --> 02:32:26.860
Dingen zu tun hat, über die wir gerade geredet haben.

02:32:27.200 --> 02:32:28.660
Dann lassen wir es weiter. Dann lassen wir es weg.

02:32:28.800 --> 02:32:30.780
Okay, alles klar. Gut. Ja, dann vielen Dank,

02:32:30.840 --> 02:32:31.880
dass ihr eingeschaltet habt. Ja.

02:32:32.320 --> 02:32:34.420
Schaltet wieder ein. Sehr interessant diesmal.

02:32:34.700 --> 02:32:36.220
Danke, dass ihr dabei wart. Vielen Dank für die Einladung.

02:32:36.540 --> 02:32:38.080
Ja, danke. Bye. Okay.

02:32:38.380 --> 02:32:40.120
Bis zum nächsten Mal. Tschüss, bis dann.