WEBVTT 00:00:00.000 --> 00:00:04.600 Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Paisen-Podcast. Heute Jubiläumsepisode 60. 00:00:05.440 --> 00:00:05.840 Hi Jochen. 00:00:05.880 --> 00:00:10.520 Oh, Jubiläum. Herzlichen Glückwunsch und auch herzlich willkommen Dominik. 00:00:10.520 --> 00:00:12.400 Ja, hey. Auch unsere Gäste. 00:00:12.900 --> 00:00:15.160 Genau, ja, beziehungsweise... 00:00:15.160 --> 00:00:16.100 Lieber Johannes, dich kennt man von. 00:00:16.200 --> 00:00:16.480 Ja, genau. 00:00:16.800 --> 00:00:19.700 Hallo zusammen und herzlichen Glückwunsch zur 60. Episode. 00:00:19.940 --> 00:00:21.900 Danke. Und lieber TF, auch dir. 00:00:22.500 --> 00:00:23.660 Ja, vielen Dank, hallo. 00:00:24.200 --> 00:00:26.580 Du warst ja auch schon mal da, habe ich noch in Erinnerung. 00:00:26.880 --> 00:00:29.320 Genau, Januar 23 haben wir gerade rekonstruiert. 00:00:29.320 --> 00:00:38.140 Ja, wir sprechen heute über Python 3.13. Und ich würde sagen, da legen wir auch direkt los. 00:00:39.400 --> 00:00:41.640 Ja, wollen wir noch News machen oder nicht? 00:00:41.720 --> 00:00:42.700 Ich wollte gerade sagen, mit den News. 00:00:45.500 --> 00:00:54.500 Genau, das ist natürlich irgendwie schon ein bisschen her. Wir sind ein bisschen spät dran. Aber es ist vielleicht auch noch interessant. Es gibt ein paar schöne Sachen, die man darüber erzählen kann, oder? 00:00:55.840 --> 00:00:57.400 Ja, also wollen wir direkt 00:00:57.400 --> 00:00:59.400 Python-Reihe 13 kommen wir auch direkt. 00:00:59.620 --> 00:01:00.840 War gar nicht so viel los, oder? 00:01:01.060 --> 00:01:02.260 Nee, sonst war auch nicht so viel los, stimmt. 00:01:02.680 --> 00:01:03.800 Dann machen wir das doch direkt, ja. 00:01:04.400 --> 00:01:05.500 Also ja, dann erzähl uns was. 00:01:07.720 --> 00:01:09.160 Ich hab's jetzt auch schon überall 00:01:09.160 --> 00:01:11.040 irgendwie installiert, wo ich irgendwie 00:01:11.040 --> 00:01:12.860 Projekte angefasst habe und es funktioniert super. 00:01:13.860 --> 00:01:14.200 Und 00:01:14.200 --> 00:01:17.000 genau, ja, jetzt 00:01:17.000 --> 00:01:18.760 haben wir da so einige Dinge. 00:01:19.080 --> 00:01:20.700 Vielleicht fangen wir einfach tatsächlich mit der 00:01:20.700 --> 00:01:22.240 neuen REPL an. 00:01:23.280 --> 00:01:25.200 Irgendwie die halt aus dem 00:01:25.200 --> 00:01:26.620 Pile-Pile-Projekt 00:01:26.620 --> 00:01:28.480 übernommen wurde. 00:01:28.880 --> 00:01:29.540 Mit der neuen REPL. 00:01:30.000 --> 00:01:30.980 Was ist eine REPL? 00:01:32.540 --> 00:01:34.760 Ja, so eine Read-Eval-Print-Loop. 00:01:35.300 --> 00:01:36.900 Irgendwie das, was man bekommt, wenn man 00:01:36.900 --> 00:01:38.380 einfach nur Python eingibt und unterdrückt. 00:01:38.520 --> 00:01:40.540 Also nutzt ihr schon 3.13? Alle? 00:01:40.980 --> 00:01:41.360 Außer Jochen? 00:01:41.680 --> 00:01:43.040 Nee, ich habe es noch nicht installiert. 00:01:43.080 --> 00:01:44.760 Ich nutze es nicht, ich nutze aber die neue REPL. 00:01:45.200 --> 00:01:47.360 Ah, das ist natürlich ein 00:01:47.360 --> 00:01:49.160 Spezialeinheit. Ja gut, ich benutze IPython überall. 00:01:50.240 --> 00:01:51.220 Warum nicht Bipython? 00:01:51.400 --> 00:01:52.520 Das hatten wir vorhin 00:01:52.520 --> 00:01:55.260 vorgespräch schon mal kurz besprochen. 00:01:55.580 --> 00:01:57.320 Also ich fand die Begründung interessant, warum sie 00:01:57.320 --> 00:01:59.320 eigentlich überhaupt die REPL verbessern, wenn sie 00:01:59.320 --> 00:02:01.320 sowieso ja wissen, dass die meisten 00:02:01.320 --> 00:02:03.120 Leute halt sich sowieso als erstes erstmal IPython 00:02:03.120 --> 00:02:05.300 installieren, weil das halt 00:02:05.300 --> 00:02:07.220 viel viel netter ist. Aber der 00:02:07.220 --> 00:02:08.780 Grund scheint zu sein, dass die 00:02:08.780 --> 00:02:10.700 CPython Core Devs halt 00:02:10.700 --> 00:02:13.300 während sie quasi dann die nächste 00:02:13.300 --> 00:02:14.580 Version entwickeln, erstmal 00:02:14.580 --> 00:02:17.320 geht PyPI nicht und 00:02:17.320 --> 00:02:18.240 pip nicht und 00:02:18.240 --> 00:02:21.140 IPython geht vielleicht auch nicht auf der neuen Version und 00:02:21.140 --> 00:02:23.260 damit sie es quasi beim Entwickeln etwas netter haben, 00:02:23.840 --> 00:02:28.800 haben sie sich quasi den schöneren Multi-Line-Edit, 00:02:28.980 --> 00:02:32.260 schönere History-Farben-Rapple implementiert, 00:02:32.320 --> 00:02:33.400 der jetzt in 3.13 released wird. 00:02:33.420 --> 00:02:35.320 Also ich finde es auch toll, weil ich bin ja zu faul für iPython 00:02:35.320 --> 00:02:36.740 und ich mache das eigentlich sonst immer klassisch. 00:02:37.000 --> 00:02:39.100 Und toll, endlich, bunt. 00:02:39.460 --> 00:02:41.920 Die Welt verbessert durch Eigennutzer, also Sauerei. 00:02:43.460 --> 00:02:45.880 Ja, also das mit den Farben finde ich relativ abgefahren tatsächlich. 00:02:46.040 --> 00:02:48.600 Also ich habe jetzt seit, weiß ich nicht, Oktober 00:02:48.600 --> 00:02:49.860 jetzt auch den Farbing-Rapple. 00:02:50.320 --> 00:02:51.860 Und wenn ich dann aber eine alte Version benutze 00:02:51.860 --> 00:02:53.700 und es ist dann plötzlich nur noch schwarz-weiß 00:02:53.700 --> 00:02:55.620 und es ist ja gar nicht so viel Farbe, 00:02:55.700 --> 00:02:58.360 es sind ja wirklich nur die größer als Zeichen, 00:02:58.800 --> 00:03:00.700 aber das kommt einem dann fast schon altbacken vor. 00:03:01.100 --> 00:03:03.280 Ja, Back to the Future, das ist schon ein bisschen wie damals. 00:03:05.020 --> 00:03:06.920 Aber schade, dass es nicht früher noch grün war oder so, 00:03:06.960 --> 00:03:08.180 aber ein echter Hacker und so. 00:03:08.360 --> 00:03:11.360 Ja, die Farbauswahl, die die C-Python-Entwickler getroffen haben, 00:03:12.100 --> 00:03:13.540 das war ein riesen Diskussionsthema. 00:03:14.040 --> 00:03:15.200 Das ist halt so Bike-Shedding-mäßig. 00:03:15.540 --> 00:03:17.480 Also da kann man halt gut drüber diskutieren. 00:03:18.020 --> 00:03:20.860 Und das Problem ist, dass man halt aus der Shell raus 00:03:20.860 --> 00:03:24.060 nicht rausfinden kann, ob die Shell auf schwarz auf weiß 00:03:24.060 --> 00:03:25.580 oder weiß auf schwarz eingestellt ist. 00:03:25.980 --> 00:03:30.860 Das heißt, man muss Farben wählen, die bei beiden Hintergrundfarben 00:03:30.860 --> 00:03:35.740 quasi noch einen einigermaßen brauchbaren Kontrast dann ergeben. 00:03:35.740 --> 00:03:39.840 Und deswegen ist dieses Pink und Rot ein bisschen so ein Kompromiss, 00:03:39.940 --> 00:03:41.980 weil das halt sowohl auf dem schwarzen Hintergrund 00:03:41.980 --> 00:03:45.320 als auch auf dem weißen Hintergrund noch einigermaßen gut lesbar bleibt. 00:03:46.680 --> 00:03:47.760 Ach okay, interessant. 00:03:48.020 --> 00:03:50.180 Ja, aber 00:03:50.180 --> 00:03:51.480 genau, 00:03:52.360 --> 00:03:54.880 wie kommt das denn, dass du 00:03:54.880 --> 00:03:57.060 die REPL schon verwendet 00:03:57.060 --> 00:03:58.780 hast, obwohl gar nicht... 00:03:58.780 --> 00:04:00.640 Ja, also die REPL ist 00:04:00.640 --> 00:04:03.060 das ist quasi die PyPy REPL 00:04:03.060 --> 00:04:04.900 nicht ganz, also die haben total viele neue Features 00:04:04.900 --> 00:04:06.800 eingebaut und Bugs gefixt und so, aber so 00:04:06.800 --> 00:04:08.860 dieses Kernfeature, dass es eben 00:04:08.860 --> 00:04:11.000 Multiline Edit 00:04:11.000 --> 00:04:11.640 gibt, also 00:04:11.640 --> 00:04:14.560 vielleicht können wir auch kurz sagen, was das ist, also 00:04:14.560 --> 00:04:16.720 wenn man quasi auf der Python 00:04:16.720 --> 00:04:18.820 Shell eine Funktion angibt, die halt über mehrere Zeilen 00:04:18.820 --> 00:04:20.740 geht und man macht dann irgendwie so einen Tippfehler 00:04:20.740 --> 00:04:22.440 in Zeile 2 von 8, 00:04:23.040 --> 00:04:24.740 dann musste man bisher halt quasi dann 00:04:24.740 --> 00:04:26.620 mit der History Zeile für Zeile in der richtigen 00:04:26.620 --> 00:04:28.620 Reihenfolge dann 00:04:28.620 --> 00:04:30.580 die Funktion wieder so neu zusammensetzen, die 00:04:30.580 --> 00:04:32.580 entsprechende kaputte Zeile dann reparieren 00:04:32.580 --> 00:04:34.860 und dann die anderen wieder über die History holen 00:04:34.860 --> 00:04:36.760 und das ist halt total nervig. Und deswegen 00:04:36.760 --> 00:04:37.640 gibt es jetzt eben 00:04:37.640 --> 00:04:40.280 Multiline Edit und PyPi hatte das, 00:04:40.420 --> 00:04:42.680 wie ich gerade schon gesagt habe, schon quasi schon immer, 00:04:42.840 --> 00:04:44.340 also in Anführungszeichen, also 00:04:44.340 --> 00:04:46.480 seit PyPi 2.4 oder 00:04:46.480 --> 00:04:48.660 2.5 oder so hatten wir das, dass man halt 00:04:48.660 --> 00:04:50.140 quasi, wenn man nach einer Funktion 00:04:50.140 --> 00:04:52.640 Pfeil nach oben drückt, dann kriegt man halt die ganze Funktion über 00:04:52.640 --> 00:04:54.640 mehrere Zeilen. Man kann dann auch wie in einem Editor 00:04:54.640 --> 00:04:56.540 mit Pfeil nach oben dann in die früheren Zeilen 00:04:56.540 --> 00:04:58.540 der Funktion, kann das einfach editieren, geht 00:04:58.540 --> 00:04:59.940 dann wieder ans Ende und mit Enter 00:04:59.940 --> 00:05:02.240 definiert man dann die Funktion neu. 00:05:02.940 --> 00:05:04.700 Und das hat ja halt, sagen wir mal, 00:05:04.700 --> 00:05:06.300 zwei der frühen 00:05:06.300 --> 00:05:08.560 Piper-Entwickler einfach so als 00:05:08.560 --> 00:05:10.480 in Anführungszeichen normalen Python-Code geschrieben. Das war 00:05:10.480 --> 00:05:12.620 einfach, also das hat eigentlich 00:05:12.620 --> 00:05:14.600 keine Piper-spezifischen Features irgendwie 00:05:14.600 --> 00:05:16.880 gebraucht. Michael Hudson, 00:05:17.160 --> 00:05:18.560 Doyle und Armin Rigo waren das. 00:05:19.260 --> 00:05:19.580 Und 00:05:19.580 --> 00:05:22.620 so ungefähr von einem Jahr haben halt zwei 00:05:22.620 --> 00:05:24.680 der C-Python-Entwickler, Luca Schlanger 00:05:24.680 --> 00:05:26.780 und Galindo Salgado 00:05:26.780 --> 00:05:28.440 gesagt, dass sie das auch gern für C-Python hätten. 00:05:29.080 --> 00:05:30.160 Beziehungsweise die haben halt versucht, 00:05:30.680 --> 00:05:32.740 sich zu überlegen, wie sie den Ripple verbessern können. 00:05:32.820 --> 00:05:34.620 Der Ripple war bisher in C-Python NC geschrieben 00:05:34.620 --> 00:05:36.540 und das macht halt alle Verbesserungen daran 00:05:36.540 --> 00:05:37.980 relativ nervig und aufwendig. 00:05:38.380 --> 00:05:40.580 Und dann haben sie halt geguckt, woher man vielleicht Python-Code 00:05:40.580 --> 00:05:42.560 nehmen könnte, der irgendwie 00:05:42.560 --> 00:05:44.520 einen Teil des Problems schon löst, ohne dann alles nochmal 00:05:44.520 --> 00:05:46.620 neu machen zu müssen und dann habe ich 00:05:46.620 --> 00:05:48.520 halt gesagt, dass sie vielleicht sich mal 00:05:48.520 --> 00:05:50.380 anschauen könnten, was PyPy da hat und dann haben sie das eben 00:05:50.380 --> 00:05:51.520 übernommen, angepasst, 00:05:52.240 --> 00:05:54.540 den Code auch total verbessert, 00:05:54.600 --> 00:05:56.240 weil in PyPy ist der auch immer noch 00:05:56.240 --> 00:05:57.920 Python 2 kompatibel, 00:05:58.380 --> 00:06:00.160 weil wir auch immer noch Python 2 Versionen releasen 00:06:00.160 --> 00:06:02.080 und 00:06:02.080 --> 00:06:04.060 also das haben die quasi so ein bisschen 00:06:04.060 --> 00:06:06.120 Grund überholt und neue Tests geschrieben und so 00:06:06.120 --> 00:06:08.120 und eben auch einiges an neuen Featuren 00:06:08.120 --> 00:06:08.880 hinzugefügt, also 00:06:08.880 --> 00:06:12.020 ich habe ein paar Notizen dazu gemacht, also einmal 00:06:12.020 --> 00:06:13.120 die Farben, die haben wir nicht gehabt, 00:06:14.360 --> 00:06:31.200 Dann diesen Paste-Mode, den es jetzt gibt, also wenn man quasi aus der Zwischenablage irgendwie mehrere Zeilen Code einfügt, dann geht ja oft die Einrückung kaputt und das ist jetzt eben auch repariert. Auch Support für Windows hatten wir bisher auch nicht und halt die Farben. 00:06:32.540 --> 00:06:33.800 Was ich tatsächlich auch nicht kannte, 00:06:33.900 --> 00:06:35.860 war, dass man einfach so ein Skript reinfügen 00:06:35.860 --> 00:06:37.780 kann. Ich habe gehört, dass das schon ein bisschen älter ist. Ich weiß aber nicht, 00:06:37.840 --> 00:06:39.700 bei welcher Version das reingekommen ist. Man kann 00:06:39.700 --> 00:06:41.620 eine Environment-Variable setzen und dann 00:06:41.620 --> 00:06:43.580 wird ein Skript ausgefügt. Das heißt, du hast deine 00:06:43.580 --> 00:06:45.760 Imports, die du immer machst, direkt 00:06:45.760 --> 00:06:47.160 mit dabei, wenn du zum Beispiel diese 00:06:47.160 --> 00:06:49.900 setzt. Deine Lieblingsmodule? 00:06:50.300 --> 00:06:51.480 Ja, nur sieben. 00:06:51.680 --> 00:06:52.000 Sieben? 00:06:53.520 --> 00:06:55.460 Finde ich ziemlich cool. Man kann dann lustige Sachen machen. 00:06:55.600 --> 00:06:56.780 Python Starter heißt das. 00:06:57.820 --> 00:06:59.500 Ja. Ja, ist ja 00:06:59.500 --> 00:07:01.560 sehr schön. Muss ich unbedingt für 00:07:01.560 --> 00:07:02.440 mein System auch bauen. 00:07:03.580 --> 00:07:04.880 Ja, aber genau, also 00:07:04.880 --> 00:07:07.580 ein großer Vorteil ist glaube ich auch jetzt, 00:07:07.720 --> 00:07:09.440 dass es war vorher irgendwie 00:07:09.440 --> 00:07:11.500 direkt in C, glaube ich, geschrieben 00:07:11.500 --> 00:07:12.920 und jetzt ist es halt auch 00:07:12.920 --> 00:07:15.660 Pure Python sozusagen und ich glaube, da kann man 00:07:15.660 --> 00:07:17.120 jetzt auch einfach eine ganze Menge mehr 00:07:17.120 --> 00:07:19.540 an die Innereien rankommen und dann auch das Verhalten so 00:07:19.540 --> 00:07:21.660 ändern, dass man da eine ganze Menge lustige 00:07:21.660 --> 00:07:22.940 Dinge mit tun kann. 00:07:24.100 --> 00:07:25.160 Lukas Schlager hatte da auf der 00:07:25.160 --> 00:07:27.220 Pure Python auch einen Vortrag gehalten. 00:07:27.660 --> 00:07:29.100 Das war ein Performance-Vortrag. 00:07:29.480 --> 00:07:31.640 Oder eine Performance performt. 00:07:33.220 --> 00:07:35.640 Live-Musik-Coding-Geschichten. 00:07:36.000 --> 00:07:37.720 Und da ist es natürlich praktisch, wenn man halt... 00:07:37.720 --> 00:07:39.100 Lustig war, dass der Tontechniker, 00:07:39.180 --> 00:07:40.420 der hat einen Euroreg dabei gehabt 00:07:40.420 --> 00:07:42.680 und hat irgendwie so einen hohen Ton auf seinem Synthesizer gespielt. 00:07:43.080 --> 00:07:44.840 Da hat der Tontechniker kurz Angst bekommen, 00:07:44.940 --> 00:07:45.880 dass seine Anlage Schrott geht. 00:07:45.960 --> 00:07:49.040 Hat alles runtergedreht auf so 20% Lautstärke oder sowas. 00:07:49.040 --> 00:07:51.080 Und auf einmal war es sehr leise. 00:07:52.060 --> 00:07:53.740 Und dann hat er fünf Minuten so gespielt. 00:07:53.840 --> 00:07:55.660 Und irgendwann hat jemand geklopft beim Tontechniker 00:07:55.660 --> 00:07:56.560 und hat dann überredet und gesagt, 00:07:56.620 --> 00:07:58.700 ja, Lukas, wird diese hohen Frequenzen 00:07:58.700 --> 00:08:00.920 jetzt nicht mehr spielen? Und dann durfte er wieder lauter drehen. 00:08:01.400 --> 00:08:01.780 Ja, ich glaube, 00:08:01.940 --> 00:08:04.500 das sieht man auch jetzt schon so ein bisschen. Es gibt halt einfach 00:08:04.500 --> 00:08:06.700 viel mehr Bug Reports und Patches, was den neuen Rappel angeht. 00:08:07.500 --> 00:08:08.640 Es ist immer noch so, dass es schon 00:08:08.640 --> 00:08:10.460 so ein bisschen nervig ist, daran zu arbeiten, weil 00:08:10.460 --> 00:08:12.480 wenn der Rappel kaputt ist, dann sieht man halt auch gleich 00:08:12.480 --> 00:08:14.660 nichts mehr. Also der Debugger geht nicht 00:08:14.660 --> 00:08:15.740 und also es ist schon, 00:08:16.520 --> 00:08:18.100 die haben da schon 00:08:18.100 --> 00:08:20.580 so ein bisschen eigene debugging-Sachen eingebaut. 00:08:21.780 --> 00:08:22.700 Aber es ist schon 00:08:22.700 --> 00:08:24.360 noch so, es bleibt so ein bisschen frickelig. 00:08:24.400 --> 00:08:26.320 Aber ich glaube, man kann auch die alte wieder aktivieren. 00:08:26.620 --> 00:08:29.980 Irgendwie insofern hat man da vielleicht die Möglichkeit, 00:08:30.260 --> 00:08:32.620 auch mit der Umgebungsvariable wieder auf die alten Dings zu kommen. 00:08:32.720 --> 00:08:34.340 Aber ja, klar, ist natürlich, wenn man es kaputt macht, 00:08:34.580 --> 00:08:35.640 dann ein Problem. 00:08:37.820 --> 00:08:39.460 Ah ja, wichtiges anderes neue Feature ist natürlich, 00:08:39.520 --> 00:08:41.520 dass man jetzt bei Exit keine Klammern mehr braucht. 00:08:41.860 --> 00:08:42.140 Oh ja. 00:08:42.780 --> 00:08:43.720 Ja, und ich glaube, Quid geht auch. 00:08:44.260 --> 00:08:45.100 Ja, vielleicht ist das so. 00:08:45.380 --> 00:08:46.520 Ich meine, ja. 00:08:47.220 --> 00:08:50.860 Ja, und Help geht auch irgendwie jetzt anders. 00:08:51.380 --> 00:08:53.240 Aber ehrlich gesagt, keine Ahnung genau, wie. 00:08:53.260 --> 00:08:55.280 Ja, es gibt jetzt diesen Help-Mode, der eingebaut ist mit F1. 00:08:55.460 --> 00:08:57.660 Und dann kann man quasi aus der 00:08:57.660 --> 00:08:59.460 Shell in so eine spezielle Help-Shell 00:08:59.460 --> 00:09:00.820 wechseln. Und von da dann, 00:09:01.520 --> 00:09:03.600 wenn man quasi die Namen von irgendwelchen Sachen, die man 00:09:03.600 --> 00:09:05.540 dokumentiert haben möchte, eingibt, dann kriegt man die 00:09:05.540 --> 00:09:06.240 direkt angezeigt. 00:09:07.080 --> 00:09:09.060 Aber bei Print braucht man schon noch Klammern, oder? 00:09:09.440 --> 00:09:09.660 Nee. 00:09:11.660 --> 00:09:13.700 Ich möchte so etwas 00:09:13.700 --> 00:09:14.660 Python 2 wieder haben. 00:09:16.180 --> 00:09:17.620 Soll ich das mal als Feature-Request 00:09:17.620 --> 00:09:18.900 vorschlagen? Also das kannst du jetzt auf jeden Fall 00:09:18.900 --> 00:09:20.040 für deine 00:09:20.040 --> 00:09:22.220 Raffle-Katze einbauen, dass sie sich dann wieder 00:09:22.220 --> 00:09:23.260 in Python 2... Kann ich das machen? 00:09:23.440 --> 00:09:26.520 Das mit dem Exit ist tatsächlich was, 00:09:26.520 --> 00:09:28.620 was halt Newbies sich relativ 00:09:28.620 --> 00:09:29.140 oft wünschen. 00:09:31.080 --> 00:09:32.300 Q reicht, glaube ich, auch. 00:09:33.960 --> 00:09:34.620 Ist das so? 00:09:34.960 --> 00:09:36.160 Q reicht? Nee. 00:09:36.820 --> 00:09:37.800 Warum steht denn das da? 00:09:38.620 --> 00:09:39.860 Weiß nicht. Ach, für den Head-Mode. 00:09:40.560 --> 00:09:42.100 Also Crit geht, aber 00:09:42.100 --> 00:09:44.020 Q nicht. Schade. 00:09:46.200 --> 00:09:48.380 Adidas QQ, da muss man direkt wieder in das 00:09:48.380 --> 00:09:49.000 Skript reinschreiben. 00:09:50.140 --> 00:09:52.420 Ja, aber so ist es auf jeden Fall 00:09:52.420 --> 00:09:54.400 toll. Also ich finde das auch super, dass man da jetzt 00:09:54.400 --> 00:09:55.920 irgendwie echt 00:09:55.920 --> 00:09:58.560 eine ganz brauchbare Geschichte eingebaut hat 00:09:58.560 --> 00:10:00.500 und gut, klar, also iPython 00:10:00.500 --> 00:10:02.540 ist natürlich auch nicht schlecht oder wie Python 00:10:02.540 --> 00:10:04.460 oder so, aber. Ja und dann 00:10:04.460 --> 00:10:06.440 daran angelegt, wir haben jetzt Farben ja schon angesprochen, vielleicht können wir noch 00:10:06.440 --> 00:10:07.720 über die Tracebacks sprechen. 00:10:08.720 --> 00:10:09.780 Also in 3.11 00:10:09.780 --> 00:10:12.260 gab es ja jetzt schon die Verbesserung, dass wir quasi 00:10:12.260 --> 00:10:14.320 in Tracebacks diese 00:10:14.320 --> 00:10:16.360 genaueren Positionen innerhalb 00:10:16.360 --> 00:10:18.240 von der Zeile kriegen. Wie sagt man, Dechle, Johannes? 00:10:18.700 --> 00:10:20.340 Genau. Dechle, ja. 00:10:20.600 --> 00:10:22.060 Da, wo ich herkomme, sagt man Dechle. 00:10:22.420 --> 00:10:24.520 Sind halt auch keine Dächer, sondern nur kleine 00:10:24.520 --> 00:10:25.660 Dächer. So groß sind die gar nicht. 00:10:26.080 --> 00:10:26.700 Ist halt so. 00:10:29.160 --> 00:10:30.480 Genau, also es wird 00:10:30.480 --> 00:10:32.340 jetzt quasi nicht mehr nur gesagt, das ist halt in Zeile 00:10:32.340 --> 00:10:34.480 5 der Fehler, sondern auch noch dieser Teil 00:10:34.480 --> 00:10:36.100 des Ausdrucks ist 00:10:36.100 --> 00:10:38.380 der Teil, der die Exception hervorgerufen hat. 00:10:39.680 --> 00:10:40.360 Und das 00:10:40.360 --> 00:10:42.380 wird jetzt halt auch noch jetzt dann 00:10:42.380 --> 00:10:44.460 farbig irgendwie anders dargestellt als der Rest der Zeile. 00:10:45.100 --> 00:10:45.780 Ja, auch sehr nützlich. 00:10:47.280 --> 00:10:48.460 Tatsächlich so ein bisschen readable 00:10:48.460 --> 00:10:50.260 und man muss sich 00:10:50.260 --> 00:10:52.100 erstmal gucken, wo ist denn jetzt der richtige Teil 00:10:52.100 --> 00:10:52.840 vom Traceback, sondern 00:10:52.840 --> 00:10:55.220 mit den Positionen, da 00:10:55.220 --> 00:10:57.960 habe ich, das Feature habe ich 00:10:57.960 --> 00:11:00.140 quasi durch einen geschickten 00:11:00.140 --> 00:11:01.480 Tweet provoziert. 00:11:01.980 --> 00:11:03.920 Da habe ich nämlich einen Screenshot 00:11:03.920 --> 00:11:05.960 gefälscht, wo wir, also den hat 00:11:05.960 --> 00:11:07.800 es nie, das Feature hat es bei uns nicht gegeben, 00:11:08.320 --> 00:11:10.100 aber ich habe quasi einen fiktiven Traceback 00:11:10.100 --> 00:11:11.600 auf Twitter fingiert 00:11:11.600 --> 00:11:13.760 und das hat dann dazu geführt, dass 00:11:13.760 --> 00:11:15.700 C-Python das wirklich entwickelt hat. 00:11:15.920 --> 00:11:16.340 Das fand ich 00:11:16.340 --> 00:11:20.160 großartig. 00:11:20.780 --> 00:11:21.720 Feature-Request durch 00:11:21.720 --> 00:11:22.480 Boßartigkeit. 00:11:23.480 --> 00:11:27.380 Also wir können das und ihr? 00:11:28.680 --> 00:11:29.980 Und dann gelogen. 00:11:30.120 --> 00:11:31.800 Also ich hatte schon so einen Plan, wie ich das irgendwann mal, 00:11:31.820 --> 00:11:32.840 wir haben das ja dann auch irgendwann 00:11:32.840 --> 00:11:35.740 gekriegt, aber so und T-Python hat uns dann 00:11:35.740 --> 00:11:37.620 halt einfach ganz schnell überholt und viel mehr Leute benutzen 00:11:37.620 --> 00:11:38.040 T-Python. 00:11:40.040 --> 00:11:40.440 Ja. 00:11:41.900 --> 00:11:43.240 Genau, hier kann man es auch nochmal sehen. 00:11:43.640 --> 00:11:45.260 Jetzt natürlich nicht, wenn ihr zuhört, aber 00:11:45.260 --> 00:11:47.700 genau. Ich kann es jetzt sehen. 00:11:48.040 --> 00:11:48.980 Das einzige, was zählt. 00:11:50.280 --> 00:11:50.760 Ja, ja. 00:11:51.720 --> 00:12:10.940 Genau. Ja, auch schön, man kriegt jetzt irgendwie gesagt, wenn man halt ein Modul genauso genannt hat wie eines aus der Standardbibliothek oder von sonstigen Dingen, die man installiert hat, glaube ich, also es gibt so ein bisschen bessere. 00:12:10.940 --> 00:12:13.460 Oder wenn man halt irgendwie bei Keyword-Argumenten 00:12:13.460 --> 00:12:14.740 das irgendwie falsch übergeben hat, 00:12:15.120 --> 00:12:17.060 dann kriegt man jetzt auch, da gab es vorher einfach nur 00:12:17.060 --> 00:12:18.620 so sehr, sehr kryptische Fehlermeldungen, 00:12:18.760 --> 00:12:20.840 die halt Anfänger auch sehr verunsichert haben. 00:12:20.940 --> 00:12:22.120 Das ist jetzt, glaube ich, auch besser. 00:12:22.220 --> 00:12:24.820 Er macht das Vorschlag, er versucht sich dran zu erinnern, 00:12:24.900 --> 00:12:26.040 was denn der Fehler schon sein könnte 00:12:26.040 --> 00:12:27.440 und versucht so einen kleinen Hinweis dazu zu geben. 00:12:28.040 --> 00:12:31.160 Ich meine, das wird halt in jeder Version 00:12:31.160 --> 00:12:32.860 jetzt gerade so ein bisschen verbessert. 00:12:32.960 --> 00:12:35.040 Es ist schon so ein, jetzt über einige Versionen 00:12:35.040 --> 00:12:37.780 eigentlich so ein festes Bestandteil 00:12:37.780 --> 00:12:38.860 von jedem C-Python-Release, 00:12:38.940 --> 00:12:40.800 dass sie halt sich echt Mühe geben, 00:12:40.920 --> 00:12:42.960 noch so ein paar der schlechten Fehlermeldungen zu verbessern. 00:12:43.820 --> 00:12:47.120 Und ich unterrichte halt Python-Anfänger jedes Semester. 00:12:47.720 --> 00:12:49.020 Das macht schon echt einen Unterschied, 00:12:49.180 --> 00:12:51.800 ob da dann irgendwie halt Abkürzungen vorkommen, 00:12:51.860 --> 00:12:52.720 die wir noch nie gehört haben 00:12:52.720 --> 00:12:56.740 oder einfach nur Syntax-Error ohne irgendwas anderes steht 00:12:56.740 --> 00:12:58.520 und wir so ein bisschen raten müssen, 00:12:58.600 --> 00:13:00.040 was das Problem gewesen sein könnte. 00:13:01.280 --> 00:13:02.900 Und ja, und das mit den Vorschlägen, 00:13:03.060 --> 00:13:03.860 also wenn man sich halt vertippt, 00:13:03.920 --> 00:13:04.940 wenn man irgendwie einen Namen vertippt, 00:13:05.440 --> 00:13:06.800 das ist jetzt schon seit ein, zwei Versionen, 00:13:06.880 --> 00:13:08.720 dass sie dann da dann Vorschläge 00:13:08.720 --> 00:13:11.020 machen könnten, was halt der existierende 00:13:11.020 --> 00:13:12.720 Name mit der kleinsten Edit-Distance ist. 00:13:13.740 --> 00:13:14.620 Und jetzt 00:13:14.620 --> 00:13:16.680 haben sie es eben noch zusätzlich hinzugefügt, dass es auch bei 00:13:16.680 --> 00:13:17.480 Keyword-Argumenten geht. 00:13:18.640 --> 00:13:19.140 Ah, okay. 00:13:21.020 --> 00:13:21.460 Ja. 00:13:22.180 --> 00:13:24.680 Also das ist auf jeden Fall vielleicht die 00:13:24.680 --> 00:13:27.200 größte User-Facing-Änderung, 00:13:27.360 --> 00:13:28.540 die man halt bekommt, wenn man 00:13:28.540 --> 00:13:30.660 jetzt Python 3.13 verwendet. 00:13:31.800 --> 00:13:31.960 Ja. 00:13:32.880 --> 00:13:34.480 Ja, ich würde auch sagen, wenn die ganzen Bibliotheken 00:13:34.480 --> 00:13:36.580 umgezogen sind, die man sonst nur nutzt, dann direkt 00:13:36.880 --> 00:13:38.740 kann nicht mehr so lange dauern. 00:13:39.320 --> 00:13:41.060 Wann zieht ihr denn immer um, bei der 3.1 00:13:41.060 --> 00:13:43.320 oder bei der Punkt 1 oder Punkt 2? 00:13:43.520 --> 00:13:45.400 Ich stelle eigentlich immer sobald, 00:13:45.980 --> 00:13:47.180 ich probiere es vorher schon aus, 00:13:47.340 --> 00:13:49.220 also einfach deswegen, um zu sehen, ob ich halt irgendwie 00:13:49.220 --> 00:13:50.840 bei den Paketen, die ich 00:13:50.840 --> 00:13:53.500 habe 00:13:53.500 --> 00:13:55.260 oder die ich maintaine, ob da nicht 00:13:55.260 --> 00:13:57.140 dann Dinge kaputt gehen, weil um mir dann halt, 00:13:57.140 --> 00:13:58.180 damit ich den Ärger nicht 00:13:58.180 --> 00:14:01.160 nach der Release kriege, gucke ich 00:14:01.160 --> 00:14:03.000 das halt vor. Also du bist dann einer von denen, die dann die 00:14:03.000 --> 00:14:04.580 Bug-Reports machen, wenn was nicht geht. 00:14:05.040 --> 00:14:07.140 Ja, aber meistens 00:14:07.140 --> 00:14:09.120 ist das halt so abstrakt, dass 00:14:09.120 --> 00:14:11.340 ich da gar nicht in Bugs reinlaufe. 00:14:12.500 --> 00:14:13.180 Also bisher, 00:14:13.400 --> 00:14:14.840 wo ich es probiert habe, hat es eigentlich immer funktioniert. 00:14:16.240 --> 00:14:17.000 Und dann 00:14:17.000 --> 00:14:18.420 updaten, 00:14:18.980 --> 00:14:21.140 das mache ich dann normalerweise, wenn es tatsächlich 00:14:21.140 --> 00:14:23.120 dann erscheint. Ja, aber der Rest der Software, 00:14:23.500 --> 00:14:25.020 den hast du ja noch nicht 00:14:25.020 --> 00:14:27.020 alles umgezogen. Ich habe noch nicht alles 00:14:27.020 --> 00:14:28.940 umgezogen. Ich habe auch bei einem Ding hat es nicht 00:14:28.940 --> 00:14:30.680 geklappt. Das war irgendwie bei meinem 00:14:30.680 --> 00:14:32.900 Fast Deploy Ding, habe ich nicht 00:14:32.900 --> 00:14:34.980 updaten können auf 3.13. 00:14:35.040 --> 00:14:40.340 weil irgendwas mit PyTest und Async und irgendwelchen Geschichten 00:14:40.340 --> 00:14:41.580 nicht mehr ging dann. 00:14:42.580 --> 00:14:43.680 Ich weiß es gar nicht mehr so genau. 00:14:43.800 --> 00:14:45.580 Da dachte ich, okay, da warte ich jetzt mal noch zwei Monate ab 00:14:45.580 --> 00:14:46.360 oder so und probiere es nochmal. 00:14:46.500 --> 00:14:48.020 Mal gucken, vielleicht ist es dann gefixt. 00:14:49.380 --> 00:14:50.680 Aber genau. 00:14:51.200 --> 00:14:53.160 Aber die Dinge, die ich angefasst habe, 00:14:53.540 --> 00:14:56.460 seitdem Python 3.13 raus ist, habe ich es umgestellt 00:14:56.460 --> 00:14:59.180 und es war bis jetzt auf das eine Ding kein Problem. 00:14:59.380 --> 00:15:00.940 Ja, die Datastandsverkehr sind immer so ein bisschen langsam. 00:15:01.060 --> 00:15:03.820 Dann haben die immer diese Boundaries in ihren Versionen drin 00:15:03.820 --> 00:15:05.380 und das nervt immer so ein bisschen. 00:15:06.060 --> 00:15:08.020 Ja, ja, gut, okay. Ich habe jetzt auch gerade nicht so viel 00:15:08.020 --> 00:15:09.100 Data Science in der Hand, daher 00:15:09.100 --> 00:15:11.060 ist mir das nicht so aufgefallen. 00:15:11.560 --> 00:15:13.980 Weil ich auch da das Gefühl habe, dass eigentlich viele Bibliotheken 00:15:13.980 --> 00:15:15.820 sich da jetzt inzwischen echt Mühe geben und halt schon 00:15:15.820 --> 00:15:17.900 bei den Betas und Release Candidates 00:15:17.900 --> 00:15:19.380 halt gucken, ob es geht und dann schon. 00:15:20.060 --> 00:15:21.840 Ja. Also es ist jetzt nicht mehr so, dass es ein halbes 00:15:21.840 --> 00:15:22.660 Jahr dauert oder so. 00:15:23.420 --> 00:15:23.820 Ja. 00:15:25.600 --> 00:15:27.840 Ja, ich bin gespannt, wie lange es diesmal dauert. Tatsächlich, ja. 00:15:28.400 --> 00:15:28.620 Ja. 00:15:30.420 --> 00:15:30.820 Ja. 00:15:31.280 --> 00:15:33.420 Wollen wir hier mit den großen Blöcken 00:15:33.420 --> 00:15:35.280 weitermachen oder willst du so ein paar der kleinen Sachen sammeln? 00:15:36.220 --> 00:15:37.580 Ich weiß nicht, jetzt hatten wir schon einen großen. 00:15:37.820 --> 00:15:38.380 Es gibt noch große Blöcke. 00:15:38.720 --> 00:15:39.960 Es gibt noch zwei große. 00:15:40.660 --> 00:15:42.820 Das war auch schon ein großer, ja. 00:15:43.380 --> 00:15:44.280 Ich habe eben noch 00:15:44.280 --> 00:15:47.420 die Dokumentation 00:15:47.420 --> 00:15:49.320 durchgeschaut und den History-Modus, 00:15:49.320 --> 00:15:50.620 den fand ich auch ziemlich gut. 00:15:50.740 --> 00:15:52.640 Mit F2 kann man seine History ansehen. 00:15:53.440 --> 00:15:54.440 Ist das auch persistent? 00:15:55.260 --> 00:15:57.140 Ja, also ich habe eben in meinen 00:15:57.140 --> 00:15:59.220 History reingeguckt in meiner Session, 00:15:59.300 --> 00:16:01.160 die ich gerade gemacht habe. Das geht sehr weit zurück. 00:16:01.280 --> 00:16:03.060 Ich war sehr überrascht, wie viel History da drin ist. 00:16:03.240 --> 00:16:04.660 Oh, da muss man jetzt ja auch passen, was man 00:16:04.660 --> 00:16:06.240 da noch brennt ohne Klammern. 00:16:06.900 --> 00:16:08.680 Ja, das will ich jetzt nicht. 00:16:09.720 --> 00:16:11.300 Ohne Anwalt möchte ich diese Frage 00:16:11.300 --> 00:16:12.120 nicht beantworten. 00:16:14.280 --> 00:16:14.460 Ne, 00:16:14.600 --> 00:16:16.620 sehr viele schöne Sachen, aber 00:16:16.620 --> 00:16:18.780 ich finde es sehr interessant, dass 00:16:18.780 --> 00:16:21.080 3.13 so ein Release ist 00:16:21.080 --> 00:16:23.100 mit einer riesigen Änderung 00:16:23.100 --> 00:16:25.220 im Frontend, also jetzt diese Rapid-Sachen, 00:16:25.900 --> 00:16:27.080 aber ja auch sehr 00:16:27.080 --> 00:16:28.360 große Änderungen im Backend, 00:16:29.060 --> 00:16:30.340 zu denen wir jetzt kommen. 00:16:30.440 --> 00:16:31.200 Du meinst jetzt Nogel? 00:16:32.840 --> 00:16:34.620 Ja, es sind tatsächlich 00:16:34.620 --> 00:16:35.120 zwei. 00:16:36.300 --> 00:16:37.140 Dann machen wir Ditt. 00:16:37.580 --> 00:16:39.160 Da habe ich mir Notizen. 00:16:39.560 --> 00:16:41.380 Ja, super, okay. Alles klar. 00:16:42.440 --> 00:16:44.140 Also beides sind ja eigentlich Sachen, 00:16:44.260 --> 00:16:45.680 die eher so im... 00:16:45.680 --> 00:16:48.080 Vielleicht nochmal für alle Leute, die einsteigen, die noch gar 00:16:48.080 --> 00:16:50.620 keine Ahnung von Weißwein haben, Ditt just in time. 00:16:51.620 --> 00:16:52.280 Was ist denn das 00:16:52.280 --> 00:16:54.340 und warum ist das interessant und warum ist das wichtig? 00:16:54.340 --> 00:16:56.600 Vielleicht nochmal so einen kurzen Aufzug 00:16:56.600 --> 00:16:58.340 lang und dann... 00:16:58.920 --> 00:16:59.180 Ja. 00:17:00.040 --> 00:17:15.840 Also C-Python ist ein Interpreter, also der Python-Code, der ausgeführt wird, der wird erst nach Bytecode übersetzt und der Bytecode wird aber dann von einem in C geschriebenen Interpreter ausgeführt und das gilt als nicht so schnell. 00:17:16.960 --> 00:17:31.380 Das ist einer der Gründe, warum Python den Ruf hat, nicht so super schnell zu sein. Und seit ein paar Versionen gibt es da einiges an Arbeiten vom Faster Python Team, was zum guten Teil von Microsoft bezahlt wird, das zu verbessern. 00:17:31.560 --> 00:17:53.120 Und was die machen ist, immer noch auf dem Interpreter, aber sie verändern quasi die Bytecodes zur Laufzeit in Abhängigkeit von den Typen, die in den Funktionen verwendet werden, was dazu führt, dass wenn ich halt an irgendeiner Stelle vor allem Integers benutze, dass dann für Integers angepasster Bytecode verwendet wird, was die Ausführung schneller macht. 00:17:53.420 --> 00:18:16.020 Und das, also dieser Prozess, der hat in 3.11 angefangen und in jeder Version gibt es da eben so ein paar Verbesserungen. Und wenn man dann aber darüber noch hinaus will, dann muss man eben, oder was man dann eben machen kann, ist nochmal zu einer anderen Technik greifen, das ist der sogenannte Just-in-Time-Compiler und das ist eine Technik, die von allen schnellen JavaScript-Implementierungen oder auch von Java verwendet wird. 00:18:16.340 --> 00:18:38.700 Und da ist die Idee, dass man zur Laufzeit eben Maschinencode erzeugt für die Funktionen, die man gerade ausführen möchte und das hat den Vorteil, dass man, also der Grund, warum man das zur Laufzeit macht, ist, weil man erst zur Laufzeit die Typen weiß, die in der Python-Funktion gerade verwendet werden und dann kann man eben Code erzeugen, der dann speziell angepasst ist auf die Arten und Weisen, wie die Funktionen, die man gerade ausführt, eben verwendet werden. 00:18:40.500 --> 00:18:42.760 Aber das kann ja auch sehr dynamisch sein, 00:18:42.840 --> 00:18:44.860 aber man muss dann wahrscheinlich ein paar Mal die so ausführen 00:18:44.860 --> 00:18:46.680 und dann gucken, was passiert und dann... 00:18:46.680 --> 00:18:48.580 Genau, also das ist der grundsätzliche Ansatz. 00:18:48.680 --> 00:18:51.500 Man fängt eben an, das erstmal so mit dem Interpreter auszuführen 00:18:51.500 --> 00:18:53.660 und dabei macht man so ein bisschen Beobachtung, 00:18:53.720 --> 00:18:55.260 was für Typen eben konkret verwendet werden, 00:18:55.720 --> 00:18:56.860 führt so ein paar Statistiken mit 00:18:56.860 --> 00:18:59.920 und nur wenn die Funktion besonders oft ausgeführt wird 00:18:59.920 --> 00:19:02.640 und man dann eben mit der Zeit eben so ein paar Informationen zusammen hat, 00:19:02.700 --> 00:19:03.400 wie die Typen so sind, 00:19:04.040 --> 00:19:06.540 dann fängt es sich an, quasi das so ein bisschen zu stabilisieren 00:19:06.540 --> 00:19:09.460 und das ist auch dann der Zeitpunkt, 00:19:09.560 --> 00:19:11.560 eben dann die Bytecodes umgeschrieben werden, quasi 00:19:11.560 --> 00:19:13.320 jetzt seit Version 3.11 00:19:13.320 --> 00:19:15.560 und jetzt, was 00:19:15.560 --> 00:19:17.560 jetzt neu ist in 3.13 00:19:17.560 --> 00:19:19.660 ist, dass dann eben dieser zweite Schritt hinzukommt, 00:19:20.220 --> 00:19:21.400 wo man dann eben nicht nur 00:19:21.400 --> 00:19:23.360 Bytecodes umschreibt und 00:19:23.360 --> 00:19:25.740 für die Situation effizientere 00:19:25.740 --> 00:19:27.200 Bytecodes, sondern eben auch noch 00:19:27.200 --> 00:19:29.660 und das ist komplett optional, also bisher 00:19:29.660 --> 00:19:31.380 in den Standard-Builds ist das Feature nicht drin, 00:19:31.460 --> 00:19:33.320 das ist eher so ein 00:19:33.320 --> 00:19:35.820 Feature-Outlook 00:19:35.820 --> 00:19:37.240 für zukünftige Versionen, 00:19:38.100 --> 00:19:40.460 dass man eben CPython auch neu bauen kann 00:19:40.460 --> 00:19:44.040 mit so einem speziellen, experimentellen Build-Time-Flag, 00:19:44.120 --> 00:19:46.900 was eben sagt, ich möchte jetzt gerne einen JIT-Compiler einbauen. 00:19:47.540 --> 00:19:49.240 Und dann wird eben zur Laufzeit 00:19:49.240 --> 00:19:51.800 dieser spezialisierte Bytecode genommen 00:19:51.800 --> 00:19:53.060 und daraus Maschinencode erzeugt. 00:19:53.300 --> 00:19:55.640 Und die Hoffnung ist, dass es dann eben noch schneller wird. 00:19:56.260 --> 00:19:58.160 In 3.13 ist es aber leider noch nicht der Fall. 00:19:58.380 --> 00:20:00.720 Also sie erzeugen quasi Maschinencode. 00:20:02.340 --> 00:20:05.500 Aber der, ja, also der macht es halt nicht, 00:20:05.680 --> 00:20:07.180 das macht es doch ziemlich schneller. 00:20:07.180 --> 00:20:08.980 das ist so ein bisschen die schlechte Nachricht, aber 00:20:08.980 --> 00:20:11.320 das ist trotzdem okay, 00:20:11.460 --> 00:20:13.040 weil das Ziel ist quasi so, 00:20:13.140 --> 00:20:15.380 das Fundament zu legen 00:20:15.380 --> 00:20:17.020 für Verbesserungen, die dann in der nächsten Version 00:20:17.020 --> 00:20:19.220 hoffentlich auch wirklich dazu führen, dass halt 00:20:19.220 --> 00:20:21.380 dann C-Python das Sachen schneller ausführen kann. 00:20:22.740 --> 00:20:22.860 Ja. 00:20:23.900 --> 00:20:24.260 Und 00:20:24.260 --> 00:20:27.220 das ist, glaube ich, eine spezielle Art 00:20:27.220 --> 00:20:27.780 von 00:20:27.780 --> 00:20:31.300 Just-in-Time-Compiler oder so, die es auch noch 00:20:31.300 --> 00:20:33.120 gar nicht so lange gibt. Das geht irgendwie zurück auf 00:20:33.120 --> 00:20:35.160 so ein Paper für 00:20:35.160 --> 00:20:37.060 Lua irgendwie, für so Copy-on-Patch 00:20:37.060 --> 00:20:37.700 Ich weiß nicht. 00:20:38.880 --> 00:20:40.460 Also so ganz kann man das nicht sagen. 00:20:41.400 --> 00:20:44.660 Die Idee gibt es schon sehr lang. 00:20:44.880 --> 00:20:46.880 Das ist ein sogenannter Template JIT. 00:20:47.440 --> 00:20:48.240 Und da ist die Idee, dass man, 00:20:48.560 --> 00:20:50.420 also man hat ja dann diese spezialisierten Bytecodes, 00:20:50.540 --> 00:20:54.060 also sowas wie Add to Integers oder sowas. 00:20:54.640 --> 00:20:58.720 Und die Idee ist, dass man quasi für alle diese Bytecodes 00:20:58.720 --> 00:21:01.760 so ein bisschen Maschinencode vorbereitet, 00:21:01.860 --> 00:21:03.340 also zu dem Zeitpunkt, wo man CPython baut. 00:21:04.820 --> 00:21:21.400 Und das dann, den vorbereiteten Maschinencode, also diese Templates, die werden dann so zusammen kopiert. Und die Idee von einem Template-Jit, die ist relativ alt. Aber was jetzt neu ist, und das ist eben dieser Copy-and-Patch-Ansatz, ist die Art und Weise, wie diese Templates hergestellt werden. 00:21:21.460 --> 00:21:36.560 Und das ist eben die Einsicht von dem Copy-and-Patch-Ansatz. Das ist ein Doktorand in Kalifornien, glaube ich, Haorang Su. Und die Idee davon ist, dass man eben den C-Compiler benutzen kann, um diese Templates vorzubereiten. Das hat viele Vorteile. 00:21:37.280 --> 00:22:02.800 Also man benutzt den C-Compiler, man hat so kleine Funktionen in C geschrieben, benutzt den C-Compiler, um die dann nach Maschinencode zu übersetzen und das bedeutet insbesondere, dass normalerweise, wenn man JIT schreibt, dann muss man halt anfangen für verschiedene Maschinenarchitekturen so ein Backend quasi von Null auf erstmal zu bauen und das ist halt super aufwendig, gerade wenn man viele Architekturen unterstützen will, wie das ja bei C-Python der Fall ist. 00:22:03.060 --> 00:22:22.560 Und die Idee von dem Copy-and-Patch-Ansatz ist, man benutzt den C-Compiler, um sich den Maschinencode erzeugen zu lassen und kopiert den dann so mit Memcpy quasi an die richtige Stelle und patcht dann eben noch so ein paar Stellen, wo man dann irgendwelche Konstanten noch so in den erzeugten Maschinencode so reinpatchen kann. 00:22:23.020 --> 00:22:39.820 Und dazu benutzt man linke Informationen. Das ist wirklich so ein relativ kreativer Ansatz, um halt mit vergleichsweise wenig Aufwand, also ohne so ein komplettes Backend schreiben zu müssen, trotzdem relativ schnell einen relativ guten Maschinencode erzeugen zu können. 00:22:41.380 --> 00:22:43.980 Ja, ich glaube, das ist irgendwie LLVM oder so wird da benutzt. 00:22:44.600 --> 00:23:13.060 Genau, das ist auch so ein bisschen das Problem. Also man braucht dann genau die richtige LVM-Version. Und wenn man die nicht installiert hat, dann bringt einem auch die Flag nicht. Man kann es dann trotzdem nicht bauen. Ich habe es tatsächlich noch nicht geschafft, das zu bauen, weil ich irgendwie das richtige LVM noch nicht hatte oder was. Aber ich glaube, die arbeiten da jetzt, also ich glaube, auf dem CPython-Main-Branch ist das jetzt auch irgendwie gelöst. Da werden halt dann Sachen schon eingecheckt oder, also man muss dann nicht mehr genau die richtige Point-Version von LVM installieren. Aber habe ich jetzt noch nicht ausprobiert. 00:23:14.600 --> 00:23:21.400 Hat LLVM nicht auch so eine IR, eine Intermediate Representation, die auch irgendwie so abstrahiert ist? 00:23:21.760 --> 00:23:32.160 Ja, also im Prinzip haben das die meisten optimierenden Compiler, die haben halt irgendwie so eine Zwischendarstellung, wo sie halt quasi diese benutzen, um Code zu optimieren. 00:23:32.160 --> 00:23:40.560 Und bei LLVM ist die deswegen relativ sichtbar, weil sie halt gute Tools haben, um die dann in so eine ASCII-Syntax zu printen und auch wieder zu parsen und weiter zu verarbeiten. 00:23:42.600 --> 00:23:43.520 Aber, ja. 00:23:46.780 --> 00:23:48.460 Auch viele technische Bauteile 00:23:48.460 --> 00:23:49.200 immer noch, ja klar. 00:23:49.900 --> 00:23:52.180 Ja, es ist schon, also es ist jetzt schon 00:23:52.180 --> 00:23:54.160 so ein bisschen, der JIT in 3.13, 00:23:54.280 --> 00:23:55.660 das ist schon wirklich eher so, 00:23:56.960 --> 00:23:58.180 das sind so vorbereitende 00:23:58.180 --> 00:24:00.020 Arbeiten. Also die Hoffnung ist eben, dass das 00:24:00.020 --> 00:24:02.020 dann so in den nächsten 00:24:02.020 --> 00:24:02.520 Versionen, 00:24:04.480 --> 00:24:05.940 also ich meine, bisher ist das relativ unbefriedigend. 00:24:06.060 --> 00:24:07.900 Wir haben einen JIT, der erzeugt ganz tollen Maschinencode, 00:24:07.980 --> 00:24:08.760 aber es wird halt nicht schneller. 00:24:08.760 --> 00:24:09.080 Also, 00:24:09.740 --> 00:24:15.420 Und es ist, ja, cool, aber halt irgendwie auch nutzlos. 00:24:15.540 --> 00:24:16.420 Also warum sollte man es machen, 00:24:16.840 --> 00:24:19.240 wenn sich die Performance halt dadurch gar nicht ändert? 00:24:20.120 --> 00:24:21.460 Aber die Hoffnung ist eben, 00:24:21.540 --> 00:24:23.400 dass sie dann, wenn sie jetzt weitere Optimierungen einbauen 00:24:23.400 --> 00:24:26.780 und bei diesem Patching, 00:24:26.920 --> 00:24:31.100 da kann man noch so ein paar extra Instruktionen dann wegoptimieren. 00:24:31.180 --> 00:24:34.800 Das haben sie, glaube ich, jetzt oft im Main Repository auch schon gemacht. 00:24:35.180 --> 00:24:37.900 Und die Hoffnung ist, dass dann eben, wenn 3.14 dann da ist, 00:24:37.900 --> 00:24:40.060 erstens eben dann, dass sie so ein paar Bugs 00:24:40.060 --> 00:24:42.180 gefixt haben, weil hoffentlich eben ein paar Leute 00:24:42.180 --> 00:24:43.860 trotzdem den 00:24:43.860 --> 00:24:46.200 experimentellen JIT halt mal ausprobieren 00:24:46.200 --> 00:24:48.340 und dann vielleicht Bug-Reports schicken 00:24:48.340 --> 00:24:50.140 und dass sie dann halt 00:24:50.140 --> 00:24:52.340 in der nächsten Version dann auch die Performance 00:24:52.340 --> 00:24:53.520 noch ein bisschen verbessern können. 00:24:54.940 --> 00:24:56.220 Und insgesamt finde ich den Ansatz halt 00:24:56.220 --> 00:24:58.160 cool, weil er in Anbetracht der Tatsache, 00:24:58.260 --> 00:25:00.240 dass das C-Python-Team halt jetzt nicht so groß 00:25:00.240 --> 00:25:01.540 ist, was bezahlte Entwickler angeht, 00:25:02.440 --> 00:25:04.140 ich finde es halt einen relativ pragmatischen 00:25:04.140 --> 00:25:05.820 Ansatz, wo sie ohne jetzt irgendwie 00:25:05.820 --> 00:25:07.920 also was ich 00:25:07.920 --> 00:25:09.340 Google vor acht hat, hat irgendwie 00:25:09.340 --> 00:25:11.420 weiß nicht, 80 Leute oder so. 00:25:12.700 --> 00:25:13.760 Das fand ich auch überraschend, ja. 00:25:14.360 --> 00:25:14.640 Und 00:25:14.640 --> 00:25:17.820 also das hier hat quasi mit der kleinen 00:25:17.820 --> 00:25:19.360 Anzahl an Festangestellten halt 00:25:19.360 --> 00:25:20.740 trotzdem 00:25:20.740 --> 00:25:23.800 mit diesem Ansatz vielleicht irgendwie recht 00:25:23.800 --> 00:25:25.000 pragmatisch irgendwo hinkommen können. 00:25:26.020 --> 00:25:27.860 Ja, ich meine. Ja, ich finde das auch cool. Ich finde das 00:25:27.860 --> 00:25:29.820 auch generell cool, ohne dass es jetzt 00:25:29.820 --> 00:25:31.460 direkt eine Geschwindigkeitsverbesserung 00:25:31.460 --> 00:25:33.760 bringt, einfach weil, wie du 00:25:33.760 --> 00:25:35.560 gesagt hast, das ist eine wichtige 00:25:35.560 --> 00:25:37.760 Grundlage, um dann irgendwann die Verbesserungen 00:25:37.760 --> 00:25:39.260 rausholen zu können. Deshalb. 00:25:40.600 --> 00:25:41.820 Richtige Richtung, meiner Meinung nach. 00:25:41.880 --> 00:25:43.740 Ja, ich meine, wenn man jetzt nicht so viel Ressourcen hat, 00:25:43.780 --> 00:25:45.560 muss man sich halt überlegen, wie man die ökonomisch einsetzt. 00:25:45.660 --> 00:25:47.080 Und wenn man jetzt sieht, was 00:25:47.080 --> 00:25:49.700 vielleicht V8 irgendwie macht 00:25:49.700 --> 00:25:51.620 oder so und das dann halt einfach später, 00:25:51.740 --> 00:25:53.660 wenn sich herausgestellt hat, was da gut funktioniert, halt 00:25:53.660 --> 00:25:55.760 dann die wesentlichen Teile nimmt 00:25:55.760 --> 00:25:57.740 oder so, das wäre schon... Wobei, ich weiß nicht 00:25:57.740 --> 00:25:59.080 genau, gibt es irgendwo 00:25:59.080 --> 00:26:01.880 quasi den gleichen Ansatz, der dann schon gut funktioniert? 00:26:02.320 --> 00:26:04.600 Weil V8 ist ja dann wahrscheinlich doch 00:26:04.600 --> 00:26:06.640 eher noch deutlich komplizierter oder so. 00:26:06.820 --> 00:26:08.540 Sehr viel komplizierter. Also V8 hat halt nicht nur 00:26:08.540 --> 00:26:10.260 einen JIT, sondern irgendwie drei oder so. 00:26:10.480 --> 00:26:11.240 Oder vier. 00:26:12.460 --> 00:26:14.620 Also halt dann erstmal einen, der quasi 00:26:14.620 --> 00:26:16.560 schlechten Code sehr schnell erzeugt und dann 00:26:16.560 --> 00:26:18.720 etwas besser optimiert, sehr gut optimiert. 00:26:18.780 --> 00:26:20.380 Dann haben sie noch einen komplett getrennten JIT für 00:26:20.380 --> 00:26:22.440 WebAssembly. 00:26:22.820 --> 00:26:24.380 Also das ist schon 00:26:24.380 --> 00:26:26.040 und dann natürlich auch wirklich dann 00:26:26.040 --> 00:26:28.540 quasi richtige Backends für ganz viele verschiedene 00:26:28.540 --> 00:26:31.280 Hardware-Architekturen. 00:26:31.380 --> 00:26:33.040 Also das ist schon ein Aufwand, den 00:26:33.040 --> 00:26:34.980 meiner Ansicht nach mit dem jetzigen 00:26:34.980 --> 00:26:36.980 Funding das C-Python-Thema erstmal so nicht 00:26:36.980 --> 00:26:38.660 hinkriegen kann. 00:26:39.120 --> 00:26:45.340 Transpilen nach, 00:26:45.460 --> 00:26:46.900 einfach Python transpilen nach 00:26:46.900 --> 00:26:47.780 JavaScript. 00:26:49.440 --> 00:26:50.900 Ja, oder nach 00:26:50.900 --> 00:26:52.340 WebAssembly. 00:26:53.480 --> 00:26:55.480 Das stimmt, das ist ja tatsächlich eine unterstützte 00:26:55.480 --> 00:26:56.180 Plattform, ja. 00:26:56.740 --> 00:26:58.380 Genau, das ist jetzt eine Tier-2-Plattform. 00:26:58.580 --> 00:26:59.480 Ja, genau, das stimmt. 00:26:59.480 --> 00:27:01.100 Also das ist 00:27:01.100 --> 00:27:03.420 so ein kleines Ding, es gibt drei neue Plattformen 00:27:03.420 --> 00:27:05.420 in 3.30. Ja, super spannend. 00:27:07.220 --> 00:27:07.760 Soll ich mal, 00:27:07.920 --> 00:27:09.040 ich lese mal hier vor, also 00:27:09.040 --> 00:27:11.440 die erste, die 00:27:11.440 --> 00:27:12.860 Tier 2 Plattform heißt 00:27:12.860 --> 00:27:15.260 WASM32 WASI, also eine 00:27:15.260 --> 00:27:17.380 WebAssembly Plattform. 00:27:18.340 --> 00:27:19.260 CF, weißt du, was 00:27:19.260 --> 00:27:21.040 Tier 2, weißt du, was die Tiere bedeuten? 00:27:21.740 --> 00:27:22.860 Ich glaube irgendwie, 00:27:23.300 --> 00:27:25.080 die machen Aussagen darüber, wie viel 00:27:25.080 --> 00:27:27.060 Bildbots sie haben und was sie so versprechen 00:27:27.060 --> 00:27:28.260 an 00:27:28.260 --> 00:27:30.760 Support über die, genau, über die 00:27:30.760 --> 00:27:32.780 Version. Da gibt es irgendwie ein Papp dazu. 00:27:33.460 --> 00:27:34.760 Ja, okay, gut. Also das kann man 00:27:34.760 --> 00:27:36.720 nachlesen. Aber ist jetzt eine höhere 00:27:36.720 --> 00:27:38.000 Zahl besser oder eine kleinere? 00:27:38.240 --> 00:27:39.840 Also eins ist am besten. 00:27:40.260 --> 00:27:42.400 Die niedrigeren Zahlen sind besser, oder? Je näher du 00:27:42.400 --> 00:27:44.760 am Ziel bist, an der 00:27:44.760 --> 00:27:46.600 Spitze, umso besser ist es. Also 00:27:46.600 --> 00:27:48.440 WebAssembly ist jetzt Tier 2 00:27:48.440 --> 00:27:50.500 Supported Plattform mit vielen Buildbots und viel 00:27:50.500 --> 00:27:52.660 Stabilität in der Version. Und es gibt zwei 00:27:52.660 --> 00:27:54.780 neue Plattformen, 00:27:54.780 --> 00:27:56.940 die, da war ich sehr überrascht, 00:27:57.060 --> 00:27:58.760 die es gibt, nämlich Android und iOS 00:27:58.760 --> 00:28:00.540 sind Tier 3 00:28:00.540 --> 00:28:02.040 Officially Supported Plattform. 00:28:04.960 --> 00:28:06.880 War ja früher ein riesen 00:28:06.880 --> 00:28:08.920 Thema, wenn man Android, wenn man 00:28:08.920 --> 00:28:10.900 Python auf Android ausführen wollte oder noch schlimmer 00:28:10.900 --> 00:28:11.520 Python auf iOS. 00:28:13.220 --> 00:28:14.660 Das ging auch schon sehr lange. 00:28:14.900 --> 00:28:16.780 Das ging auch schon sehr lange. Ich meine, es ist ja 00:28:16.780 --> 00:28:18.040 auch kein Problem, du kannst ja einfach 00:28:18.040 --> 00:28:20.800 den Interpreter auch total kopilieren 00:28:20.800 --> 00:28:22.340 und so. Und da ging auch 00:28:22.340 --> 00:28:24.840 NumPy und so, das ging alles. Und es gab 00:28:24.840 --> 00:28:26.780 da so eine schöne App namens 00:28:26.780 --> 00:28:27.420 Pythonista. 00:28:29.760 --> 00:28:30.780 Aber die hat 00:28:30.780 --> 00:28:32.820 natürlich eigentlich schon gegen die App-Store-Regeln 00:28:32.820 --> 00:28:33.400 verstoßen. 00:28:35.600 --> 00:28:36.120 Also ich meine, 00:28:36.400 --> 00:28:38.720 mein 00:28:38.720 --> 00:28:40.480 Beowulf-Cluster aus iOS, 00:28:40.780 --> 00:28:41.340 aus iPhones. 00:28:42.220 --> 00:28:43.280 Was ist genau die Regel? 00:28:44.620 --> 00:28:46.140 Also die App-Store-Regel ist, 00:28:47.100 --> 00:28:48.180 du darfst da nur 00:28:48.180 --> 00:28:50.200 Dinge installieren. Also 00:28:50.200 --> 00:28:52.520 kompilierter Code, ja, aber auch irgendwie 00:28:52.520 --> 00:28:54.540 C++, C, irgendwie 00:28:54.540 --> 00:28:55.400 Objective-C, 00:28:56.400 --> 00:28:57.700 und 00:28:57.700 --> 00:28:59.140 was war es noch? 00:29:00.680 --> 00:29:01.260 Ich weiß nicht, vielleicht 00:29:01.260 --> 00:29:03.820 ist gerade eine Handvoll Sprachen. 00:29:03.840 --> 00:29:05.160 Aber viel wichtiger ist doch die Regel, dass du keinen 00:29:05.160 --> 00:29:07.380 dynamisch erzeugten Code nachladen musst. 00:29:07.380 --> 00:29:09.160 Ja, das genau, ja. 00:29:09.640 --> 00:29:11.540 Weil dann kann Apple ja nicht mehr prüfen, 00:29:11.640 --> 00:29:13.620 ob du nicht irgendwelche schlimmen 00:29:13.620 --> 00:29:14.720 Programme nachlädst. 00:29:15.120 --> 00:29:17.320 Ihre Sandbox-Tests oder was auch immer die da noch mal machen. 00:29:17.680 --> 00:29:19.440 Ja, ist auch ein 00:29:19.440 --> 00:29:21.230 Und du konntest halt mit Python, 00:29:21.350 --> 00:29:23.410 da kannst du halt auch einfach quasi Python-Code 00:29:23.410 --> 00:29:24.770 auf deinem Telefon ausführen und 00:29:24.770 --> 00:29:27.170 das geht natürlich eigentlich nicht. 00:29:28.470 --> 00:29:28.930 Ja, ist klar. 00:29:29.490 --> 00:29:31.030 Aber es ging dann doch. Ja, aber bei Android 00:29:31.030 --> 00:29:33.050 wäre das ja prinzipiell gegangen. 00:29:33.490 --> 00:29:35.510 Nur war halt das Tooling bisher immer 00:29:35.510 --> 00:29:37.390 sehr umständlich. Also ich weiß, 00:29:37.390 --> 00:29:38.990 dass es Beware gibt und es gab auch 00:29:38.990 --> 00:29:41.150 Kiwi und viele andere 00:29:41.150 --> 00:29:43.270 Ansätze schon, aber die waren schon 00:29:43.270 --> 00:29:44.850 immer sehr umständlich. 00:29:45.890 --> 00:29:46.350 Und wenn es jetzt... 00:29:46.350 --> 00:29:49.390 Genau, das ist schon noch wichtig, dass es 00:29:49.390 --> 00:29:50.850 dass es jetzt halt quasi von den 00:29:50.850 --> 00:29:52.870 C-Python-Entwicklern halt mit 00:29:52.870 --> 00:29:55.230 versorgt wird. Ich habe jetzt nochmal nachgeschaut, was genau 00:29:55.230 --> 00:29:57.210 die Tires bedeuten. Also Tire 1 00:29:57.210 --> 00:29:58.870 ist halt das richtig gute Zeug, also so 00:29:58.870 --> 00:30:01.290 macOS, Windows, 00:30:01.530 --> 00:30:01.870 Linux. 00:30:02.930 --> 00:30:04.910 Tire 2 braucht man halt irgendwie 00:30:04.910 --> 00:30:06.930 Buildbots und mindestens zwei 00:30:06.930 --> 00:30:08.630 C-Python-Core-Developer, die 00:30:08.630 --> 00:30:10.430 eben die Plattform unterstützen 00:30:10.430 --> 00:30:13.070 und wenn es da 00:30:13.070 --> 00:30:14.890 Buildbot-Failures gibt, dann 00:30:14.890 --> 00:30:16.690 werden C-Python-Releases dadurch 00:30:16.690 --> 00:30:19.150 blockiert. Und Tire 3 00:30:19.150 --> 00:30:20.010 heißt eben 00:30:20.010 --> 00:30:22.470 BuildBot einen Core-Entwickler, 00:30:23.450 --> 00:30:25.010 aber wenn es da 00:30:25.010 --> 00:30:26.710 Bugs gibt, dann kann man trotzdem, 00:30:26.750 --> 00:30:28.510 also dann kann C-Python trotzdem released werden. 00:30:30.090 --> 00:30:31.030 Also es ist quasi so, 00:30:31.090 --> 00:30:32.270 wir geben uns Mühe, aber 00:30:32.270 --> 00:30:34.190 wenn jetzt irgendwie 00:30:34.190 --> 00:30:37.010 es nur noch irgendwie einen bekannten Bug auf Android 00:30:37.010 --> 00:30:38.990 gibt, dann releasen wir halt möglicherweise trotzdem. 00:30:39.930 --> 00:30:40.870 Und der 00:30:40.870 --> 00:30:42.810 Core-Developer, der für Android und 00:30:42.810 --> 00:30:45.190 iOS zuständig ist, ist übrigens Russell 00:30:45.190 --> 00:30:47.090 Keith-McNeil, der der 00:30:47.090 --> 00:30:48.850 auch Beware schon gemacht hat, der das schon lange 00:30:48.850 --> 00:30:49.150 gemacht, 00:30:50.770 --> 00:30:52.530 hat es jetzt offenbar eben reingekriegt. 00:30:52.650 --> 00:30:53.690 Der diesen tollen Vortrag 00:30:53.690 --> 00:30:56.030 gehalten hat, irgendwie 00:30:56.030 --> 00:30:58.370 Black Swan Events für 00:30:58.370 --> 00:31:00.630 ich weiß gar nicht, wie der Titel von dem Vortrag hat, 00:31:00.910 --> 00:31:02.390 da ging es halt genau darum, was es könnte, 00:31:02.790 --> 00:31:04.690 was eigentlich sind die bedrohlichsten Geschichten, die 00:31:04.690 --> 00:31:06.270 jetzt Python noch zustoßen können 00:31:06.270 --> 00:31:08.730 und ein Szenario war halt 00:31:08.730 --> 00:31:10.290 so, ja, was ist, wenn 00:31:10.290 --> 00:31:12.630 irgendwie künftige Generationen gar nicht 00:31:12.630 --> 00:31:14.090 mehr vor so riesigen Desktop-Dingern 00:31:14.090 --> 00:31:16.610 sitzen oder so, ich kann das 00:31:16.610 --> 00:31:18.590 gar nicht verstehen, ich finde das total toll, aber 00:31:18.590 --> 00:31:20.650 eher vielleicht auf Tablets oder Telefone gucken 00:31:20.650 --> 00:31:22.590 und dann einfach ein Vergessenheit gerät, dass 00:31:22.590 --> 00:31:24.610 es Python überhaupt noch gibt, weil Python gibt es halt 00:31:24.610 --> 00:31:26.110 nicht auf iOS oder so. 00:31:26.850 --> 00:31:28.590 Und dagegen sollte man vielleicht 00:31:28.590 --> 00:31:30.470 was tun. Und dann, ja, jetzt ist halt was 00:31:30.470 --> 00:31:31.850 passiert und das sieht ja schon ganz gut aus. 00:31:32.410 --> 00:31:34.170 Ja, ich habe das bei meinen Studenten. Man muss nach Studenten echt. 00:31:34.350 --> 00:31:36.590 Also ich habe halt, also ich mache 00:31:36.590 --> 00:31:38.530 eine Python-Einführung für alle, also 00:31:38.530 --> 00:31:40.350 da dürfen Informatiker nicht hin. 00:31:40.990 --> 00:31:42.470 Und das heißt, ich habe auch Studierende 00:31:42.470 --> 00:31:44.510 aus allen Fächern und 00:31:44.510 --> 00:31:46.470 jetzt nicht viele, 00:31:46.570 --> 00:31:48.350 aber da gibt es halt dann immer wieder Teilnehmende, 00:31:48.430 --> 00:31:50.390 die dann halt einfach auch nur ein Tablet 00:31:50.390 --> 00:31:52.590 haben. Tier 1? 00:31:53.050 --> 00:31:54.450 Ja, also da sind wir noch nicht. 00:31:54.450 --> 00:31:56.050 Wir haben kein Tier 1 Gerät, genau. 00:31:56.870 --> 00:31:58.650 Und Jupiter Notebook 00:31:58.650 --> 00:32:00.330 haben wir. Wir haben dann halt entweder die Möglichkeit, 00:32:00.510 --> 00:32:02.110 das irgendwie über Google Call-Up zu machen, 00:32:02.250 --> 00:32:04.310 also ich mache alles mit Jupiter Notebooks, aber das ist halt dann immer 00:32:04.310 --> 00:32:06.570 so ein bisschen nervig mit die Input-Dateien 00:32:06.570 --> 00:32:07.550 hochladen und so Zeug. 00:32:08.130 --> 00:32:10.410 Und dann können die sich ins Rechenzentrum setzen, 00:32:10.530 --> 00:32:12.470 da hast du es auch installiert, aber das ist natürlich auch total nervig, 00:32:12.530 --> 00:32:13.910 du musst immer deine Übungsaufgaben da machen. 00:32:14.910 --> 00:32:15.990 Und so einen richtig, 00:32:16.490 --> 00:32:18.110 also richtig guten Jupiter Support 00:32:18.110 --> 00:32:20.050 auf so einem 00:32:20.050 --> 00:32:21.770 iPad gibt es halt einfach auch noch nicht. 00:32:22.510 --> 00:32:23.430 Das ist schon einfach 00:32:23.430 --> 00:32:25.990 im Vergleich zu installiert 00:32:25.990 --> 00:32:28.030 an der Conda, dann ist alles in Ordnung, ist es halt schon einfach 00:32:28.030 --> 00:32:28.610 sehr frickelig. 00:32:31.550 --> 00:32:32.110 Ich muss 00:32:32.110 --> 00:32:33.950 noch dazu sagen, nicht, dass wir jetzt hier Personen 00:32:33.950 --> 00:32:35.610 übergehen, es gibt noch zweite 00:32:35.610 --> 00:32:37.970 Maintainer für diese Plattform, neben Russell 00:32:37.970 --> 00:32:40.230 Keith-McGee. Für Android 00:32:40.230 --> 00:32:42.010 gibt es noch den Peter Victorin 00:32:42.010 --> 00:32:44.050 oder Peter Victorin 00:32:44.050 --> 00:32:45.610 oder wie auch immer man das aussprechen mag. 00:32:45.610 --> 00:32:46.830 Einer von den drei, 00:32:46.890 --> 00:32:48.370 mir verzeihen, die Wille auf Besuch. 00:32:48.810 --> 00:32:49.970 Es gibt es noch den 00:32:49.970 --> 00:32:52.670 NetDaily. Also wieder so eine tolle Name-Calling 00:32:52.670 --> 00:32:54.950 gemacht, da muss ich ja nochmal kurz zum Sammelkartenspiel 00:32:54.950 --> 00:32:56.650 zurückkommen, was er sich kurz angekündigt hat. 00:32:57.590 --> 00:32:58.810 Weil ich ja auf 00:32:58.810 --> 00:33:01.290 dem Talk von 00:33:01.290 --> 00:33:02.950 Lukas Langa, der ja 00:33:02.950 --> 00:33:04.650 in diesem tollen Rappel irgendwie dann ein 00:33:04.650 --> 00:33:06.630 kurzes Befehlchen eingeben konnte, 00:33:06.810 --> 00:33:08.490 um das Bild von, ich dachte, 00:33:08.730 --> 00:33:10.670 es wäre John Romero gewesen, was 00:33:10.670 --> 00:33:12.430 eigentlich Pablo Cardenas Agato war. 00:33:12.950 --> 00:33:14.690 Und dann hatten wir kurz dieses Thema 00:33:14.690 --> 00:33:16.510 und ich finde das eigentlich eine coole Idee, dass man demnächst 00:33:16.510 --> 00:33:18.470 auf den Pycons so 00:33:18.470 --> 00:33:20.650 Sammelkartenspiele. Wir bringen die erste 00:33:20.650 --> 00:33:22.470 Edition mit, dann machen wir den Python-Podcast 00:33:22.470 --> 00:33:23.950 das dann Team an. 00:33:25.650 --> 00:33:26.510 Ich finde, die 00:33:26.510 --> 00:33:28.630 sollten das selbst verteilen und 00:33:28.630 --> 00:33:30.530 nur die Leute, die bei den Vorträgen waren, 00:33:30.610 --> 00:33:32.550 kriegen auch so eine Karte. Also ich glaube, 00:33:32.590 --> 00:33:34.670 man kann die verkaufen. Also ich vermute, 00:33:34.790 --> 00:33:36.630 dass das wirklich die Art und Weise ist, wie man 00:33:36.630 --> 00:33:38.410 endlich mal gutes Funding für 10 Seiten findet. 00:33:41.250 --> 00:33:42.490 Ja, dann liebe 00:33:42.490 --> 00:33:44.390 Zuhörer, schreibt uns, ob das die Wahrheit ist 00:33:44.390 --> 00:33:46.370 und dann müssen wir das wohl machen. Damals als 00:33:46.370 --> 00:33:48.330 NFTs. Irgendwann gab es ja auch so Sachen, die dann diese 00:33:48.330 --> 00:33:50.210 Bilder dann gemacht haben und das dann als NFT. 00:33:50.410 --> 00:33:52.110 Ja, aber das mit den NFTs 00:33:52.110 --> 00:33:54.230 ist immer noch die Zukunft. 00:33:54.610 --> 00:33:55.150 Ich weiß nicht. 00:33:56.070 --> 00:33:58.250 Der einzige Vorteil von AI ist, dass die die NFTs 00:33:58.250 --> 00:33:58.870 verdrängt haben. 00:34:01.870 --> 00:34:02.590 Für einen ganz 00:34:02.590 --> 00:34:04.470 kurzen Moment waren Grafikkarten wieder billig 00:34:04.470 --> 00:34:06.390 und dann hat die AI 00:34:06.390 --> 00:34:07.030 zugeschlagen. 00:34:09.030 --> 00:34:09.470 Tja. 00:34:10.690 --> 00:34:12.370 Okay, also es gibt zwei neue 00:34:12.370 --> 00:34:14.270 Plattformen, Android und iOS und 00:34:14.270 --> 00:34:16.270 das ist eine großartige Sache, finde ich. 00:34:16.370 --> 00:34:18.570 Und WebAssembly. 00:34:19.070 --> 00:34:21.210 Und WebAssembly, ja genau, WebAssembly ist quasi 00:34:21.210 --> 00:34:23.590 aufgestiegen von M-Skripten 00:34:23.590 --> 00:34:24.110 zu WASI. 00:34:26.450 --> 00:34:27.210 Wir müssen noch 00:34:27.210 --> 00:34:28.230 über den anderen JIT reden. 00:34:29.910 --> 00:34:30.930 Es gibt nämlich 00:34:30.930 --> 00:34:33.150 zwei JITs in 3.13 und der eine ist 00:34:33.150 --> 00:34:35.390 der coole, der quasi das irgendwann mal schneller machen soll, 00:34:35.870 --> 00:34:37.130 der aber quasi standardmäßig gar nicht 00:34:37.130 --> 00:34:39.010 eingebaut ist und dann gibt es aber den 00:34:39.010 --> 00:34:41.150 anderen, der quasi standardmäßig eingebaut ist, 00:34:41.190 --> 00:34:42.310 aber für einen ganz anderen Zweck und 00:34:42.310 --> 00:34:44.850 ich glaube in einer der 00:34:44.850 --> 00:34:47.070 Core.py folgen, ist Pablo Galeno 00:34:47.070 --> 00:34:49.330 Sagado, über den wir gerade auch schon geredet haben, sehr stolz 00:34:49.330 --> 00:34:50.830 drauf, dass er quasi den ersten 00:34:50.830 --> 00:34:53.050 C-Python-Jit gemerged hat und geschrieben hat. 00:34:53.590 --> 00:34:55.450 Und das ist nämlich der Jit, der benutzt wird, um 00:34:55.450 --> 00:34:57.650 besseres 00:34:57.650 --> 00:34:58.610 Profiling machen zu können. 00:35:00.910 --> 00:35:01.270 Und 00:35:01.270 --> 00:35:03.150 das funktioniert mit dem Linux Perf 00:35:03.150 --> 00:35:05.090 Profiler. Und das Problem, 00:35:05.210 --> 00:35:07.130 wenn man jetzt so ein, also der Perf Profiler 00:35:07.130 --> 00:35:08.650 ist eigentlich so ein Profiler für 00:35:08.650 --> 00:35:11.050 C. Also man kann halt sehen, was macht 00:35:11.050 --> 00:35:13.150 der Kernel, was macht der Linux Kernel oder was machen eben auch 00:35:13.150 --> 00:35:15.390 die C-Programme, die im User-Space laufen 00:35:15.390 --> 00:35:17.250 und man kann eben sehen, die und die 00:35:17.250 --> 00:35:19.010 C-Funktionen werden jetzt gerade so und so oft 00:35:19.010 --> 00:35:21.350 ausgeführt. Das ist so ein Sampling-Profiler, also 00:35:21.350 --> 00:35:23.190 der Profiling-Aufhalt ist sehr gering. 00:35:23.890 --> 00:35:25.270 Das Problem ist jetzt aber, dass wenn man 00:35:25.270 --> 00:35:27.410 quasi Python-Programme profilt, 00:35:27.790 --> 00:35:29.170 dann sieht man natürlich jetzt gar nicht, welche 00:35:29.170 --> 00:35:31.310 Python-Funktionen wie viel Zeit verbrauchen, sondern 00:35:31.310 --> 00:35:33.270 man sieht dann die ganze Zeit 00:35:33.270 --> 00:35:34.770 nur, dass halt irgendwelche Interpreter-Funktionen 00:35:34.770 --> 00:35:37.210 ausgeführt werden. Und da 00:35:37.210 --> 00:35:38.910 gibt es jetzt eben dieses neue Feature, den 00:35:38.910 --> 00:35:41.070 PerfJit. Und da ist die Idee, 00:35:41.170 --> 00:35:42.970 dass man so eine ganz, ganz kleine, irgendwie ein paar 00:35:42.970 --> 00:35:45.130 wenige Maschinencode-Instruktionen 00:35:45.130 --> 00:35:46.850 lange Funktionen generiert 00:35:46.850 --> 00:35:48.030 zur Laufzeit 00:35:48.030 --> 00:35:51.130 und für jede Python-Funktion eben genau 00:35:51.130 --> 00:35:53.050 eine so eine Funktion. Und das hat 00:35:53.050 --> 00:35:55.290 den Vorteil, dass Perf eben die ganzen Python-Funktionen 00:35:55.290 --> 00:35:57.070 voneinander unterscheiden kann. Wenn man eben 00:35:57.070 --> 00:35:59.150 nicht nur eine interpretierige 00:35:59.150 --> 00:36:01.310 Python-Code-Funktion 00:36:01.310 --> 00:36:02.850 dann sieht in Perf, 00:36:03.310 --> 00:36:05.230 sondern man sieht dann eben diese neu generierten 00:36:05.230 --> 00:36:07.210 Mini-Funktionen. Und dann 00:36:07.210 --> 00:36:09.270 gibt es irgendwie so einen Rückübersetzungsschritt, 00:36:09.350 --> 00:36:10.710 wo man dann eben sagen kann, okay, 00:36:11.370 --> 00:36:13.470 diese neue, neu generierte Assembly-Funktion 00:36:13.470 --> 00:36:15.510 an Adresse sowieso, die entspricht 00:36:15.510 --> 00:36:16.650 eben der Python-Funktion 00:36:16.650 --> 00:36:19.370 f, wie auch immer. 00:36:20.110 --> 00:36:21.410 Und so kann man dann eben mit 00:36:21.410 --> 00:36:23.470 Perf sehen, in welcher Python-Funktion man 00:36:23.470 --> 00:36:25.010 lange Zeit verbraucht hat. 00:36:25.810 --> 00:36:27.470 Das hört sich nach einem 00:36:27.470 --> 00:36:28.910 sehr umständlichen Weg an. 00:36:29.990 --> 00:36:31.470 Es ist erstaunlich umständlich, aber Profiling 00:36:31.470 --> 00:36:33.570 ist auch echt einfach ultra kompliziert. 00:36:34.450 --> 00:36:35.110 Ja, gut, klar. 00:36:36.610 --> 00:36:37.530 Also es gibt 00:36:37.530 --> 00:36:39.210 ja irgendwie so 00:36:39.210 --> 00:36:41.670 irgendwie eine große Sammlung 00:36:41.670 --> 00:36:43.650 an Profilern für Python und für andere Sprachen, aber 00:36:43.650 --> 00:36:45.610 C-Profile hat halt einfach 00:36:45.610 --> 00:36:47.530 einen riesen Overhead. Dann gibt es verschiedene 00:36:47.530 --> 00:36:49.390 Sampling-Profiler für Python. Wie heißt dieser? 00:36:50.350 --> 00:36:51.750 PySpy oder so? Der funktioniert, glaube ich, 00:36:51.750 --> 00:36:53.670 ziemlich gut. Habt ihr den mal benutzt? 00:36:55.210 --> 00:36:55.930 Nee, ich weiß 00:36:55.930 --> 00:36:57.710 gar nicht. Ich hab wieder vergessen, was ich 00:36:57.710 --> 00:36:58.830 hab mal irgendwas benutzt. 00:36:59.010 --> 00:37:00.490 Gibt es einen, der Hotspot heißt? 00:37:01.630 --> 00:37:03.250 Aber Hotspot ist, glaube ich, eine UI nur, oder? 00:37:03.430 --> 00:37:04.930 Wo da die Samples herkommen, weiß ich nicht so genau. 00:37:06.390 --> 00:37:07.210 Ja, und dann gibt es also 00:37:07.210 --> 00:37:09.470 unseren quasi, WMProf, der ist aber nicht mehr so richtig 00:37:09.470 --> 00:37:11.170 maintained. Also auf Piper schon, aber 00:37:11.170 --> 00:37:13.370 C-Python nicht so richtig. Ist auch Sampling. 00:37:13.590 --> 00:37:15.250 Also Sampling heißt halt, dass man quasi 00:37:15.250 --> 00:37:17.210 nicht jeden Funktionsaufruf mitschreibt, was halt 00:37:17.210 --> 00:37:19.210 sehr, sehr hohen Overhead hat, sondern 00:37:19.210 --> 00:37:21.210 einfach nur so tausendmal pro Sekunde halt guckt, 00:37:21.270 --> 00:37:22.470 welche Funktionen gerade auf dem Stack sind. 00:37:23.090 --> 00:37:24.610 Und dann sagt, so statistisch gesehen, 00:37:24.910 --> 00:37:26.890 sind das die Funktionen halt, die dann viel Zeit brauchen. 00:37:28.490 --> 00:37:28.850 Und 00:37:28.850 --> 00:37:30.950 Perf ist halt auch so einer. Und der Vorteil von diesem 00:37:30.950 --> 00:37:33.450 Sampling-Ansatz ist, dass man den Profiling-Overhead 00:37:33.450 --> 00:37:34.850 eben beliebig klein machen kann. 00:37:34.930 --> 00:37:36.870 Man kann halt die Anzahl der Samples immer kleiner machen. 00:37:37.210 --> 00:37:52.330 Und wenn es dann nur noch 10 Samples sind, dann ist es halt quasi genauso schnell, wie es vorher auch war. Man hat aber auch schlechtere Informationen dann sozusagen. Also man kann dann quasi die Abwägung zwischen Genauigkeit der Informationen, die man hat und Overhead beliebig ausbalancieren. 00:37:52.790 --> 00:38:11.370 Und Perf funktioniert halt sehr gut, wenn man da gute Informationen darüber kriegt, was auf dem C-Level funktioniert. Aber die Informationen, welche Python-Funktion da jetzt gerade involviert ist, die geht halt verloren. Und die kann man dann eben wieder zurückkriegen mit diesem neuen Perf-Integration-Feature, das jetzt in 3.13 released wurde. Aber ist auf jeden Fall frickelig. 00:38:11.370 --> 00:38:31.310 Also ich glaube auf Mac ist es ja auch total schwierig, weil man braucht halt so ausführbare Blöcke von Maschinencode und Apple hat da halt auch einiges an Security Features. Man muss dann quasi sicherstellen, dass man so einen Codeblock eben so hin und her wechselt zwischen ich kann den Codeblock schreiben und ich kann ihn ausführen. 00:38:31.310 --> 00:38:46.430 Also man kann nie gleichzeitig schreibbar und ausführbar haben, um eben so Security-Exploits unwahrscheinlicher zu machen. Und bis man das ganz genau richtig hingekriegt hat, das ist tricky. Wobei Perf ist eigentlich nur ein Linux-Projekt. Insofern habe ich, glaube ich, gerade Quatsch gesagt. 00:38:47.070 --> 00:38:48.570 Ach so, das gehört. Ja, ich will 00:38:48.570 --> 00:38:50.490 mit MacOS, ich glaube, im letzten 00:38:50.490 --> 00:38:52.490 Copy-by-Episode war auch irgendwie 00:38:52.490 --> 00:38:54.450 drin, dass der 00:38:54.450 --> 00:38:56.830 Memory-Profiler, Memory, den Pablo 00:38:56.830 --> 00:38:58.710 gerade geschrieben hat, der 00:38:58.710 --> 00:39:00.890 hat auf MacOS nicht funktioniert, 00:39:01.050 --> 00:39:01.270 weil 00:39:01.270 --> 00:39:03.850 irgendwie sie 00:39:03.850 --> 00:39:06.830 die malloc-Funktion irgendwie, also 00:39:06.830 --> 00:39:08.870 nicht die... 00:39:08.870 --> 00:39:10.890 Von einer 00:39:10.890 --> 00:39:11.690 Mac-Version zur nächsten. 00:39:13.230 --> 00:39:14.650 Kann man auch schon mal machen. 00:39:15.490 --> 00:39:15.870 Warum nicht? 00:39:17.070 --> 00:39:18.750 Ja, ich finde es cool, dass es Leute gibt, die sich dann 00:39:18.750 --> 00:39:20.810 wirklich mit den Linkern auf allen Plattformen rumschlagen, 00:39:20.910 --> 00:39:21.750 um dieses Problem zu lösen. 00:39:25.130 --> 00:39:25.490 Ja. 00:39:27.250 --> 00:39:28.670 Ja, ja, Profiling, tja. 00:39:29.050 --> 00:39:30.470 Das ist... Wenn das so low-level ist, 00:39:30.730 --> 00:39:32.630 sinkt dann eigentlich der Tier, ist dann Tier 0, oder? 00:39:34.630 --> 00:39:34.990 Sorry. 00:39:35.490 --> 00:39:35.830 Couldn't resist. 00:39:37.350 --> 00:39:38.210 Es ist interessant. 00:39:39.550 --> 00:39:40.630 Aber was ist denn das nächste 00:39:40.630 --> 00:39:41.430 Thema auf unserer Liste? 00:39:41.430 --> 00:39:43.170 Ja, na gut. 00:39:43.510 --> 00:39:45.070 Dann, was jetzt auch drin ist, 00:39:45.150 --> 00:39:46.410 das wurde auch viel diskutiert, 00:39:46.850 --> 00:39:48.570 ist halt, ja, es nennt sich jetzt 00:39:48.570 --> 00:39:50.590 Free Threading früher, No-Gill irgendwie, 00:39:51.690 --> 00:39:52.770 dass man halt 00:39:52.770 --> 00:39:54.610 optional den Gill 00:39:54.610 --> 00:39:56.410 ausschalten kann, ist auch eine, 00:39:56.670 --> 00:39:58.670 muss man Compiler-Flex setzen und dann 00:39:58.670 --> 00:40:00.590 neu kompilieren oder halt sich ein entsprechendes 00:40:00.590 --> 00:40:02.630 Binary halt via was auch immer, wie man 00:40:02.630 --> 00:40:04.650 halt so Python installiert, halt 00:40:04.650 --> 00:40:06.670 das damit installieren und dann 00:40:06.670 --> 00:40:07.430 kann man das benutzen. 00:40:09.050 --> 00:40:10.590 Tja, also... Was macht das denn überhaupt, 00:40:10.590 --> 00:40:11.470 der Gill? 00:40:12.690 --> 00:40:13.090 Oh! 00:40:14.230 --> 00:40:27.110 Ja, es sorgt eigentlich im Grunde dafür, dass halt der, dass immer nur, dass Python immer nur auf einer CPU läuft, wenn ich das jetzt mal ganz. 00:40:28.590 --> 00:40:30.990 Aber das ist ja noch eine Auswirkung, das ist ja nicht das, was dem macht. 00:40:30.990 --> 00:40:32.310 Ne, ich glaube, das ist tatsächlich das, was. 00:40:34.170 --> 00:40:38.850 Und es stimmt auch nicht, er kann auf vielen CPUs laufen, nur halt immer nur auf einer gleichzeitig. 00:40:39.130 --> 00:40:40.730 Ja, immer nur auf einer gleichzeitig, genau, das meinte ich. 00:40:42.330 --> 00:40:44.590 Aber das ist ja nur eine Auswirkung, das ist ja nicht der Grund, 00:40:44.710 --> 00:40:46.490 warum man das macht. Der Grund, warum man das macht, ist, dass 00:40:46.490 --> 00:40:48.370 viele Operationen, 00:40:48.410 --> 00:40:50.250 gerade was Memory Management angeht, 00:40:51.670 --> 00:40:52.550 man dadurch 00:40:52.550 --> 00:40:54.710 halt nicht, da muss man halt nicht locken, 00:40:54.870 --> 00:40:56.310 was man ansonsten halt müsste, weil 00:40:56.310 --> 00:40:58.570 wenn man den Reference Counter von irgendeiner 00:40:58.570 --> 00:41:00.330 Datenstruktur erhöht, oder 00:41:00.330 --> 00:41:02.430 Also ganz allgemein, die ganzen 00:41:02.430 --> 00:41:04.310 Datenstrukturen sind halt erstmal nicht 00:41:04.310 --> 00:41:04.830 Threadsafe. 00:41:07.130 --> 00:41:08.550 Und das bedeutet, dass wenn man 00:41:08.550 --> 00:41:10.270 die von mehreren Threads aus benutzt, 00:41:10.550 --> 00:41:12.250 wird alles kaputt, dass die dann kaputt gehen können. 00:41:12.330 --> 00:41:15.410 Um das zu verhindern, müsste man halt locken 00:41:15.410 --> 00:41:17.090 und wenn man lockt, dann wird alles so langsam, 00:41:17.490 --> 00:41:19.610 dass man keinen Vorteil 00:41:19.610 --> 00:41:20.510 mehr davon hat, dass man mehr 00:41:20.510 --> 00:41:22.950 CPUs hat. Also ich glaube, 00:41:23.390 --> 00:41:25.190 die ersten Versuche, das war 00:41:25.190 --> 00:41:26.970 das Projekt hieß irgendwie 00:41:26.970 --> 00:41:28.150 Gilectomy oder so. 00:41:28.790 --> 00:41:29.790 Es gibt noch ein älteres. 00:41:30.950 --> 00:41:33.030 Also so alle paar Jahre kommt mal jemand 00:41:33.030 --> 00:41:33.910 und schaut ein Versuch aus. 00:41:35.370 --> 00:41:37.210 Doch, bei 1.1 wieder nicht genau aufgepasst. 00:41:37.290 --> 00:41:39.190 Ja, genau. Also es war wirklich so 00:41:39.190 --> 00:41:41.030 1.6 oder irgendwie so was ganz frühes, wo das dann 00:41:41.030 --> 00:41:44.530 kann gut sein, aber da war das 00:41:44.530 --> 00:41:46.470 auch, also an den Versuch erinnere ich mich noch 00:41:46.470 --> 00:41:48.270 und da war es halt so, dass wenn man das einfach nur 00:41:48.270 --> 00:41:49.730 versucht hat zu locken und auch nicht 00:41:49.730 --> 00:41:52.270 irgendwie was kompliziertes gemacht hat, sondern 00:41:52.270 --> 00:41:54.430 einfach mal probiert hat, es nicht ganz so langsam hinzukriegen, 00:41:54.790 --> 00:41:55.470 dann war irgendwie 00:41:55.470 --> 00:41:58.130 Performance war so Faktor 40 00:41:58.130 --> 00:41:59.810 weniger und 00:41:59.810 --> 00:42:01.590 ja, dann hat man es auch 00:42:01.590 --> 00:42:03.890 Single Performance, genau. 00:42:04.330 --> 00:42:06.030 Und dann hat man es runtergekriegt mit Tricks auf 00:42:06.030 --> 00:42:08.070 20, Faktor 20 00:42:08.070 --> 00:42:10.230 irgendwie schlechter, aber das ist halt immer weit 00:42:10.230 --> 00:42:12.450 entfernt von. Irgendwie 00:42:12.450 --> 00:42:14.330 man will das verwenden, weil wenn das 00:42:14.330 --> 00:42:16.370 so eine Auswirkung hat, dann lohnt sich 00:42:16.370 --> 00:42:18.370 das eher nicht. Aber was macht man denn dann mit den ganzen 00:42:18.370 --> 00:42:20.210 Objekten, die da irgendwo rumliegen? Wie holt man die denn dann weg? 00:42:23.070 --> 00:42:23.670 Wie meinst du? 00:42:23.690 --> 00:42:24.170 Wenn man nicht mehr braucht. 00:42:25.090 --> 00:42:26.090 Du meinst Garbage Collector? 00:42:26.290 --> 00:42:28.210 Ja. Gut, das ist nochmal ein anderes... 00:42:28.970 --> 00:42:30.410 Der weiß ich gar nicht, ob der irgendwie... 00:42:30.410 --> 00:42:32.250 Aber der Reference Count ist ja dafür da, oder? 00:42:32.270 --> 00:42:34.590 Dass man das wieder wegräumen kann, wenn es auf null fällt. 00:42:34.610 --> 00:42:36.250 Also an dem Garbage Collector hatten die quasi bei diesen 00:42:36.250 --> 00:42:37.810 Gilectomy und so Versuchen auch nichts geändert. 00:42:37.930 --> 00:42:40.470 was sie gemacht haben, ist jedem Objekt einen Log zu geben 00:42:40.470 --> 00:42:42.470 und immer wenn ein Threat mit dem 00:42:42.470 --> 00:42:44.430 Objekt eben interagieren will, insbesondere 00:42:44.430 --> 00:42:46.450 wenn eben der Reference Count 00:42:46.450 --> 00:42:48.290 verändert wird, musst du halt dir erstmal 00:42:48.290 --> 00:42:50.590 das Log holen für das Objekt. 00:42:51.630 --> 00:42:52.490 Und weil halt 00:42:52.490 --> 00:42:54.470 ständig, um irgendeine Operation mit 00:42:54.470 --> 00:42:56.570 dem Objekt machen zu können, du halt ständig an dem Reference Count 00:42:56.570 --> 00:42:57.230 rumoperierst, 00:42:58.030 --> 00:43:00.530 ja, musst du halt ständig auf das Log 00:43:00.530 --> 00:43:02.510 warten und das hat halt 00:43:02.510 --> 00:43:04.370 die bisherigen Versuche, den 00:43:04.370 --> 00:43:06.030 Guild zu entfernen, einfach sehr, sehr teuer gemacht. 00:43:06.510 --> 00:43:11.750 Also die Single-Thread-Performance eben komplett ruiniert. 00:43:12.730 --> 00:43:14.990 Und jetzt kann es doch dann eigentlich sein, 00:43:15.110 --> 00:43:16.790 dass so ein Objekt dann einfach weggeräumt wird, 00:43:16.890 --> 00:43:17.850 obwohl es noch gebraucht wird? 00:43:18.270 --> 00:43:19.470 Jetzt wird es super kompliziert. 00:43:19.990 --> 00:43:23.250 Also wir haben jetzt, genau, es gibt ein Guild, 00:43:23.330 --> 00:43:26.130 der verhindert, dass mehr als ein Thread Python-Core ausführen kann. 00:43:26.890 --> 00:43:28.810 Also gleichzeitig auf einem Core. 00:43:30.450 --> 00:43:32.750 Jetzt kommt eben der nächste Versuch 00:43:33.310 --> 00:43:53.930 Und das ist von Sam Gross bei Meta über viele Jahre lang eben probiert worden und der hat einige sehr clevere neue Ideen da reingebracht, um zu versuchen eben die Verlangsamung für Single-Thread-Performance, soweit es geht, zu minimieren. 00:43:53.930 --> 00:44:11.310 Und da gibt es eben so eine ganze Bandbreite an Optimierungen, womit er dann eben versucht, genau diese Probleme in den Griff zu kriegen. Und eine davon ist eben die Beobachtung, dass die allermeisten Objekte, die werden halt trotzdem nur von einem Thread benutzt. 00:44:11.650 --> 00:44:13.350 Also wenn ich halt eine Funktion habe, die 00:44:13.350 --> 00:44:15.230 irgendwie eine Liste erstellt und da was rein 00:44:15.230 --> 00:44:17.370 appendet und so weiter, selbst wenn 00:44:17.370 --> 00:44:19.330 auf ganz vielen anderen Threads halt noch Sachen laufen, 00:44:19.830 --> 00:44:20.970 kommt halt kein anderer Thread 00:44:20.970 --> 00:44:23.270 erstmal standardmäßig an diese Liste ran. 00:44:23.330 --> 00:44:25.430 Das heißt, die erste Optimierung ist zu sagen, 00:44:26.110 --> 00:44:27.570 für die ganzen lokalen 00:44:27.570 --> 00:44:29.270 Objekte, die ich also nur von einem Thread 00:44:29.270 --> 00:44:31.010 überhaupt jemals anfasse, 00:44:31.710 --> 00:44:33.410 muss ich für das 00:44:33.410 --> 00:44:35.270 Updaten der Reference Counts eben nicht locken. 00:44:35.910 --> 00:44:36.570 Also das ist quasi 00:44:36.570 --> 00:44:38.630 so die wichtigste Optimierung. 00:44:40.390 --> 00:44:41.150 Genau, das heißt 00:44:41.150 --> 00:44:42.830 Biased Reference Counting, weil quasi 00:44:42.830 --> 00:44:44.950 dafür gesorgt wird, dass man eben 00:44:44.950 --> 00:44:47.630 nicht gesharete Objekte, 00:44:48.250 --> 00:44:49.290 die nur von einem Thread 00:44:49.290 --> 00:44:50.910 eben erreichbar sind, 00:44:51.290 --> 00:44:52.790 dass man da eben das Locking quasi 00:44:52.790 --> 00:44:54.170 sein lassen kann. 00:44:56.250 --> 00:44:57.210 Jetzt gibt es aber natürlich 00:44:57.210 --> 00:44:59.450 eine ganze andere Klasse an Objekten, 00:44:59.450 --> 00:45:00.890 die werden halt von ganz vielen 00:45:00.890 --> 00:45:03.390 verschiedenen Threads angefasst, also halt 00:45:03.390 --> 00:45:05.950 alles, was die ganzen Build-ins, also 00:45:05.950 --> 00:45:07.090 None, 00:45:07.510 --> 00:45:09.350 die ganzen Typen und dafür gibt es 00:45:09.350 --> 00:45:11.170 dann also wieder einen ganz anderen Ansatz. Und da ist nämlich 00:45:11.170 --> 00:45:12.970 die Idee, dass man da halt sagt, 00:45:13.230 --> 00:45:15.270 diese Objekte, die können eh nicht sterben. 00:45:15.550 --> 00:45:16.510 Also sowas wie NAN. 00:45:16.750 --> 00:45:19.150 Warum nicht wegräumen? NAN gibt es halt einfach 00:45:19.150 --> 00:45:21.250 immer und das gilt 00:45:21.250 --> 00:45:23.150 halt für ganz, ganz viele andere Arten von 00:45:23.150 --> 00:45:24.890 Objekten auch. Die meisten Typen gibt es halt immer 00:45:24.890 --> 00:45:26.390 und die werden dann so 00:45:26.390 --> 00:45:28.590 unsterblich gemacht. 00:45:28.690 --> 00:45:30.150 Ist das dann ein Singleton? 00:45:32.230 --> 00:45:33.290 Also NAN ist auch ein Singleton, 00:45:33.410 --> 00:45:35.050 ja, aber das ist nicht das einzige 00:45:35.050 --> 00:45:37.170 Kriterium. Man kann sich schon noch vorstellen, dass es Singletons gibt, 00:45:37.270 --> 00:45:38.890 die halt vielleicht auch sterben könnten. 00:45:38.890 --> 00:45:40.810 aber, also die man vielleicht wegräumen will, aber 00:45:40.810 --> 00:45:43.030 es gibt 00:45:43.030 --> 00:45:44.790 also die ganzen eingebauten Sachen, die 00:45:44.790 --> 00:45:46.830 werden einfach nie, also die 00:45:46.830 --> 00:45:48.950 werden halt nie garbage collected und deswegen kann man 00:45:48.950 --> 00:45:50.870 da eben auch sagen, da kriegt jetzt der Reference Count 00:45:50.870 --> 00:45:52.790 irgendwie so einen speziellen Flag und 00:45:52.790 --> 00:45:54.990 dann erhöht und senkt 00:45:54.990 --> 00:45:56.170 man den Reference Count eben auch nicht. 00:45:57.070 --> 00:45:58.810 Und das, dann muss man die auch wieder nicht 00:45:58.810 --> 00:45:59.410 locken, also. 00:46:00.490 --> 00:46:02.270 Und dann gibt es noch den dritten Ansatz 00:46:02.270 --> 00:46:04.750 und das ist das sogenannte Deferred Reference Counting 00:46:04.750 --> 00:46:06.550 und da verstehe ich die ganzen Details auch nicht komplett, 00:46:06.910 --> 00:46:08.710 aber da ist eben die Idee, dass man 00:46:08.710 --> 00:46:11.610 eben das Erhöhen und 00:46:11.610 --> 00:46:13.650 Senken des Reference-Counts nicht mehr 00:46:13.650 --> 00:46:15.470 die ganze Zeit up-to-date macht, 00:46:16.230 --> 00:46:17.790 um 00:46:17.790 --> 00:46:19.650 eben zu, also da geht es um 00:46:19.650 --> 00:46:21.530 Objekte, die so dazwischen sind, also die von einem 00:46:21.530 --> 00:46:23.550 mehr als einem Thread erreicht werden können. 00:46:23.610 --> 00:46:25.530 Also man erhöht, aber man 00:46:25.530 --> 00:46:27.290 reduziert das nicht oder beides nicht? 00:46:28.430 --> 00:46:29.610 Ich glaube beides 00:46:29.610 --> 00:46:31.430 nicht, also und dann 00:46:31.430 --> 00:46:33.470 das sorgt aber dafür, dass wenn der Reference-Count null wird, 00:46:33.470 --> 00:46:35.090 dann kann man die auch nicht sofort einsammeln, sondern 00:46:35.090 --> 00:46:37.390 da muss man eben warten und dann 00:46:37.390 --> 00:46:39.550 warten, bis alle Threads zu irgendeinem 00:46:39.550 --> 00:46:41.750 wohldefinierten Punkt kommen und dann kann man schauen, 00:46:42.270 --> 00:46:43.610 ob es nicht noch irgendwelche References 00:46:43.610 --> 00:46:45.530 in den Stackframes gibt oder so, 00:46:45.910 --> 00:46:47.310 die dann noch dazugezählt werden müssen. 00:46:47.750 --> 00:46:49.630 Deswegen eben Deferred. Und nur 00:46:49.630 --> 00:46:51.450 wenn man da dann eben überall nachgeschaut hat und 00:46:51.450 --> 00:46:53.550 feststellt, oh okay, das Objekt, das ist 00:46:53.550 --> 00:46:55.350 jetzt wirklich auch von keinem Frame-Objekt mehr 00:46:55.350 --> 00:46:57.470 erreichbar, dann kann ich das wirklich wegräumen. 00:46:57.470 --> 00:46:58.870 Und das hat auch komplizierte 00:46:58.870 --> 00:47:01.670 Interaktionen mit dem 00:47:01.670 --> 00:47:04.670 Memory Allocator, 00:47:05.090 --> 00:47:08.570 Da wechselt nämlich die Free-Threading-Version 00:47:08.570 --> 00:47:09.390 auch zu Mimalog. 00:47:09.510 --> 00:47:13.810 Das ist so ein von Microsoft geschriebener C-Memory-Allocator, 00:47:13.930 --> 00:47:17.870 der eben auch besonders gut mit Multi-Threading interagiert. 00:47:17.990 --> 00:47:21.490 Und da wird auf eine für mich noch nicht ganz verständliche Art und Weise 00:47:21.490 --> 00:47:25.870 eben mit besonderen Mimalog-Features dann erreicht, 00:47:25.970 --> 00:47:27.090 dass genau das Richtige passiert. 00:47:28.130 --> 00:47:30.530 Dass genau das Richtige passiert, das ist immer toll. 00:47:33.250 --> 00:47:34.490 Ja, das ist auch ... 00:47:34.490 --> 00:47:39.770 Ja, aber das hört sich jetzt so ein bisschen an wie so Eventual Consistency für den Reference-Counter. 00:47:39.930 --> 00:47:40.710 Ja, ich glaube, das ist genau. 00:47:40.710 --> 00:47:47.870 Weil im Endeffekt ist die Zahl, die in dem Reference-Counter drinsteht, ja auch nur dann wichtig, wenn es eine Null ist. 00:47:48.730 --> 00:47:55.510 Also Vorbemerkung ist, das gilt alles nur für Objekte, die eben von mehr als einem Thread erreicht werden können. 00:47:55.990 --> 00:47:56.470 Ja, okay, klar. 00:47:56.550 --> 00:48:07.110 Genau, aber für die hast du absolut recht, da ist eben da eine Zahl drin, die nicht unbedingt wirklich alle References von allen Threads dann widerspiegelt. 00:48:07.110 --> 00:48:14.050 Und um das Objekt dann wirklich wegräumen zu können, muss man halt nochmal nachschauen, ob das wirklich alles so gestimmt hat. 00:48:14.930 --> 00:48:25.790 Genau, aber für mich der Knackpunkt an dem, dass das überhaupt funktionieren kann, ist, dass die Zahl, die tatsächlich in dem Reference Count drinsteht, die meiste Zeit ja uninteressant ist. 00:48:25.890 --> 00:48:33.990 Solange die Zahl größer als 0 ist, ist der exakte Wert nicht wichtig, sondern es wird erst dann wichtig, wenn der exakte Wert 0 erreicht. 00:48:34.090 --> 00:48:36.550 Also so ein bisschen so, als wenn du die Box aufmachst und guckst, ob die Katze noch lebt. 00:48:37.230 --> 00:48:41.050 Ja, aber du musst sie ja nur aufmachen, wenn du es wirklich wissen willst. 00:48:41.450 --> 00:48:47.110 Solange es dich nicht interessiert, ob die Katze noch lebt, kannst du außen den Schalter drücken oder nicht drücken, so viel du willst. 00:48:47.510 --> 00:48:54.630 Und ich glaube, das ist für mich in meinem Kopf so ein bisschen der Kern an der Sache, warum das überhaupt funktionieren kann. 00:48:55.030 --> 00:49:05.350 Weil wir nur zu sehr wenigen Zeitpunkten wirklich den exakten Wert wissen müssen, weil wir nur zu wenigen Zeitpunkten wirklich draufschauen müssen und sagen müssen, okay, jetzt muss ich wissen, ob die Zahl wirklich null ist oder nicht. 00:49:05.670 --> 00:49:20.470 Ich glaube, Eventual Consistency ist auf jeden Fall ein super Gedankenmodell, weil, also Eventual Consistency wird ja auch quasi aus den gleichen Gründen eingeführt. Also natürlich kann ich, will ich, eigentlich ist es besser, wenn meine Information halt die ganze Zeit konsistent ist. 00:49:20.990 --> 00:49:22.950 Aber das hat halt im Datenbankbereich 00:49:22.950 --> 00:49:25.130 dann auch entsprechende Nachteile, Performance-Nachteile. 00:49:25.950 --> 00:49:27.030 Ja, und gerade in verteilten 00:49:27.030 --> 00:49:27.870 Datenbanken. Genau. 00:49:28.790 --> 00:49:30.990 Und quasi aus den gleichen 00:49:30.990 --> 00:49:32.990 Gründen führe ich halt quasi 00:49:32.990 --> 00:49:34.810 im Field, also auf einem ganz anderen 00:49:34.810 --> 00:49:36.870 Maßstab natürlich, aber werden die 00:49:36.870 --> 00:49:38.070 Deferred Reference Counts verwendet. 00:49:38.990 --> 00:49:40.750 Ja, cool. Super coole Sache. 00:49:41.590 --> 00:49:42.790 Ja, genau. 00:49:42.950 --> 00:49:44.870 Aber es ist halt, wie gesagt, auch bisher noch 00:49:44.870 --> 00:49:46.990 experimentell 00:49:46.990 --> 00:49:48.730 und standardmäßig nicht eingebaut. Da gibt es auch noch 00:49:48.730 --> 00:49:50.690 so ein paar Nachteile. Die Single Thread Performance ist 00:49:50.690 --> 00:49:52.590 auch quasi in der 00:49:52.590 --> 00:49:54.590 Free-Threading-Version schlechter im Moment. 00:49:54.710 --> 00:49:56.570 Ich glaube vor allem, weil sie im Moment eben noch 00:49:56.570 --> 00:49:58.470 dieses Bytecode-Rewriting, 00:49:58.610 --> 00:50:00.590 wo wir vorhin in der JIT-Sektion drüber gesprochen haben, 00:50:00.630 --> 00:50:01.430 noch abschalten müssen. 00:50:02.210 --> 00:50:04.350 Eben aus dem Grund, dass wenn ich quasi mehr 00:50:04.350 --> 00:50:06.010 als einen Thread habe, 00:50:06.350 --> 00:50:07.850 der die gleiche Python-Version ausführt 00:50:07.850 --> 00:50:09.810 und alle wollen jetzt den Bytecode umschreiben, 00:50:10.430 --> 00:50:11.650 dann habe ich da eben auch wieder 00:50:11.650 --> 00:50:12.970 quasi 00:50:12.970 --> 00:50:16.390 Mutationen derselben Datenstruktur 00:50:16.390 --> 00:50:18.370 von einem Thread und das will ich nicht immer locken 00:50:18.370 --> 00:50:20.150 und deswegen haben sie das bisher einfach 00:50:20.150 --> 00:50:22.130 abgeschaltet in der Free-Threading-Version 00:50:22.130 --> 00:50:24.150 und das sorgt dann eben für 00:50:24.150 --> 00:50:26.410 weiß ich nicht, 10%, 20% 00:50:26.410 --> 00:50:27.830 Verschlechterung der 00:50:27.830 --> 00:50:29.270 Single-Threading-Performance. 00:50:30.870 --> 00:50:31.310 Oder 00:50:31.310 --> 00:50:34.030 es gibt eben, ein anderes Problem ist, dass es 00:50:34.030 --> 00:50:36.070 gibt eben einfach ganz, ganz viel Python-Code, der 00:50:36.070 --> 00:50:38.270 so in der Welt ist, in irgendwelchen Bibliotheken, 00:50:38.330 --> 00:50:39.430 der einfach nicht Thread-Safe ist. 00:50:40.210 --> 00:50:42.210 Bisher konnte man sich halt so ein bisschen immer 00:50:42.210 --> 00:50:44.470 so durchmogeln 00:50:44.470 --> 00:50:46.290 mit der Tatsache, dass meistens ist man 00:50:46.290 --> 00:50:48.130 halt vom Gill geschützt und 00:50:48.130 --> 00:50:50.250 so viel Multithreaded-Python-Code 00:50:50.250 --> 00:50:52.270 gibt es halt auch oft nicht und 00:50:52.270 --> 00:50:54.190 deswegen finden wir jetzt 00:50:54.190 --> 00:50:55.590 wahrscheinlich die nächsten zehn Jahre 00:50:55.590 --> 00:50:58.130 Locking-Bugs in allen 00:50:58.130 --> 00:50:59.150 PyPI-Bibliotheken. 00:51:00.730 --> 00:51:02.330 Und für die C-Extensions 00:51:02.330 --> 00:51:03.230 gilt das natürlich erst recht. 00:51:04.490 --> 00:51:06.210 Ja, aber die C-Extensions hatten ja vorher schon 00:51:06.210 --> 00:51:08.010 die Möglichkeit, den GIL 00:51:08.010 --> 00:51:09.670 freizugeben, also NumPy zum Beispiel. 00:51:10.870 --> 00:51:12.150 Ja, sobald ich quasi was 00:51:12.150 --> 00:51:13.870 mache, was dann wirklich 00:51:13.870 --> 00:51:15.950 weit weg von jedem 00:51:15.950 --> 00:51:16.670 Python-Objekt. 00:51:17.610 --> 00:51:18.550 Genau, was aus dem 00:51:18.550 --> 00:51:20.290 Python-Memory-Management rausgeht. 00:51:20.390 --> 00:51:21.450 Da kannst du schon mit deinem Fuß 00:51:21.450 --> 00:51:22.810 deinen Sprecher kaputt hauen. 00:51:23.830 --> 00:51:25.270 Ja gut, okay, Footguns. 00:51:26.210 --> 00:51:27.110 Also genau, die große 00:51:27.110 --> 00:51:29.030 Mathematik-Multiplikation, die NumPy macht, 00:51:29.090 --> 00:51:30.410 die hat halt mit Python nichts mehr zu tun. 00:51:31.010 --> 00:51:32.690 Und die konnte halt dann auch schon 00:51:32.690 --> 00:51:35.310 auf dem extra Core dann 00:51:35.310 --> 00:51:39.470 den Lüfter heiß laufen lassen. 00:51:40.510 --> 00:51:41.570 Aber genau. 00:51:42.850 --> 00:51:43.450 Ja, das sind die 00:51:43.450 --> 00:51:44.830 wenigsten Operationen, das ist mir schon klar. 00:51:45.230 --> 00:51:47.390 Die prinzipielle Möglichkeit gab es vorher schon. 00:51:47.610 --> 00:51:50.070 Wenn ich mein eigenes Memory Management 00:51:50.070 --> 00:51:51.890 mache, brauche ich auch, bin ich nicht auf den Gelenk. 00:51:51.930 --> 00:51:53.910 Ja, aber da hat man sich dann ja auch wahrscheinlich 00:51:53.910 --> 00:51:55.830 dann schon Gedanken drüber gemacht, wie man das dann tut, 00:51:56.010 --> 00:51:57.990 ohne dass es kaputt geht. Oder wenn man 00:51:57.990 --> 00:51:59.510 es falsch gemacht hätte, wäre es schon aufgefallen. 00:51:59.870 --> 00:52:01.950 Aber ganz viel von dem, wo man sich keine Gedanken 00:52:01.950 --> 00:52:03.790 gemacht hat, das wird dann jetzt wahrscheinlich irgendwann 00:52:03.790 --> 00:52:05.430 auffallen, dass das nicht ganz richtig war. 00:52:05.430 --> 00:52:06.410 Das ist auch in der Standardbibliothek. 00:52:06.750 --> 00:52:08.170 Da gibt es einfach ganz viele solche Stellen. 00:52:08.270 --> 00:52:11.010 Wir hatten heute so ein Bug-Report. 00:52:12.710 --> 00:52:14.230 Es gibt das Line-Cache-Modul. 00:52:14.310 --> 00:52:16.630 Das kennt keiner, weil man das quasi selber nie benutzt. 00:52:16.690 --> 00:52:18.870 ist quasi dafür da, dass wenn ich Tracebacks 00:52:18.870 --> 00:52:21.070 kriege, dass die Source-Code-Zeilen 00:52:21.070 --> 00:52:23.070 halt quasi aus den Python-Dateien 00:52:23.070 --> 00:52:24.850 geladen werden zum Anzeigen. Und das wird 00:52:24.850 --> 00:52:26.810 gecached, damit ich nicht jedes Mal die Dateien eröffnen muss. 00:52:27.550 --> 00:52:28.890 Und wenn ich jetzt aber 00:52:28.890 --> 00:52:30.830 quasi Python-Code zu Laufzeigen erzeuge, mit 00:52:30.830 --> 00:52:32.930 exec oder so, dann kann ich quasi auch 00:52:32.930 --> 00:52:34.610 da dann in den Line-Cache 00:52:34.610 --> 00:52:36.810 so Sachen reinschreiben. Und die 00:52:36.810 --> 00:52:38.690 will ich aber vielleicht auch wieder löschen, damit 00:52:38.690 --> 00:52:40.830 eben der Cache nicht mehr und mehr Speicher 00:52:40.830 --> 00:52:42.570 verwendet. Und dann hatten wir einen Bug von 00:52:42.570 --> 00:52:44.310 SymPy oder so, die schreiben da eben so 00:52:44.310 --> 00:52:46.650 Sachen in den Line-Cache rein und löschen die dann auch wieder. 00:52:46.690 --> 00:52:48.710 und dann stellt sich halt raus, dass der Line-Cache 00:52:48.710 --> 00:52:50.770 nicht Thread-Safe ist. Also wenn ich 00:52:50.770 --> 00:52:52.130 das quasi von mehreren Threads mache, 00:52:52.630 --> 00:52:54.630 dann kriege ich halt irgendwelche komischen Exceptions 00:52:54.630 --> 00:52:56.510 von irgendwelchen internen Line-Cache 00:52:56.510 --> 00:52:58.390 Funktionen, von denen ich noch nie gehört habe 00:52:58.390 --> 00:53:00.510 und ja, 00:53:00.810 --> 00:53:02.650 also wenn, klar 00:53:02.650 --> 00:53:04.470 das ist jetzt alles schon extra ultra 00:53:04.470 --> 00:53:06.690 speziell, aber so Stellen wird es 00:53:06.690 --> 00:53:08.530 halt in der Standardbibliothek auch noch an 00:53:08.530 --> 00:53:10.510 anderen Plätzen geben, dass man halt dann 00:53:10.510 --> 00:53:12.190 feststellt, oh okay, es gibt hier Python-Code, 00:53:13.230 --> 00:53:14.850 da hat halt noch nie jemand drüber nachgedacht, 00:53:14.930 --> 00:53:16.190 was passiert eigentlich, wenn ich das auf 00:53:16.190 --> 00:53:17.750 vier Threads gleichzeitig ausführen. 00:53:18.210 --> 00:53:20.130 Ja, und eigentlich sollte man sich ja auch keine Gedanken, 00:53:20.210 --> 00:53:21.290 beziehungsweise es ist ja der 00:53:21.290 --> 00:53:24.390 Ansatz, dass man sich keine Gedanken drüber machen soll. 00:53:24.490 --> 00:53:26.330 Viele andere Sprachen lösen das Problem halt 00:53:26.330 --> 00:53:28.130 auf eine andere Art und Weise, indem sie sagen, 00:53:28.210 --> 00:53:30.050 da musst du jetzt halt selber explizit drüber nachdenken. 00:53:32.190 --> 00:53:32.550 Also 00:53:32.550 --> 00:53:34.250 man wird da... Das ist ja der Ansatz, dass man es in Python 00:53:34.250 --> 00:53:36.490 nicht machen muss. Man wird da in Python schon drüber nachdenken 00:53:36.490 --> 00:53:38.130 müssen. Also wenn du halt sowas hast, wie du hast 00:53:38.130 --> 00:53:40.170 irgendein globales Dictionary und das wird 00:53:40.170 --> 00:53:42.250 jetzt von zwei Threads mutiert und ich habe aber in beiden 00:53:42.250 --> 00:53:43.970 eine Iteration darüber, 00:53:44.350 --> 00:53:46.630 dann sind halt wahrscheinlich die Invarianten 00:53:46.630 --> 00:53:48.530 der Schleife kaputt, egal ob die Datenstruktur 00:53:48.530 --> 00:53:50.610 jetzt, also klar, die Datenstruktur 00:53:50.610 --> 00:53:52.630 soll nicht kaputt gehen, aber ich kann 00:53:52.630 --> 00:53:54.350 ja trotzdem dann plötzlich den Key 00:53:54.350 --> 00:53:56.430 verlieren, den ich erwarte, dass da noch 00:53:56.430 --> 00:53:57.170 eine Dictionary drin ist. 00:53:59.090 --> 00:54:00.330 Ja, auch diese ganzen 00:54:00.330 --> 00:54:02.570 Probleme, die bei Multithreaded Programming 00:54:02.570 --> 00:54:04.310 auftreten, also allein, 00:54:04.550 --> 00:54:06.550 wenn ich irgendeine Variable habe, die ich inkrementieren 00:54:06.550 --> 00:54:08.710 möchte, dann, da muss 00:54:08.710 --> 00:54:10.490 ich ja schon irgendwie einen 00:54:10.490 --> 00:54:11.610 Mechanismus haben, der 00:54:11.610 --> 00:54:14.010 Multithreading ermöglicht, aber 00:54:14.010 --> 00:54:15.370 das ist ja nochmal eine ganz andere Ebene. 00:54:16.330 --> 00:54:17.950 Ja, ja klar und das ist auch, also solche 00:54:17.950 --> 00:54:19.550 Bugs haben wir definitiv auch schon gesehen, also 00:54:19.550 --> 00:54:22.070 sowas wie, ja die sind ja auch leicht, 00:54:22.310 --> 00:54:23.790 also ich meine, die hat man ja sofort, 00:54:24.090 --> 00:54:26.250 ja, also sowas wie self.counter 00:54:26.250 --> 00:54:28.090 plus gleich 1, das ist halt nicht 00:54:28.090 --> 00:54:29.790 Atomic in 00:54:29.790 --> 00:54:32.050 der Free-Threading-Version, ja, also wenn ich 00:54:32.050 --> 00:54:33.190 da mehrere Threads habe, die das machen, 00:54:33.790 --> 00:54:35.870 dann, ja, 00:54:36.010 --> 00:54:37.230 dann könnten halt komische Sachen passieren. 00:54:37.770 --> 00:54:39.490 Aber da gab es auch früher schon so, 00:54:39.590 --> 00:54:45.990 Gab es auch früher schon so Stolperfallen, wo manche Sachen in Python Atomic aussahen und es dann aber irgendwie auch nicht. 00:54:45.990 --> 00:55:04.210 Genau, also viele von diesen Bugs, die sind quasi bisher auch schon, das sind jetzt quasi keine Bugs, die nur in Free Threading wirklich vorhanden sind. Das sind quasi latente Bugs, die es schon immer gibt, die auch quasi in der ganz normalen GIL-Version von Python Bugs sind und Crashes verursachen können. 00:55:05.550 --> 00:55:26.590 Nur bisher waren die quasi einfach viel unwahrscheinlicher, dass man die wirklich dann auch trifft, diese Bugs. Aber dadurch, dass jetzt eben mehr Leute versuchen werden, mit Multithreading in der Free-Threading-Version Programme dann schneller laufen zu lassen, wird die Wahrscheinlichkeit, dass man diese Bugs halt dann auch quasi in echt sieht, die geht halt hoch. 00:55:26.870 --> 00:55:33.810 Das heißt, also ja, ich meine das ernst. Wir werden jetzt wahrscheinlich zehn Jahre lang Bugs in allen Bibliotheken finden, die irgendwas mit Threading zu tun haben. 00:55:34.410 --> 00:55:45.210 Ja und es gibt ja auch keine so richtigen atomaren Operationen in Python oder keine, denen das ansieht, dass sie atomar sind. Das macht das Reasoning so ein bisschen schwierig. 00:55:45.370 --> 00:56:03.610 Absolut. Und das ist ja auch eine der großen Schwierigkeiten des Free-Threading-Projekts, dass sie sich quasi bei allen eingebauten Containern, also wie Listen und Dictionaries und so weiter, jetzt überlegen müssen, welche der Methoden wollen wir eigentlich als atomar verstanden haben und welche halt dann auch nicht. 00:56:04.410 --> 00:56:07.830 Das erkennt man nicht. 00:56:07.830 --> 00:56:10.450 Ich glaube, das wird dann dokumentiert. 00:56:11.890 --> 00:56:13.830 Ja gut, klar, das muss man nachlesen, aber ja. 00:56:14.370 --> 00:56:17.250 Aber die Entwickler, die quasi Free Threading implementieren, 00:56:17.370 --> 00:56:20.010 die müssen sich eben bei jeder Methode Gedanken darüber machen. 00:56:20.910 --> 00:56:22.390 Also List Dependent ist halt Atomic, 00:56:22.510 --> 00:56:24.690 aber List Extent bin ich mir schon mal nicht mehr so sicher. 00:56:25.350 --> 00:56:28.570 Wenn das, was ich dann als Argument von Extent reinreiche, 00:56:28.610 --> 00:56:29.870 wenn das selber ein Iterator ist 00:56:29.870 --> 00:56:31.490 und da halt dann irgendwie mit einem Generator 00:56:31.490 --> 00:56:32.810 Python-Code ausgeführt wird, 00:56:32.850 --> 00:56:34.390 dann kann das halt auch eine Weile dauern, bis ich da durch. 00:56:34.410 --> 00:56:36.250 bin. Und in der Zwischenzeit können 00:56:36.250 --> 00:56:38.090 natürlich andere Threads dann laufen und 00:56:38.090 --> 00:56:39.890 irgendwelchen Quatsch produzieren. 00:56:40.710 --> 00:56:42.230 Ja, und jetzt machen wir uns 00:56:42.230 --> 00:56:44.210 auf einmal Gedanken über Transaktionen und über 00:56:44.210 --> 00:56:46.190 Transaktionsmanagement und das ist dann schon auf 00:56:46.190 --> 00:56:47.730 Sprachebene was sehr Spezifisches. 00:56:48.470 --> 00:56:50.030 Um die Frage zu beantworten, was für 00:56:50.030 --> 00:56:52.290 einen atomaren Counter ich benutzen kann, da gibt's 00:56:52.290 --> 00:56:52.710 irgendwie 00:56:52.710 --> 00:56:56.550 itertools.counter oder so, heißt es glaube ich. 00:56:56.910 --> 00:56:58.430 Und das gilt wirklich als, 00:56:58.550 --> 00:56:59.890 also das ist die 00:56:59.890 --> 00:57:01.950 Thread-Safe-Variante, um einen 00:57:01.950 --> 00:57:03.710 atomaren Counter entfalten zu haben. 00:57:05.410 --> 00:57:06.590 Also hätte ich jetzt nicht 00:57:06.590 --> 00:57:08.530 gewusst. Ich auch nicht, aber 00:57:08.530 --> 00:57:10.230 wir hatten halt Bug-Reports, die gesagt haben, 00:57:10.310 --> 00:57:12.270 self.x gleich 1 geht halt nicht. 00:57:13.110 --> 00:57:13.770 Ja, genau. 00:57:14.710 --> 00:57:16.550 Ich erinnere mich noch, das habe ich vor Jahren 00:57:16.550 --> 00:57:18.710 mal diese Meinung 00:57:18.710 --> 00:57:20.590 vertreten, dass das Global Interpreter 00:57:20.590 --> 00:57:22.530 Log mich davor schützt, dass ich 00:57:22.530 --> 00:57:24.630 x plus gleich 1 machen kann, so viel ich will. 00:57:25.530 --> 00:57:26.550 Und dann haben wir 00:57:26.550 --> 00:57:27.990 im Chaosdorf 00:57:27.990 --> 00:57:30.710 an einem Abend das einfach mal ausprobiert 00:57:30.710 --> 00:57:32.610 und es stellte sich als falsch 00:57:32.610 --> 00:57:34.330 raus, die Annahme, weil man eben sehr schnell 00:57:34.330 --> 00:57:35.770 falsche Zahlen rauskriegen kannst. 00:57:36.330 --> 00:57:36.890 Darf ich kurz fragen? 00:57:37.570 --> 00:57:37.790 Ja. 00:57:38.370 --> 00:57:39.230 Das ist selbstverständlich. 00:57:39.490 --> 00:57:40.030 Was wissen wir hier? 00:57:40.050 --> 00:57:43.470 Also das komplette, wie heißt das, Insider Baseball, 00:57:43.610 --> 00:57:47.190 also das hat sich geändert in den letzten Python-Versionen, 00:57:47.430 --> 00:57:48.870 also in den letzten C-Python-Versionen. 00:57:49.370 --> 00:57:52.970 Du hast absolut recht, dass quasi, also ursprünglich war die Regel, 00:57:53.870 --> 00:57:58.430 ein Bytecode ist atomar und aber theoretisch kann ich 00:57:58.430 --> 00:58:01.090 nach jedem Bytecode eben einen Thread-Switch haben 00:58:01.090 --> 00:58:02.990 und sowas wie 00:58:02.990 --> 00:58:04.670 das erwähnte Beispiel 00:58:04.670 --> 00:58:07.090 X plus gleich 1, das sind eben mehrere 00:58:07.090 --> 00:58:08.510 Bytecodes, das heißt, da kann ich dazwischen 00:58:08.510 --> 00:58:10.970 ein Threadswitch haben und entsprechend 00:58:10.970 --> 00:58:13.230 ist das nicht atomar. In einer 00:58:13.230 --> 00:58:14.150 der letzten Versionen, 00:58:15.330 --> 00:58:17.130 ich weiß nicht, 3.12 vielleicht oder so, 00:58:17.670 --> 00:58:18.450 haben sie quasi 00:58:18.450 --> 00:58:20.930 in CPython die Bytecodes, 00:58:21.150 --> 00:58:23.550 wo man Threadswitches 00:58:23.550 --> 00:58:25.150 machen kann, also in der 00:58:25.150 --> 00:58:26.290 regulären GIL-Version, 00:58:27.150 --> 00:58:28.210 stark reduziert. 00:58:29.170 --> 00:58:31.030 Und es gibt jetzt eben nur noch ganz, ganz wenige 00:58:31.030 --> 00:58:32.210 Bytecodes, wo wirklich dann 00:58:32.210 --> 00:58:34.110 Switches stattfinden können. 00:58:35.030 --> 00:58:36.790 Das sorgt dafür, dass die 00:58:36.790 --> 00:58:38.870 quasi beobachtbare... 00:58:38.870 --> 00:58:40.270 Atomarität 00:58:40.270 --> 00:58:42.030 zunimmt. Das heißt, plötzlich 00:58:42.030 --> 00:58:43.970 in 3.12 war dieses Counter-Beispiel 00:58:43.970 --> 00:58:45.830 atomar. Und das ist natürlich 00:58:45.830 --> 00:58:47.670 total schlecht, weil 00:58:47.670 --> 00:58:50.090 wenn man die Community darauf vorbereiten 00:58:50.090 --> 00:58:51.930 will, dass jetzt irgendwann mal der Guild entfernt wird 00:58:51.930 --> 00:58:53.870 und man quasi mit 00:58:53.870 --> 00:58:56.030 Thread-Switches an viel mehr 00:58:56.030 --> 00:58:57.490 Stellen rechnen muss, 00:58:58.070 --> 00:58:59.990 ist es halt schlecht, wenn man in der Version davor 00:58:59.990 --> 00:59:01.950 dafür sorgt, 00:59:02.110 --> 00:59:04.110 dass viel weniger Thread-Switches 00:59:04.110 --> 00:59:05.970 an viel vorhersagbareren Stellen, nämlich nur 00:59:05.970 --> 00:59:07.450 am Ende von der Schleife oder sowas, stattfinden 00:59:07.450 --> 00:59:09.910 kann. Also 00:59:09.910 --> 00:59:11.910 das finde ich, also ich meine 00:59:11.910 --> 00:59:13.850 klar, dieses Reduzieren der 00:59:13.850 --> 00:59:15.870 Thread-Switches, das erhöht halt wieder die 00:59:15.870 --> 00:59:17.850 Single-Threading-Performance, das war der Grund, warum sie das 00:59:17.850 --> 00:59:19.910 gemacht haben, aber ich finde es 00:59:19.910 --> 00:59:21.030 halt unstrategisch. 00:59:22.410 --> 00:59:23.850 Also ich glaube, wenn du in 3.12 das mit 00:59:23.850 --> 00:59:25.490 dem Counter nochmal ausprobieren würdest, dann würdest du, 00:59:25.670 --> 00:59:27.350 das wäre es quasi nicht mehr beobachtbar. 00:59:28.030 --> 00:59:29.650 Dann mache ich das jetzt mal nicht, zur Sicherheit. 00:59:30.590 --> 00:59:31.610 Mach lieber gleich in der 00:59:31.610 --> 00:59:34.230 No-Gill-Version. 00:59:35.330 --> 00:59:35.830 Ja gut, aber 00:59:35.830 --> 00:59:36.870 damit muss es ja gehen. 00:59:37.450 --> 00:59:40.990 damit müsstest du es kaputt kriegen, würde ich 00:59:40.990 --> 00:59:42.610 hoffen. Ja, gut, kaputt kriegen. 00:59:44.130 --> 00:59:45.050 Ja, also. 00:59:46.690 --> 00:59:48.830 Ich habe jetzt leider keine Node-Gate-Version hier 00:59:48.830 --> 00:59:50.570 kompiliert, deshalb muss ich leider. 00:59:50.670 --> 00:59:52.770 Aber ich glaube, da gibt es auch zum Beispiel so, also es gibt 00:59:52.770 --> 00:59:54.610 Packages davon. Ja, ja, also bei 00:59:54.610 --> 00:59:56.770 UV habe ich jetzt gesehen, gibt es das auf jeden Fall. 00:59:57.050 --> 00:59:58.490 Ja, bei UV, bei Python 00:59:58.490 --> 01:00:00.650 inside. Genau. Und in 01:00:00.650 --> 01:00:02.070 bei Panf. 01:00:02.830 --> 01:00:04.450 In Panf weiß ich nicht, aber in Ubuntu, 01:00:04.610 --> 01:00:06.310 in dem Dead Snake 01:00:06.310 --> 01:00:08.130 PPA gibt es auch. 01:00:09.390 --> 01:00:12.170 Ja, aber ich meine, also 01:00:12.170 --> 01:00:14.390 ehrlich gesagt, ich weiß nicht, habt ihr 01:00:14.390 --> 01:00:16.710 jetzt alle schon einen Anwendungsfall, 01:00:16.710 --> 01:00:18.730 wo ihr unbedingt das mal ausprobieren 01:00:18.730 --> 01:00:20.330 wollt, ob dann nicht alles viel schneller wird? 01:00:20.550 --> 01:00:22.210 Weil ehrlich gesagt, ich habe das 01:00:22.210 --> 01:00:24.610 dann nicht so 01:00:24.610 --> 01:00:25.650 wahnsinnig viele Dinge. 01:00:26.450 --> 01:00:28.110 Es liegt aber halt vor allem auch daran, dass wir 01:00:28.110 --> 01:00:29.990 daran gewöhnt sind, es nicht zu brauchen. 01:00:30.190 --> 01:00:31.390 Gut, das kann natürlich sein. 01:00:31.850 --> 01:00:34.450 Ich glaube schon, dass es dann 01:00:34.450 --> 01:00:36.250 einiges gibt, wo das halt schon 01:00:36.250 --> 01:00:38.270 irgendwie auch, klar, man muss dann 01:00:38.270 --> 01:00:40.250 sich irgendwie umgewöhnen und vielleicht 01:00:40.250 --> 01:00:42.210 gibt es auch ein paar schöne Bibliotheken, die das halt alles 01:00:42.210 --> 01:00:43.870 ein bisschen weniger gefährlich machen, 01:00:44.410 --> 01:00:46.270 dass man so ein paar schöne Abstraktionen auf jeden Fall 01:00:46.270 --> 01:00:46.570 jetzt hat. 01:00:48.510 --> 01:00:50.190 Aber ich denke schon, dass wir 01:00:50.190 --> 01:00:52.130 an einen Punkt kommen können, wo man dann eben sagen kann, 01:00:54.250 --> 01:00:54.450 ja, 01:00:54.850 --> 01:00:56.190 also früher hätten wir vielleicht Multiprocessing 01:00:56.190 --> 01:00:57.750 genommen und es wäre nervig und 01:00:57.750 --> 01:01:00.430 also frickelig gewesen, 01:01:00.510 --> 01:01:02.010 das dann gut hinzukriegen und jetzt nehmen wir halt 01:01:02.010 --> 01:01:03.450 und es funktioniert gut. 01:01:05.010 --> 01:01:05.530 Ja, das 01:01:05.530 --> 01:01:08.310 ist halt auch, mit Threads 01:01:08.310 --> 01:01:10.450 programmieren ist halt 01:01:10.450 --> 01:01:12.350 auch was Gefährliches. Da gibt es ja, also ich 01:01:12.350 --> 01:01:14.310 meine, selbst wenn diese Operationen alle 01:01:14.310 --> 01:01:16.270 atomar sind und selbst wenn das so ist, dann gibt es ja 01:01:16.270 --> 01:01:17.510 immer noch diese ganzen Probleme 01:01:17.510 --> 01:01:20.030 und Deadlocks und 01:01:20.030 --> 01:01:21.950 Race Conditions und lauter anderes. Und das 01:01:21.950 --> 01:01:24.410 ist einfach eine schwierige 01:01:24.410 --> 01:01:26.310 Sache. Ich habe kurz, ich habe eben nachgeguckt, 01:01:26.410 --> 01:01:28.090 es gibt in PyEnv gibt es eine 01:01:28.090 --> 01:01:30.170 3.13.0 Version und es gibt eine 01:01:30.170 --> 01:01:31.770 3.13.0T Version. 01:01:33.130 --> 01:01:34.370 Und das werden die beiden 01:01:34.370 --> 01:01:35.150 und der Schädlichen sein. 01:01:36.990 --> 01:01:38.330 Gut, dann muss ich jetzt Boomer installieren. 01:01:38.810 --> 01:01:40.130 Genau, und dann muss man ein altes Skript 01:01:40.130 --> 01:01:41.010 vom Chaosdorf finden. 01:01:43.610 --> 01:01:44.270 Es war 01:01:44.270 --> 01:01:46.170 nicht so ein beeindruckendes 01:01:46.170 --> 01:01:47.590 Testhahn. Es war einfach nur 01:01:47.590 --> 01:01:50.330 zwei Threads, die eine Variable gleichzeitig 01:01:50.330 --> 01:01:52.070 erhöht haben. Also das kann man relativ 01:01:52.070 --> 01:01:54.430 leicht wieder rekonstruieren. 01:01:54.570 --> 01:01:55.290 Ja, ich sehe das auch so. 01:01:57.050 --> 01:01:57.610 Ich bin, 01:01:58.270 --> 01:02:00.050 ich habe so sehr gemischte Gefühle, 01:02:00.050 --> 01:02:01.910 was das Free-Threading angeht. Einerseits ist es halt 01:02:01.910 --> 01:02:04.070 cool, weil endlich diese endlose Diskussion 01:02:04.070 --> 01:02:05.950 aufhören auf der einen Seite und weil halt auch 01:02:05.950 --> 01:02:07.870 wirklich jemand mal Geld in die Hand genommen hat und das 01:02:07.870 --> 01:02:09.630 richtig gut macht. Also 01:02:09.630 --> 01:02:12.050 richtig gut, klar, da kann man dann auch Details 01:02:12.050 --> 01:02:13.710 kritisieren, aber die Tatsache, dass jetzt eben 01:02:13.710 --> 01:02:15.890 irgendwie einige Leute 01:02:15.890 --> 01:02:17.950 von Meta dafür bezahlt werden, das 01:02:17.950 --> 01:02:19.950 halt wirklich zu machen und auch 01:02:19.950 --> 01:02:22.310 quasi den Aufwand 01:02:22.310 --> 01:02:23.930 betreiben, das in C-Python reinzukriegen, was ja 01:02:23.930 --> 01:02:25.950 auch wirklich immer viele Diskussionen 01:02:25.950 --> 01:02:27.770 und viel Überzeugungsarbeit und viel 01:02:27.770 --> 01:02:30.010 Debugging und sehr, sehr viel Aufwand 01:02:30.010 --> 01:02:32.270 sind 01:02:32.270 --> 01:02:34.450 dafür nötig und ich finde es erstmal gut, 01:02:34.590 --> 01:02:36.190 dass das halt jetzt passiert und 01:02:36.190 --> 01:02:38.290 dass quasi auch die 01:02:38.290 --> 01:02:40.330 Community mitgenommen wird und irgendwie 01:02:40.330 --> 01:02:42.410 verschiedene, also es gibt ja 01:02:42.410 --> 01:02:44.150 jetzt wirklich auch schon einige an Bibliotheken, 01:02:44.310 --> 01:02:46.130 die jetzt mitziehen und gucken, dass sie halt auch 01:02:46.130 --> 01:02:48.110 FreeThreading-Versionen dann 01:02:48.110 --> 01:02:50.250 Binary auf PyPI releasen 01:02:50.250 --> 01:02:52.090 und so weiter. Und das 01:02:52.090 --> 01:02:54.150 ist schon wirklich 01:02:54.150 --> 01:02:56.230 gut. Klar, auf der anderen Seite sehe ich 01:02:56.230 --> 01:02:58.230 das, ich denke 01:02:58.230 --> 01:02:59.270 wirklich, das wird 01:02:59.270 --> 01:03:02.250 eine Riesenumstellung und das wird schon auch 01:03:02.250 --> 01:03:03.890 was die Bugs angeht und was die 01:03:03.890 --> 01:03:05.990 Eingewöhnungszeit angeht und 01:03:05.990 --> 01:03:08.390 sowohl in den Bibliotheken als auch in der 01:03:08.390 --> 01:03:08.930 Sprache selbst. 01:03:10.230 --> 01:03:12.530 Ich habe mal so einen, das ist schon ewig her, 01:03:12.570 --> 01:03:14.150 aber ich habe mal einen Vortrag gehört von einem 01:03:14.150 --> 01:03:14.850 der 01:03:14.850 --> 01:03:18.390 Sun JVM JIT-Entwickler, 01:03:18.490 --> 01:03:20.150 der auch in einem ganzen Laufzeitsystem 01:03:20.150 --> 01:03:22.130 und dem 01:03:22.130 --> 01:03:24.490 Multithreaded Garbage Collector 01:03:24.490 --> 01:03:26.090 und so gearbeitet hat und der meinte so, 01:03:26.830 --> 01:03:28.470 im Garbage Collector findet man halt 01:03:28.470 --> 01:03:30.110 zehn Jahre lang Multithreading-Bugs 01:03:30.110 --> 01:03:32.510 und die werden halt immer schwieriger 01:03:32.510 --> 01:03:34.230 zu finden und 01:03:34.230 --> 01:03:36.810 ich weiß halt nicht so genau, ob 01:03:36.810 --> 01:03:38.630 wir darauf so richtig gefasst sind. 01:03:38.850 --> 01:03:39.430 Also anders. 01:03:40.790 --> 01:03:40.970 Ja. 01:03:42.450 --> 01:03:44.570 Naja gut, hat halt ein bisschen 01:03:44.570 --> 01:03:46.490 Zeit noch populärer zu werden, dann steigt 01:03:46.490 --> 01:03:48.410 die Wahrscheinlichkeit, dass man die Bugs findet, das ist doch gut. 01:03:48.870 --> 01:03:50.090 Dann kann man auch schwierige Bugs finden. 01:03:51.230 --> 01:03:52.610 Ist jetzt schon auf dem Tyobi-Index 01:03:52.610 --> 01:03:53.010 ganz oben. 01:03:53.950 --> 01:03:56.330 Also ich sehe es so ein bisschen, 01:03:56.330 --> 01:03:58.310 hat ein bisschen eine andere Perspektive. Ich glaube, 01:03:58.510 --> 01:04:01.050 die Möglichkeit, Multithreading 01:04:01.050 --> 01:04:03.030 zu machen, eröffnet eine ganz 01:04:03.030 --> 01:04:05.090 neue Klasse an Programmen, die man 01:04:05.090 --> 01:04:07.210 mit Python bisher nicht schreiben konnte. 01:04:07.470 --> 01:04:08.610 Spiele wolltest du bauen? 01:04:09.910 --> 01:04:10.990 Ja, Spiele sind 01:04:10.990 --> 01:04:12.830 eine, ja, aber da hast du dann immer noch 01:04:12.830 --> 01:04:14.270 die Performance-Differenz, 01:04:14.790 --> 01:04:16.610 aber gerade so 01:04:16.610 --> 01:04:18.510 verteilte Anwendungen. Das, was Meta macht, 01:04:18.630 --> 01:04:20.290 das, was halt die großen 01:04:20.290 --> 01:04:23.190 Anbieter 01:04:23.190 --> 01:04:24.870 machen, wenn man sich mal diese 01:04:24.870 --> 01:04:26.710 Erlang-Sachen anguckt aus den 80ern, 01:04:26.810 --> 01:04:31.170 die einfach viele Dinge gleichzeitig über einen Computer laufen lassen müssen, 01:04:31.330 --> 01:04:34.290 weil es nicht anders geht, da sieht man diese Klasse von Anwendungen. 01:04:35.210 --> 01:04:36.470 Das ist die eine Seite. 01:04:36.570 --> 01:04:38.750 Die andere Seite ist halt, dass die wenigsten von uns 01:04:38.750 --> 01:04:40.550 diese Klasse von Anwendungen schreiben. 01:04:42.070 --> 01:04:44.410 So ein bisschen aus Henne-und-Ei-Problem heraus. 01:04:44.410 --> 01:04:47.910 Weil wenn wir diese Klasse von Anwendungen schreiben müssten, 01:04:48.130 --> 01:04:52.290 dann müssten wir zwangsweise bisher eine andere Sprache als Python verwendet haben, 01:04:52.370 --> 01:04:53.530 weil das in Python eben nicht ging. 01:04:54.850 --> 01:04:59.150 Und deshalb sind wir Python-Entwickler 01:04:59.150 --> 01:05:02.910 nicht gewöhnt, diese Sorte Programme zu schreiben 01:05:02.910 --> 01:05:05.170 und auch nicht gewöhnt, diese Sorte Probleme zu lösen. 01:05:06.390 --> 01:05:10.210 Und das bedingt sich so ein bisschen selber. 01:05:10.370 --> 01:05:11.370 Das ist so ein Catch-22. 01:05:11.850 --> 01:05:13.830 Du kannst es erst lösen, wenn du es gelöst hast. 01:05:14.010 --> 01:05:15.630 Und um es zu lösen, musst du es erst gelöst haben. 01:05:15.650 --> 01:05:17.770 Also ich glaube wirklich, dass das nicht so super häufig ist. 01:05:17.910 --> 01:05:18.990 Also ein Fall, den ich halt, 01:05:19.210 --> 01:05:21.570 ich habe dann irgendwann mal in den Pepp auch geguckt, 01:05:22.130 --> 01:05:24.510 wo begründet wird, warum will man das eigentlich haben. 01:05:24.850 --> 01:05:46.450 Und da war zum Beispiel ein Beispiel, was ich dann auch einleuchtend fand, also es waren ein paar, aber eins ist mir jetzt noch in Erinnerung, die anderen nicht mehr. Da war es halt so, dass da irgendwie auch in Data-Science-Umfelder Firmen gesagt haben, also wir haben ein Problem und zwar haben wir hier irgendwie dicke Maschinen mit irgendwie jeder Menge GPUs drin und jetzt wollen wir die GPUs mit Bildern füttern oder sonst irgendwas. 01:05:47.170 --> 01:06:09.430 Und klar, irgendwie I.O. ist nicht so das Problem, da haben wir kein Problem mit dem GIL, aber wir müssen die jetzt auch noch so ein bisschen transformieren, müssen da irgendwie so ein bisschen das irgendwie mal so drehen oder manchmal in Badges organisieren und keine Ahnung und das machen wir halt in Python und wir müssen das schnell genug machen können, um halt die ganzen GPUs ständig mit Daten versorgen zu können. 01:06:09.430 --> 01:06:27.950 Die Dinger sind sauteuer, wenn wir da nur die Hälfte der GPUs verwenden können, dann lohnt sich das alles nicht mehr. Und jetzt haben wir ein Problem mit dem GIL, weil wir kriegen die GPUs nicht schnell genug mit den Daten gefüttert. Und eigentlich haben wir fast keine Alternative, als eine andere Programmiersprache zu nehmen, weil, was wollen wir machen? 01:06:28.810 --> 01:06:30.650 Wir können es auch nicht auf Prozesse aufteilen 01:06:30.650 --> 01:06:32.170 oder das geht auch alles nicht, weil 01:06:32.170 --> 01:06:34.370 da haben wir das gleiche Problem, dass halt der Overhead 01:06:34.370 --> 01:06:35.650 uns irgendwie 01:06:35.650 --> 01:06:38.050 das zu verteilen halt 01:06:38.050 --> 01:06:40.510 so viel Performance wegfrisst, dass wir 01:06:40.510 --> 01:06:41.890 dann die GPUs wieder nicht gefüttert kriegen. 01:06:42.450 --> 01:06:44.330 Also, tja, was sollen wir tun? 01:06:44.830 --> 01:06:46.830 Und da dachte ich, okay, das ist wirklich ein Anwendungsfall. 01:06:47.830 --> 01:06:48.510 Ja, da braucht man 01:06:48.510 --> 01:06:50.350 das wahrscheinlich. Aber 01:06:50.350 --> 01:06:52.250 ansonsten... 01:06:52.250 --> 01:06:54.250 Ja, genau, aber das ist eben diese Klasse 01:06:54.250 --> 01:06:56.010 von Problemen, die ich meinte 01:06:56.010 --> 01:06:58.610 vorhin. Und früher waren es halt Telefonverteiler, 01:06:58.810 --> 01:07:01.210 oder Netzwerkinterfaces 01:07:01.210 --> 01:07:02.590 oder keine Ahnung. 01:07:02.590 --> 01:07:04.550 Ja, aber da würde ich sagen, damit bist du mit Async 01:07:04.550 --> 01:07:06.350 schon, ich weiß auch gar nicht, ob Erlang 01:07:06.350 --> 01:07:08.030 irgendwie das auch kann. 01:07:08.730 --> 01:07:10.510 Ich bin mir gar nicht so sicher. Also ich glaube, die haben dann 01:07:10.510 --> 01:07:12.090 ja, also wenn du halt irgendwie so 01:07:12.090 --> 01:07:14.950 deine OTP... 01:07:14.950 --> 01:07:16.450 Ja, genau, die fahren auch 01:07:16.450 --> 01:07:18.450 eine Reihe von Prozessen hoch und haben dann halt 01:07:18.450 --> 01:07:20.550 eine schlaue Art irgendwie, die miteinander kommunizieren 01:07:20.550 --> 01:07:23.710 können. Und intern machen die halt 01:07:23.710 --> 01:07:24.570 einfach, das kannst du mit Falken ganz 01:07:24.570 --> 01:07:26.670 genauso machen. Startest du auch mehrere Prozesse 01:07:26.670 --> 01:07:28.430 und machst in jedem einzelnen Prozess 01:07:28.430 --> 01:07:30.450 dann irgendwie 01:07:30.450 --> 01:07:30.910 korroutieren. 01:07:32.310 --> 01:07:34.330 Das ist nur nicht so 01:07:34.330 --> 01:07:35.890 üblich, aber könnte man wahrscheinlich tun. 01:07:36.890 --> 01:07:38.750 Also ich meine, ja, diese... 01:07:38.750 --> 01:07:40.470 Async ist ja jetzt auch nicht gerade eine 01:07:40.470 --> 01:07:41.650 uralte Entwicklung. 01:07:42.030 --> 01:07:44.390 Diese Probleme gibt es ja auch schon lange. 01:07:44.490 --> 01:07:45.770 Und Async ist ja auch noch eine Version, 01:07:46.190 --> 01:07:48.570 das zu lösen. Auch mit Vor- und Nachteilen, 01:07:48.630 --> 01:07:49.210 muss man auch sagen. 01:07:49.850 --> 01:07:52.030 Ja, aber das ist auch... 01:07:52.030 --> 01:07:54.870 Aber das ist das, was ich meine. Es gibt eben... 01:07:54.870 --> 01:07:56.170 Das ist die Sicht, die ich 01:07:56.170 --> 01:07:58.350 habe. Vielleicht ist die auch falsch, ja, oder vielleicht 01:07:58.350 --> 01:07:59.550 ist die einfach nicht so weit verbreitet, aber 01:07:59.550 --> 01:08:02.170 meiner Meinung nach öffnet es eine Klasse von 01:08:02.170 --> 01:08:03.630 Programmen, die 01:08:03.630 --> 01:08:06.210 vorher nicht praktisch schreibbar waren. 01:08:07.110 --> 01:08:08.290 Und es ist ja jetzt auch so, dass wir 01:08:08.290 --> 01:08:08.590 schon 01:08:08.590 --> 01:08:12.250 eigentlich letztlich in einer sehr pragmatischen 01:08:12.250 --> 01:08:14.150 Situation sind. Also wir haben jetzt, es ist 01:08:14.150 --> 01:08:16.050 standardmäßig nicht an und wir gucken, 01:08:16.470 --> 01:08:18.570 wir haben jetzt Zeit als Community rauszufinden, 01:08:19.010 --> 01:08:20.090 gibt es Anwendungsfälle dafür, 01:08:20.190 --> 01:08:22.390 finden wir Anwendungsfälle dafür, wird es stabil genug, 01:08:22.870 --> 01:08:24.190 ist die Single-Threading-Performance 01:08:24.190 --> 01:08:26.310 akzeptabel schlechter 01:08:26.310 --> 01:08:28.150 und 01:08:28.150 --> 01:08:29.830 ziehen die ganzen Bibliotheken mit 01:08:29.830 --> 01:08:32.090 und im Moment ist das Risiko halt 01:08:32.090 --> 01:08:33.790 nicht so hoch. Also das 01:08:33.790 --> 01:08:36.210 quasi der absolute Worst Case, der passieren könnte, 01:08:36.310 --> 01:08:38.330 ist halt, wir finden in zwei Jahren raus, niemand benutzt 01:08:38.330 --> 01:08:40.330 das, das stürzt die ganze Zeit ab und 01:08:40.330 --> 01:08:42.290 Sam Groves hat keine Lust mehr 01:08:42.290 --> 01:08:44.050 und dann kann man es halt auch 01:08:44.050 --> 01:08:45.210 einfach wieder weglassen. 01:08:47.270 --> 01:08:47.910 Also was ich, 01:08:48.210 --> 01:08:50.010 würde ich nicht von ausgehen, aber also 01:08:50.010 --> 01:08:51.390 die Möglichkeit besteht halt sozusagen. 01:08:52.550 --> 01:08:53.990 Ja und wahrscheinlich haben wir, also 01:08:53.990 --> 01:08:55.850 ich meine, das hat mich jetzt auch quasi 01:08:55.850 --> 01:08:57.730 so eine andere Geschichte, diese 01:08:57.730 --> 01:08:59.230 Agent-Geschichte, es hat eine gewisse 01:08:59.230 --> 01:09:01.630 Ähnlichkeit in der Hinsicht, als 01:09:01.630 --> 01:09:03.710 dass auch das halt ein tiefgreifender Eingriff 01:09:03.710 --> 01:09:05.930 war quasi und sich erst so 01:09:05.930 --> 01:09:07.730 über die Zeit entfaltet 01:09:07.730 --> 01:09:09.550 hat, was das alles für Probleme bringt und wo es 01:09:09.550 --> 01:09:10.850 überall reingreift und so. Und das ist 01:09:10.850 --> 01:09:12.670 bis heute ist das noch nicht so, 01:09:13.010 --> 01:09:15.450 da ist immer noch Potenzial, also es ist schon 01:09:15.450 --> 01:09:17.010 viel, viel besser geworden, aber es ist immer noch so, 01:09:17.890 --> 01:09:19.550 dass da noch, das ist noch nicht ganz komplett 01:09:19.550 --> 01:09:21.550 fertig alles. Und das hat auch 01:09:21.550 --> 01:09:22.950 vor zehn Jahren oder so angefangen. 01:09:23.930 --> 01:09:25.170 Und ja, 01:09:25.430 --> 01:09:26.070 das hat 01:09:26.070 --> 01:09:29.250 ganz schön lange, ist schon ganz schön lange 01:09:29.250 --> 01:09:31.190 auf dem Weg. Und das wird wahrscheinlich 01:09:31.190 --> 01:09:32.070 da auch so sein, ja. 01:09:32.790 --> 01:09:35.170 Klar, auf jeden Fall. Es ist auf jeden Fall ein langfristiges Projekt. 01:09:35.310 --> 01:09:36.290 Das ist jetzt nichts, was wir jetzt 01:09:36.290 --> 01:09:39.530 in einer Version mal irgendwie so ein bisschen reinbasteln 01:09:39.530 --> 01:09:40.470 und dann ist das Problem gelöst. 01:09:41.630 --> 01:09:41.990 Ja. 01:09:43.030 --> 01:09:45.270 Ja, und selbst wenn das alles auf technischer Ebene 01:09:45.270 --> 01:09:47.230 einwandfrei funktioniert, dann ist halt 01:09:47.230 --> 01:09:49.330 Multithreaded Programming immer noch 01:09:49.330 --> 01:09:50.790 einfach auch eine schwierige Sache. 01:09:52.310 --> 01:09:52.770 Also die 01:09:52.770 --> 01:09:55.150 Dining Philosophers, die kann man sich 01:09:55.150 --> 01:09:57.230 gerne mal ansehen und 01:09:57.230 --> 01:09:59.130 versuchen, da eine Lösung zu schreiben. Das ist nicht so 01:09:59.130 --> 01:09:59.450 einfach. 01:10:01.490 --> 01:10:02.830 Klar. Und also ob es dann 01:10:02.830 --> 01:10:04.610 klappt. Mal schauen, ob sich Dominik fragt, was das bedeutet. 01:10:05.310 --> 01:10:07.110 Ja, ich warte nur darauf, dass du es sehr clear 01:10:07.110 --> 01:10:07.290 hast. 01:10:10.450 --> 01:10:11.090 Die Dining 01:10:11.090 --> 01:10:12.770 Philosophers sind ein Gedankenexperiment, 01:10:13.050 --> 01:10:14.850 wo du fünf 01:10:14.850 --> 01:10:17.050 Menschen an einem Tisch sitzen hast 01:10:17.050 --> 01:10:18.910 und die wollen Spaghetti essen und zum Spaghetti 01:10:18.910 --> 01:10:20.290 essen braucht man zwei Gabeln. 01:10:20.730 --> 01:10:21.650 Spaghetti is Dining. 01:10:22.470 --> 01:10:24.010 Ja, okay. Ja, zwei Gabeln. 01:10:24.310 --> 01:10:25.290 Very fine dining. 01:10:26.670 --> 01:10:28.130 Und auch geteilte Gabeln 01:10:28.130 --> 01:10:29.970 ist auch absolut, es gibt es nur 01:10:29.970 --> 01:10:31.970 in den nobelsten Restaurants, weil 01:10:31.970 --> 01:10:33.790 jeder von denen hat nur eine Gabel. 01:10:34.770 --> 01:10:36.070 Also bei jedem Teller liegt 01:10:36.070 --> 01:10:38.030 eine, zwischen zwei Tellern liegt immer eine Gabel. 01:10:38.210 --> 01:10:40.090 Also ein Philosoph hat eine Gabel rechts von links 01:10:40.090 --> 01:10:42.050 und eine links von sich, aber 01:10:42.050 --> 01:10:44.330 auf diese Gabel haben immer zwei Menschen Zugriff. 01:10:45.510 --> 01:10:45.830 Und 01:10:45.830 --> 01:10:47.850 jetzt wollen die alle Spaghetti essen und 01:10:47.850 --> 01:10:49.370 brauchen dafür zwei Gabeln. 01:10:50.970 --> 01:10:51.810 Offensichtlich können die 01:10:51.810 --> 01:10:53.270 nicht alle gleichzeitig Spaghetti essen. 01:10:54.310 --> 01:10:59.810 Weil es gibt nur fünf Gabeln, wenn jeder zwei Gabeln braucht, bräuchten sie zehn Gabeln. 01:10:59.950 --> 01:11:01.490 Das ist also so ein Ressourcenproblem. 01:11:02.230 --> 01:11:11.690 Das viel schlimmere Problem ist aber, dass man da ganz einfach diese ganzen Probleme visualisieren kann, die auftreten können. 01:11:11.790 --> 01:11:15.370 Selbst wenn dieses System auf einer technischen Ebene einwandfrei funktioniert. 01:11:15.430 --> 01:11:21.690 Also du meinst zum Beispiel, die haben alle eine große Schüssel Spaghetti und die haben gleichzeitig zwei Enden einer langen Spaghetti im Mund, weil die... 01:11:22.670 --> 01:11:43.310 Das ist das Disney, die Disney-Variante, ne, die meine ich jetzt hier an der Stelle nicht, aber ja. Zum Beispiel, wenn man ganz naiv sagt, wenn ein Philosoph Spaghetti essen möchte, dann greift er zuerst mit seiner rechten Hand nach einer Gabel und dann mit der linken Hand nach einer Gabel und wenn da eine Gabel nicht liegt, dann wartet er halt in dem Zustand, in dem er gerade ist, bis die Gabeln verfügt. 01:11:43.310 --> 01:11:46.810 Also sitzen da irgendwelche Leute, die haben alle eine Gabel in der Hand und warten darauf, dass sie in die zweite kommen. 01:11:47.250 --> 01:12:01.170 Genau, also im schlimmsten Fall greift jeder nach der rechten Gabel und wartet dann auf die linke Gabel, die aber durch den Philosoph zu seiner Linken schon belegt ist. Und die warten dann alle aufeinander und müssen für immer an diesem Tisch sitzen und verhungern, vor dem vollen Teller. 01:12:01.470 --> 01:12:02.290 Deadlock quasi. 01:12:02.530 --> 01:12:08.650 Und das ist ja eine extrem simple Situation, das ist ja eine extrem vereinfachte Sichtweise. 01:12:08.670 --> 01:12:12.010 Du meinst, wir müssen miteinander reden und sagen, gib mir mal eine Gabel, bitte. 01:12:12.310 --> 01:12:22.990 Ja, aber tatsächlich, Threads, die kommunizieren, sind ja auch was extrem Schwieriges, insbesondere wenn die gerade auf einen Lock warten, weil üblicherweise, wenn so ein Thread auf einen Lock wartet, kann er ja derweil nichts anderes machen. 01:12:23.130 --> 01:12:25.190 Das ist dann blöd. Hat den Mund schon voll. 01:12:25.430 --> 01:12:33.390 Genau, das ist blöd. Und jetzt muss man eben anfangen, wie kriegt man das in den Griff, wie kann man das im Allgemeinen lösen, dass die keine Deadlocks machen. 01:12:33.550 --> 01:12:34.350 Mehr Karten verteilen? 01:12:35.270 --> 01:12:50.770 Ja, das wäre eine Möglichkeit, aber normalerweise ist das schwierig. Also zum Beispiel in dem Modell vom Jochen einfach mehr GPUs einbauen, ist prinzipiell eine Lösung. Ist nicht ganz billig. Und es sind halt goldene Gabeln, mehr Gabeln geht nicht. 01:12:52.350 --> 01:13:12.510 Ja, es ist einfach ein Gedankenmodell, um nachzuweisen, dass auf dieser ganz simplen Ebene schon Probleme auftreten, die ungeheuer schwierig zu lösen sind und ungeheuer schwierig in ihrer Allgemeinheit zu lösen sind. Und wenn du sagst, okay, dann habe ich eine Lösung gefunden für fünf, was ist, wenn du da sechs Philosophen sitzen hast oder tausend oder nur zwei? Geht deine Lösung dann immer noch? 01:13:12.510 --> 01:13:14.470 Also schon allein die Tatsache, dass quasi 01:13:14.470 --> 01:13:16.690 einer der schwierigsten Probleme bei verteilten 01:13:16.690 --> 01:13:17.910 Systemen ein Counter ist, 01:13:18.770 --> 01:13:20.570 das ist ja eigentlich auch schon 01:13:20.570 --> 01:13:21.570 relativ lustig so. 01:13:23.770 --> 01:13:25.010 Eine Zahl hochzählen. 01:13:25.030 --> 01:13:26.850 Genau, eine Zahl hochzählen, aber so global 01:13:26.850 --> 01:13:28.390 konsistent und so, das ist wirklich 01:13:28.390 --> 01:13:30.690 auch, schon das ist nicht so einfach. 01:13:30.850 --> 01:13:33.030 Ja, kennt ihr das, wenn irgendwie an so einem Festival-Eingang 01:13:33.030 --> 01:13:34.730 irgendwer stehen muss mit so einem Klicker, 01:13:35.130 --> 01:13:36.630 wenn man draufdrückt, muss jemand reinrennen oder wenn man 01:13:36.630 --> 01:13:38.150 an der anderen Hand jemand rausrennt, 01:13:38.570 --> 01:13:40.610 also ich bin ja auch so sicher, der verdrückt sich die ganze Zeit 01:13:40.610 --> 01:13:42.670 Irgendwann, man weiß gar nicht so genau, wie viele Leute 01:13:42.670 --> 01:13:44.130 sind eigentlich auf dem Gelände, sondern es ist wahrscheinlich 01:13:44.130 --> 01:13:45.910 ein ähnliches Problem. Wenn es so 18 Eingänge sind, 01:13:46.170 --> 01:13:48.530 dann finden die dann raus, jetzt sind 01:13:48.530 --> 01:13:50.570 gerade minus 10 Leute bei uns auf dem Festival. 01:13:51.430 --> 01:13:53.010 Das ist doch die klassische 01:13:53.010 --> 01:13:54.430 mathematische Mengenlehre, wenn 01:13:54.430 --> 01:13:56.710 drei Leute reingehen und fünf rausgehen, 01:13:56.770 --> 01:13:58.290 müssen zwei wieder reingehen, damit es leer ist. 01:13:58.350 --> 01:13:59.870 Und der Kirchturm ist minus 30 Meter hoch. 01:14:03.750 --> 01:14:04.730 Ja, okay, 01:14:04.970 --> 01:14:06.510 also Threading ist 01:14:06.510 --> 01:14:08.410 eine Riesensache. Man kann es ja mal positiv ausdrücken. 01:14:08.410 --> 01:14:10.410 Die Hoffnung ist, dass es jetzt eben ganz, ganz tolle 01:14:10.410 --> 01:14:12.510 Abstraktionen geben wird, die dann auf 01:14:12.510 --> 01:14:14.990 der quasi Low-Level-Basis 01:14:14.990 --> 01:14:16.810 von Threads 01:14:16.810 --> 01:14:18.550 und Logs und was weiß ich, was es dann 01:14:18.550 --> 01:14:20.430 eben an Infrastruktur gibt oder 01:14:20.430 --> 01:14:22.390 geben wird, die das 01:14:22.390 --> 01:14:24.370 unwahrscheinlicher machen, dass wir Deadlogs produzieren. 01:14:24.770 --> 01:14:26.350 Das ist die positive Sicht. Das wäre 01:14:26.350 --> 01:14:26.850 sehr schön. 01:14:28.230 --> 01:14:30.330 Und das kriegen wir bestimmt hin, weil die 01:14:30.330 --> 01:14:32.230 Python-Community ist großartig und die 01:14:32.230 --> 01:14:34.390 zeigt immer wieder, was sie für geniale Lösungen 01:14:34.390 --> 01:14:36.330 findet. War das jetzt sarkastisch 01:14:36.330 --> 01:14:36.770 oder nicht? 01:14:38.750 --> 01:14:40.290 Die Zeit wird es zeigen. 01:14:40.410 --> 01:14:44.290 Das möchte ich in Folge 01:14:44.290 --> 01:14:45.530 600 besprechen. 01:14:47.990 --> 01:14:49.130 Es ist schon so, also 01:14:49.130 --> 01:14:52.270 ich bin immer wieder überrascht. Ich meine, wir haben ja hier 01:14:52.270 --> 01:14:54.170 in dieser Runde immer wieder den Pick, wo 01:14:54.170 --> 01:14:56.230 wir auf Sachen zeigen, die 01:14:56.230 --> 01:14:57.850 in der Python-Welt passieren oder auch außerhalb, 01:14:58.650 --> 01:15:00.230 die einfach geniale Dinge sind, die 01:15:00.230 --> 01:15:01.930 keiner wusste. Ich mache auch 01:15:01.930 --> 01:15:04.070 gelegentlich Python-Schulungen für 01:15:04.070 --> 01:15:06.010 Anfänger. Und eine 01:15:06.010 --> 01:15:07.950 Sache, die wir da machen, ist einfach mal durch 01:15:07.950 --> 01:15:09.710 die Standardbibliothek scrollen. 01:15:10.410 --> 01:15:11.990 Und gucken, was es da so alles gibt. 01:15:12.130 --> 01:15:16.250 Und da findet man immer Sachen, die spannend sind und neu und interessant. 01:15:16.830 --> 01:15:19.310 Und ich finde, das gehört schon auch irgendwie so ein bisschen 01:15:19.310 --> 01:15:22.170 zur Python-Welt dazu, dass es immer mehr Dinge gibt 01:15:22.170 --> 01:15:25.650 und immer viele schöne neue Sachen und neue Bibliotheken, 01:15:25.730 --> 01:15:27.330 die Dinge tun, von denen man noch nicht mal wusste, 01:15:27.390 --> 01:15:28.430 dass man sie gebraucht hat bisher. 01:15:29.450 --> 01:15:31.270 Du wolltest gerade picken, hast du damit gesagt schon? 01:15:32.230 --> 01:15:32.850 Noch nicht. 01:15:33.150 --> 01:15:35.490 Vor allem, ich habe diese Woche oder dieses Mal 01:15:35.490 --> 01:15:37.370 gar keinen Python-Pick dabei, aber das macht ja nichts. 01:15:37.850 --> 01:15:38.330 Kein Python. 01:15:38.430 --> 01:15:39.730 Es ist einfach nur ein Hinweis darauf, 01:15:39.830 --> 01:15:41.630 dass es viele tolle Dinge gibt, die man nicht kennt. 01:15:41.710 --> 01:15:43.990 Ja, und wenn man jetzt von der Schnabelpolitik weggeht 01:15:43.990 --> 01:15:46.050 und sich mal die Top 100 bei PI anschaut 01:15:46.050 --> 01:15:47.390 oder so, dann wird es dann auch mal irgendwie 01:15:47.390 --> 01:15:49.870 also so die Bandbreite, was 01:15:49.870 --> 01:15:51.830 für verschiedene Themen es so gibt, ist 01:15:51.830 --> 01:15:54.270 schon immer wieder sehr beeindruckend. 01:15:54.270 --> 01:15:56.230 Ja, aber 01:15:56.230 --> 01:15:58.190 das ist versehentlich 01:15:58.190 --> 01:16:00.090 total gute Überleitung, weil in der 01:16:00.090 --> 01:16:02.190 3.13 wurden ja auch Sachen entfernt. 01:16:02.230 --> 01:16:04.430 Und die 01:16:04.430 --> 01:16:05.770 Liste ist gar nicht so klein. 01:16:06.350 --> 01:16:08.310 Das ist übrigens auch da wieder so ein bisschen 01:16:08.310 --> 01:16:10.510 Geschichte. Das ist 01:16:10.510 --> 01:16:12.810 ein gefühlt jahrzehntelanges 01:16:12.810 --> 01:16:14.570 Projekt, so ein paar von diesen Sachen. 01:16:14.890 --> 01:16:16.350 Also das wurde mal 01:16:16.350 --> 01:16:18.330 auf einem C-Python 01:16:18.330 --> 01:16:20.530 Core-Developer-Treffen 01:16:20.530 --> 01:16:22.390 in einem Vortrag empfohlen, der 01:16:22.390 --> 01:16:24.390 damals mit sehr gemischten 01:16:24.390 --> 01:16:25.870 Reaktionen aufgenommen wurde. 01:16:27.610 --> 01:16:28.130 Und 01:16:28.130 --> 01:16:30.430 es hat ewig gedauert, bis das jetzt wirklich 01:16:30.430 --> 01:16:31.990 passiert ist, dass der Bibliotheken jetzt 01:16:31.990 --> 01:16:33.090 entfernt wurden. 01:16:34.630 --> 01:16:36.590 Die Motivation ist, dass es halt quasi so ein bisschen 01:16:36.590 --> 01:16:37.890 Code in der Standardbibliothek 01:16:37.890 --> 01:16:39.950 gab, der einfach 01:16:39.950 --> 01:16:42.070 sehr veraltet ist 01:16:42.070 --> 01:16:43.190 und nicht mehr so richtig 01:16:43.190 --> 01:16:46.250 für aktuelle Probleme zu benutzen 01:16:46.250 --> 01:16:48.350 ist. Und die wurden dann eben 01:16:48.350 --> 01:16:50.110 zuerst deprecated 01:16:50.110 --> 01:16:51.930 und jetzt seit ein paar Versionen und jetzt eben 01:16:51.930 --> 01:16:53.130 wirklich wurden ein paar entfernt. 01:16:54.110 --> 01:16:55.790 Ja, wir können die Liste einfach mal, 01:16:55.870 --> 01:16:57.790 ich habe die Liste zufällig vor mir. 01:16:59.230 --> 01:17:00.050 Rein zufällig. 01:17:04.210 --> 01:17:05.990 Diese Anstrengung 01:17:05.990 --> 01:17:07.470 heißt Removing Dead Batteries. 01:17:07.890 --> 01:17:11.590 und die entfernt folgende Module 01:17:11.590 --> 01:17:13.390 AIFC, Audio-Op, 01:17:13.570 --> 01:17:15.330 Chunk, CGI, CGI-TP, 01:17:15.610 --> 01:17:17.190 Crypt, Image-Header, 01:17:17.510 --> 01:17:19.450 Mail-Cap, MSI-Lib, NIS, 01:17:19.870 --> 01:17:21.670 NETP-Lib, OSS-Audio-Dev, 01:17:22.130 --> 01:17:23.770 Pipes, Sound-Header, 01:17:24.410 --> 01:17:25.770 SPWD, SunAU, 01:17:26.010 --> 01:17:27.750 Telnet-Lib, UU, XDR-Lib 01:17:27.750 --> 01:17:29.170 und Libs 2-3. 01:17:30.630 --> 01:17:31.930 Falls es jetzt konstruktiv gefallen 01:17:31.930 --> 01:17:33.490 sei, weil euer Paket auf einmal weg ist, 01:17:33.710 --> 01:17:35.070 dann solltet ihr aufpassen mit dem Update. 01:17:35.610 --> 01:17:37.570 Genau, also wenn da jetzt was dabei war, was ihr gerne 01:17:37.570 --> 01:17:39.290 haben wir. Ich glaube, die landen da auf PyPI. 01:17:40.490 --> 01:17:41.530 Ja, ja, die gibt es doch. 01:17:42.030 --> 01:17:43.550 Was CPython ja nur erreichen 01:17:43.550 --> 01:17:45.470 will, ist, dass sie die nicht mehr maintainen. 01:17:45.770 --> 01:17:47.430 Nicht, dass die jetzt verboten 01:17:47.430 --> 01:17:49.270 sind und auf gar keinen Fall mehr von irgendjemand 01:17:49.270 --> 01:17:49.970 verboten. 01:17:51.370 --> 01:17:53.450 Ja klar, es geht nur darum, dass man die nicht die ganze Zeit 01:17:53.450 --> 01:17:55.530 mitschleifen muss, weil das ist ja auch Aufwand, 01:17:56.190 --> 01:17:57.550 die in der neuen Version mitzunehmen. 01:17:58.230 --> 01:17:59.330 Aber also bei einem 01:17:59.330 --> 01:18:01.550 Großteil dieser Bibliotheken weiß ich nicht, was die tun. 01:18:02.270 --> 01:18:03.190 Ja, man kann so ein bisschen raten, 01:18:03.310 --> 01:18:04.850 aber bei ein paar kann man nicht mal raten. 01:18:04.890 --> 01:18:06.410 Ja, bei manchen, ja, 01:18:07.110 --> 01:18:09.390 Was, keine Ahnung, NNTP-Lib 01:18:09.390 --> 01:18:10.750 macht, okay gut, das ist NNTP-Lib. 01:18:10.750 --> 01:18:13.270 CGI macht, das weiß ich auch noch, weil wir alt sind. 01:18:14.250 --> 01:18:15.430 Ja, gut, da sind wir. 01:18:15.550 --> 01:18:16.950 Aber wüsstest du jetzt den Unterschied zwischen 01:18:16.950 --> 01:18:18.210 CGI und CGI-TP? 01:18:19.510 --> 01:18:20.950 Ich glaube, das eine ist der Trace-Pack. 01:18:22.230 --> 01:18:22.950 Ja, aber 01:18:22.950 --> 01:18:24.470 Turbo. 01:18:25.090 --> 01:18:27.170 SunAU ist so ein altes Audio-Format, oder? 01:18:27.490 --> 01:18:29.230 Ja, ich glaube auch. Oh, MSI-Lib 01:18:29.230 --> 01:18:31.650 für Microsoft-Installer-Dateien, 01:18:31.650 --> 01:18:33.310 auch großartig. 01:18:36.570 --> 01:18:38.610 Kennt ihr die meist untergeladene Datei 01:18:38.610 --> 01:18:39.510 auf PyPI? 01:18:42.030 --> 01:18:42.650 Irgendwas mit 01:18:42.650 --> 01:18:43.950 Setup-Tools oder ich weiß nicht. 01:18:44.910 --> 01:18:45.830 Okay, keine Ahnung. 01:18:47.350 --> 01:18:48.410 Also auf jeden Fall das Richtige, 01:18:48.510 --> 01:18:48.850 diese Sachen. 01:18:49.870 --> 01:18:51.890 Es gibt so eine Liste, die sagt Botro 3. 01:18:52.650 --> 01:18:53.890 Ah, oh, das liegt, ach ja, 01:18:54.210 --> 01:18:56.070 das liegt in den Updaten irgendwie 01:18:56.070 --> 01:18:57.710 alle zwei Stunden und 01:18:57.710 --> 01:19:00.590 da das halt irgendwie eines der Hauptdinger 01:19:00.590 --> 01:19:02.530 ist, dass du halt brauchst, 01:19:02.530 --> 01:19:03.550 wenn du irgendwas mit 01:19:03.550 --> 01:19:05.970 irgendwie AWS oder so machst. 01:19:06.570 --> 01:19:10.530 Die drittbestes Boto-Core? 01:19:11.470 --> 01:19:12.730 Ja, ja, das ist alles so. 01:19:12.770 --> 01:19:13.290 Und Platz 2? 01:19:13.590 --> 01:19:16.450 Ja, aber ist das nicht der Grund, warum Pipe.ai keine Statistiken mehr anzeigt? 01:19:17.030 --> 01:19:17.250 Naja. 01:19:18.070 --> 01:19:20.330 Also da könnte man jetzt denken, das wäre irgendwie wichtig, 01:19:20.450 --> 01:19:21.390 aber das ist halt überhaupt gar nichts. 01:19:21.450 --> 01:19:23.270 Warum zeigen die keine Statistiken mehr an? 01:19:24.110 --> 01:19:26.490 Weil die nicht trennen können, 01:19:26.750 --> 01:19:28.690 ob das jetzt ein Mirror ist oder ein automatisches 01:19:28.690 --> 01:19:30.530 Update oder jemand, der die Bibliothek tatsächlich 01:19:30.530 --> 01:19:32.410 in einem Projekt installieren möchte und deshalb 01:19:32.410 --> 01:19:33.510 sind diese Zahlen völlig verdient. 01:19:33.510 --> 01:19:35.490 Also du willst sagen, weil Counter halt zu schwierig sind. 01:19:36.110 --> 01:19:39.510 Und nicht nur in der Benutzung, 01:19:39.670 --> 01:19:41.170 sondern auch in der Interpretation. 01:19:41.730 --> 01:19:43.470 Ja, ich meine, 01:19:43.530 --> 01:19:45.270 die Zahl der Downloader ist auch irgendwie so ein bisschen 01:19:45.270 --> 01:19:46.890 weird. 01:19:48.070 --> 01:19:49.550 1,5 Milliarden 01:19:49.550 --> 01:19:53.430 Die Zahl, die da rauskommt, ist halt, wie oft 01:19:53.430 --> 01:19:55.450 das geupdatet wird, ist auf jeden Fall ein Faktor, 01:19:55.450 --> 01:19:56.850 mit dem da multipliziert wird. 01:19:57.850 --> 01:19:59.470 Ja, ich meine, aber das ist 01:19:59.470 --> 01:20:01.350 ja jetzt nicht irgendwie eine gute Sache, wenn da irgendwie 01:20:01.350 --> 01:20:03.370 alle paar Minuten Pakete 01:20:03.370 --> 01:20:05.330 irgendwie die Version hochzählt. 01:20:05.890 --> 01:20:07.270 Aber wenn das dann irgendwie in den 01:20:07.270 --> 01:20:09.310 CIs, quasi in so 01:20:09.310 --> 01:20:11.570 Continuous Integration Pipelines 01:20:11.570 --> 01:20:13.450 verwendet wird, dann wird das halt gnadenlos 01:20:13.450 --> 01:20:14.870 neu runtergeladen, wenn sich da irgendwas ändert. 01:20:15.150 --> 01:20:16.550 Also, ja, naja. 01:20:17.610 --> 01:20:19.070 Ja, wahrscheinlich braucht man irgendein anderes 01:20:19.070 --> 01:20:23.150 Metric KPI 01:20:23.150 --> 01:20:25.070 für irgendwie, ist das jetzt 01:20:25.070 --> 01:20:26.990 irgendwie interessant oder nicht? Aber ich weiß auch nicht, welche. 01:20:27.470 --> 01:20:27.930 Github-Sterne. 01:20:30.510 --> 01:20:31.310 Auch schwierig. 01:20:34.450 --> 01:20:34.810 Metric 01:20:34.810 --> 01:20:35.930 KPIs. 01:20:36.790 --> 01:20:36.950 Ja. 01:20:38.330 --> 01:20:40.170 Es wurde schon mal in einem Podcast erwähnt. 01:20:41.010 --> 01:20:42.530 Vielleicht sollten wir da sowas auch 01:20:42.530 --> 01:20:44.830 so eine Quartettserie 01:20:44.830 --> 01:20:45.270 von machen. 01:20:46.530 --> 01:20:48.870 Von den PIPI-Bibliotheken. 01:20:49.570 --> 01:20:50.550 Ja, genau. Hast du ein 01:20:50.550 --> 01:20:52.750 Quartett mit vier, die besten PIPI-Bibliotheken 01:20:52.750 --> 01:20:54.710 oder irgendwas mit den KPIs, kannst du 01:20:54.710 --> 01:20:56.490 die ganzen Module da reinbauen, dann kannst du dich 01:20:56.490 --> 01:20:58.730 gegeneinander, wer denn kennt, könnt ihr das? 01:20:59.010 --> 01:20:59.950 Also meins hat 01:20:59.950 --> 01:21:02.150 1,5 Milliarden Downloads. 01:21:02.810 --> 01:21:04.790 Aha, 798 01:21:04.790 --> 01:21:06.170 sich Megabyte. Mehr Kilobyte größer, genau. 01:21:09.390 --> 01:21:10.530 Und Anzahl der Releases 01:21:10.530 --> 01:21:11.250 wäre doch auch ein gutes. 01:21:14.190 --> 01:21:14.950 Offene Issues. 01:21:16.970 --> 01:21:18.330 Ist es besser, wenn es höher ist? 01:21:19.550 --> 01:21:19.950 Tja. 01:21:21.310 --> 01:21:22.190 Genau, aber 01:21:22.190 --> 01:21:24.070 um auf die Dead Batteries zurückzukommen, 01:21:24.310 --> 01:21:26.370 ich verstehe es auch, dass es gut ist, 01:21:26.370 --> 01:21:27.190 wenn die entfernt werden. 01:21:28.090 --> 01:21:28.590 Ja, absolut. 01:21:30.370 --> 01:21:32.370 Aber es wird da sicherlich die Leute geben, 01:21:32.530 --> 01:21:33.330 die sagen, nein, 01:21:34.310 --> 01:21:35.850 wie soll ich sonst je meine 01:21:35.850 --> 01:21:38.710 wie soll ich das Detail nicht verwenden? 01:21:40.130 --> 01:21:41.330 Ja, aber die hätten ja jetzt auch schon 01:21:41.330 --> 01:21:42.990 eine ganze Zeit lang Zeit irgendwie da was 01:21:42.990 --> 01:21:44.370 und ich glaube auch nicht, 01:21:44.510 --> 01:21:47.110 da ist auch nichts zu uns passiert. 01:21:48.290 --> 01:21:49.090 Ja, ich weiß nicht, 01:21:49.470 --> 01:21:51.310 haben wir vielleicht nur so kleinere Dinge 01:21:51.310 --> 01:21:52.250 oder ich weiß es nicht genau, 01:21:52.550 --> 01:21:54.290 gab es noch irgendwas Interessantes? 01:21:54.990 --> 01:21:55.630 Typing, ja. 01:21:56.430 --> 01:21:58.470 Ein Typing-Simple-Namespace, wolltest du sagen? 01:21:59.630 --> 01:22:00.350 Das kannte ich noch gar nicht, 01:22:00.430 --> 01:22:02.230 ich weiß gar nicht, welche Version das war. 01:22:03.170 --> 01:22:05.030 aber... Ja, du kannst 01:22:05.030 --> 01:22:07.030 es auch nicht. Okay. Ja, ich kann es auch 01:22:07.030 --> 01:22:08.990 nicht. Simple Namespace 01:22:08.990 --> 01:22:11.210 ist ein Dikt, dass man wie Attribute 01:22:11.210 --> 01:22:12.850 dann die Keys benutzen kann. 01:22:14.030 --> 01:22:15.250 So ein bisschen so ein Name-Tuppe. 01:22:15.710 --> 01:22:16.870 Und da 01:22:16.870 --> 01:22:19.130 hat CF gesagt, oh, das ist aber ganz 01:22:19.130 --> 01:22:20.890 schwierig, weil da ständig irgendwas kaputt geht 01:22:20.890 --> 01:22:22.910 und hat dann auch Enum in den Raum 01:22:22.910 --> 01:22:24.990 geworfen. Das würde ich gerne noch mal kurz 01:22:24.990 --> 01:22:27.090 hören und verstehen, warum das so blöd ist. 01:22:27.430 --> 01:22:28.930 Ich habe doch schon gesagt, dass ich das zensieren will. 01:22:29.950 --> 01:22:30.590 Nee, wir haben 01:22:30.590 --> 01:22:32.370 so ein bisschen darüber geredet, welche 01:22:32.370 --> 01:22:35.210 Standard-Bibliotheks-Module 01:22:35.210 --> 01:22:37.090 uns als Piper-Entwicklern 01:22:37.090 --> 01:22:38.890 irgendwie besonders oft Probleme bereiten 01:22:38.890 --> 01:22:40.850 und Inam ist da immer mal 01:22:40.850 --> 01:22:41.690 wieder so ein 01:22:41.690 --> 01:22:44.750 wie heißt es? Eine eierliegende 01:22:44.750 --> 01:22:45.890 Wollmilchsau. Ein Problembär. 01:22:47.350 --> 01:22:48.230 Also Inam 01:22:48.230 --> 01:22:50.650 benutzt einfach ganz, ganz viele Tricks des 01:22:50.650 --> 01:22:52.510 Python-Datenmodells und Metaklassen und 01:22:52.510 --> 01:22:52.910 irgendwie 01:22:52.910 --> 01:22:57.070 schafft es immer wieder Randfälle 01:22:57.070 --> 01:22:59.090 zu erwischen, 01:22:59.090 --> 01:23:01.210 die wir dann doch nicht so ganz korrekt implementiert 01:23:01.210 --> 01:23:02.170 haben und da müssen wir erstmal, 01:23:03.150 --> 01:23:05.090 wenn wir, was weiß ich, zu einer 01:23:05.090 --> 01:23:06.930 neuen CPython-Version die Standardbibliothek 01:23:06.930 --> 01:23:09.030 dann übernehmen, müssen wir 01:23:09.030 --> 01:23:10.650 erstmal irgendwelche Python 01:23:10.650 --> 01:23:13.270 Datenmodell-Core-Features fixen, 01:23:13.330 --> 01:23:15.250 bevor ihr ihn dann halt auch nur importiert oder so. 01:23:16.390 --> 01:23:17.050 Genau, und NameTuple 01:23:17.050 --> 01:23:18.990 ist da auch ein Problem, nicht so richtig, weil das 01:23:18.990 --> 01:23:20.850 irgendwie 01:23:20.850 --> 01:23:23.190 einen Bugs hat, sondern weil das oft Performance-Bugs 01:23:23.190 --> 01:23:25.070 hat. Ja, mit der Tuple und langsam, das war 01:23:25.070 --> 01:23:27.030 mir auch neu. Ja, NameTuple benutzt 01:23:27.030 --> 01:23:28.550 halt quasi, wenn man so einen neuen 01:23:28.550 --> 01:23:31.010 NameTuple-Typ anlegt, dann 01:23:31.010 --> 01:23:32.670 da wird halt auch mit exec dann irgendwie 01:23:32.670 --> 01:23:34.990 mit Strings irgendwelche Python-Code generiert 01:23:34.990 --> 01:23:37.150 und das mag der JIT halt nicht. 01:23:37.790 --> 01:23:39.190 Weil der JIT, 01:23:39.230 --> 01:23:41.030 der geht halt davon aus, dass ich die gleichen Funktionen 01:23:41.030 --> 01:23:43.190 oft aufrufe und nicht ganz, ganz viele neue Funktionen 01:23:43.190 --> 01:23:44.930 ständig mache, die dann eben 01:23:44.930 --> 01:23:46.870 neu zum Machine-Code übersetzt werden müssen. 01:23:47.510 --> 01:23:48.570 Und das sorgt eben dafür, dass 01:23:48.570 --> 01:23:51.010 bei Name-Tuple die Performance 01:23:51.010 --> 01:23:53.110 oft wirklich sehr, sehr 01:23:53.110 --> 01:23:54.950 schlecht war in PyPy. Und inzwischen ist das gefixt, 01:23:55.070 --> 01:23:57.090 aber so über so ein paar Versionen 01:23:57.090 --> 01:23:58.870 hatten wir mit Name-Tuple immer mal wieder Probleme. 01:23:58.870 --> 01:24:00.490 Mit Data-Classes am Anfang übrigens auch, 01:24:00.570 --> 01:24:02.750 ist inzwischen auch, glaube ich, ganz gut repariert. 01:24:04.850 --> 01:24:06.530 Aber das sind auf jeden Fall so ein paar, also 01:24:06.530 --> 01:24:08.690 es gibt Bibliotheken, die wir einfach eins zu eins 01:24:08.690 --> 01:24:10.790 übernehmen können, gerade wenn die in Python geschrieben sind, 01:24:10.810 --> 01:24:12.810 ist überhaupt kein Problem. Und es gibt 01:24:12.810 --> 01:24:14.290 welche, wo wir halt dann eben sehr, sehr viel 01:24:14.290 --> 01:24:16.770 Piper-spezifische Patches haben und 01:24:16.770 --> 01:24:18.510 NameTuple ist definitiv 01:24:18.510 --> 01:24:20.650 eins von denen, wo es eher mehr 01:24:20.650 --> 01:24:21.610 als weniger Patches gibt. 01:24:23.510 --> 01:24:24.550 Das habe ich jetzt geschafft, ohne 01:24:24.550 --> 01:24:25.230 jemanden zu beleidigen. 01:24:27.250 --> 01:24:27.610 Oh. 01:24:30.570 --> 01:24:33.270 genau, ja, Typing 01:24:33.270 --> 01:24:35.030 waren auch noch so ein paar Dinge. 01:24:37.070 --> 01:24:37.470 Ich bin ja nicht so 01:24:37.470 --> 01:24:38.170 der Typing-User. 01:24:38.750 --> 01:24:41.210 Die Features sind schon viel zu advanced 01:24:41.210 --> 01:24:41.550 für mich. 01:24:43.390 --> 01:24:44.410 Ja, ups. 01:24:45.490 --> 01:24:46.130 Ja, aber 01:24:46.130 --> 01:24:48.050 ich weiß nicht. 01:24:51.050 --> 01:24:52.530 Da war jetzt auch Read-Only. 01:24:53.710 --> 01:24:54.690 Ja, okay. 01:24:56.030 --> 01:24:57.170 Hast du das gerade vor dir? 01:24:59.110 --> 01:25:00.370 Ja, die Beschreibung ist 01:25:00.370 --> 01:25:03.090 sehr kurz, aber es geht wohl 01:25:03.090 --> 01:25:04.990 darum, dass man Locals bearbeiten 01:25:04.990 --> 01:25:06.870 kann. Und das war 01:25:06.870 --> 01:25:09.210 bisher nicht so genau definiert, 01:25:09.270 --> 01:25:09.850 was da passiert. 01:25:10.870 --> 01:25:12.630 Und jetzt kann man das machen. 01:25:12.630 --> 01:25:14.210 Das ist wohl für Debugger wichtig. 01:25:14.330 --> 01:25:15.850 Hier steht, es ist für Debugger wichtig. 01:25:16.550 --> 01:25:18.510 Ich glaube, der Trick ist, also das Wichtige daran ist 01:25:18.510 --> 01:25:20.450 wirklich, dass jetzt einfach mal genau aufgeschrieben 01:25:20.450 --> 01:25:22.510 wurde, was genau passiert, 01:25:22.590 --> 01:25:24.650 wenn man Locals aufruft. Was können sie erwarten? 01:25:24.770 --> 01:25:25.990 Was können sie erwarten? Und 01:25:25.990 --> 01:25:28.310 manchmal ist es eben so, dass das 01:25:28.310 --> 01:25:30.230 Dictionary was Locals, also bei Globals ist es ja so, 01:25:30.310 --> 01:25:32.310 das Dictionary, wenn ich da 01:25:32.310 --> 01:25:33.630 Keys reinschreibe, dann 01:25:33.630 --> 01:25:36.170 das ist wirklich das richtige Global Dictionary. 01:25:36.310 --> 01:25:38.390 Und wenn ich danach das entsprechende 01:25:38.390 --> 01:25:40.430 Global nachschaue, dann sehe ich auch die Änderung. 01:25:41.010 --> 01:25:41.750 Und bei Locals hängt eben... 01:25:41.750 --> 01:25:44.110 Und das macht sehr schöne Tricks. 01:25:44.310 --> 01:25:46.130 Ja, das macht sehr schöne Tricks möglich. Bei Locals 01:25:46.130 --> 01:25:48.290 ist das nicht so. Bei Locals war es eben manchmal so, 01:25:49.010 --> 01:25:50.190 dass wenn ich Locals verändere, 01:25:50.270 --> 01:25:52.230 dass sich dann die, sich die Locals 01:25:52.230 --> 01:25:53.970 wirklich ändern und manchmal eben halt auch nicht. 01:25:54.230 --> 01:25:56.150 Und genau in welchen Fällen 01:25:56.150 --> 01:25:57.450 welche Variante dann 01:25:57.450 --> 01:25:59.890 galt, das war 01:25:59.890 --> 01:26:02.210 so ein bisschen, immer ein bisschen schwierig vorherzusehen 01:26:02.210 --> 01:26:03.970 und verschiedene Python-Versionen haben das auch irgendwie, 01:26:04.430 --> 01:26:06.090 nee, verschiedene Python-Implementierungen haben das 01:26:06.090 --> 01:26:08.190 auch verschieden dann angegangen. 01:26:08.370 --> 01:26:08.970 Also quasi 01:26:08.970 --> 01:26:12.150 zwischen Funktionen, Global Scopes, Generatoren, 01:26:12.770 --> 01:26:14.190 Core-Routinen, Comprehensions, 01:26:14.790 --> 01:26:16.110 Class-Scope, also es gibt da 01:26:16.110 --> 01:26:17.550 schon so einiges. Achso, 01:26:18.110 --> 01:26:20.110 Code, der von exec oder eva ausgeführt wird, 01:26:20.490 --> 01:26:22.290 da gab es eben schon so einiges an Fällen, 01:26:23.590 --> 01:26:24.310 wo es halt 01:26:24.310 --> 01:26:25.970 dann so immer so leicht unterschiedliches 01:26:25.970 --> 01:26:28.290 Verhalten gab. Das wurde jetzt 01:26:28.290 --> 01:26:29.570 eben fest definiert und ich glaube, 01:26:29.890 --> 01:26:38.810 Es ist so, dass Locals weniger oft, also dass man Mutationen bei Locals weniger oft zu Veränderungen in den echten Locals führen. 01:26:39.730 --> 01:26:56.090 Aber auf der anderen Seite ist es eben so, dass in den Debuggern, wenn man da sich so ein Frame-Objekt geben lässt und da das Attribut F-Locals mutiert, dass das eben zu vorhersagbaren Veränderungen an den echten Werten der Locals führt. 01:26:56.090 --> 01:27:23.690 Und das im Debugger ist eben wichtig, wenn ich im Debugger dann sagen möchte, ich führe jetzt die Funktion aus und die lokale Variable A hat den Wert 17. Ich will jetzt aber einfach mal im Debugger, um rauszufinden, was da genau passiert, das auf 19 setzen. Und wenn das dann nicht geht, weil eben das Verändern der Locals im Debugger nicht so richtig implementiert ist oder nicht immer geht oder nicht in Generatoren geht, ist das halt so ein bisschen frustrierend. Und da ist es eben gut, wenn man jetzt ein klar definiertes Verhalten hat, auf das man sich verlassen kann. 01:27:24.050 --> 01:27:30.130 Ja, und die vielen Debugger-Autoren unter unseren Zuhörern haben sich gerade eben sehr gefreut. 01:27:30.730 --> 01:27:41.110 Naja, also die Debugger-Autoren sind die einen, aber die Leute, die Debugger dann benutzen, denen gehören wir ja dann doch meistens. 01:27:41.610 --> 01:27:43.690 Leider auch, doch tatsächlich. 01:27:44.250 --> 01:27:49.390 Print-Debugging. Wir alle, die noch nicht sofort beim ersten Mal perfekten Code schreiben können. 01:27:50.630 --> 01:27:52.430 Print-Debugging, mehr braucht kein Mensch. 01:27:52.430 --> 01:27:57.850 Kennt ihr diese, das kann ich auch noch nicht, aber ich fand diese Analogie sehr schön. 01:27:58.300 --> 01:28:13.960 Ich glaube auch aus der letzten Copyright-Episode, da gab es wohl irgendeinen Vortrag vor langer Zeit, wo jemand gesagt hat, sei kein Bond-Villain beim Debuggen zum Beispiel. 01:28:14.300 --> 01:28:31.940 Also Bond-Villain, die machen aber alle irgendwie blöde Fehler, dass sie zum Beispiel irgendwie ständig erklären, was ihr Plan ist oder dass sie halt nicht irgendwie mit der großen Weltraumlaser-Kanone schießen, sondern mit einer kleinen Pistole irgendwie sich eine Schießerei mit Bond liefern. 01:28:31.940 --> 01:28:33.720 und das ist halt eine dumme Idee, weil da ist er halt einfach 01:28:33.720 --> 01:28:35.680 besser drin und man hätte 01:28:35.680 --> 01:28:37.340 lieber den Weltraumlaser nehmen sollen. 01:28:37.800 --> 01:28:39.940 Und die Idee ist sozusagen, wenn du debugst, 01:28:40.120 --> 01:28:41.840 nimm den Weltraumlaser direkt. Fang nicht 01:28:41.840 --> 01:28:43.640 irgendwie an mit Printf mit der blöden kleinen 01:28:43.640 --> 01:28:45.760 Pistole, sondern nimm das 01:28:45.760 --> 01:28:47.420 mächtigste Tool, was du irgendwie hast. 01:28:47.500 --> 01:28:49.720 Weil das ist doch Zeitverschwendung, wenn du irgendwie zuerst 01:28:49.720 --> 01:28:51.840 mit Printf anfängst, nimmst du das nächste, das geht auch nicht, 01:28:51.920 --> 01:28:53.660 dann nimmst du das nächste. Fang lieber gleich mit dem 01:28:53.660 --> 01:28:55.800 großen Ding an. Den großen Hammer nehmen und 01:28:55.800 --> 01:28:56.220 draufhauen. 01:28:57.200 --> 01:28:58.540 Erster Schritt, kannst nicht dein 01:28:58.540 --> 01:29:01.120 Produkt schneiden mit dem Weltraumlaser. 01:29:01.940 --> 01:29:06.420 Ja, aber die Idee hatte was. 01:29:08.160 --> 01:29:10.820 Aber das ist einfach sehr individuell. 01:29:11.160 --> 01:29:12.980 Ich kenne auch Leute, die leben nur im Debugger. 01:29:14.620 --> 01:29:16.060 Da ist halt einfach der erste Schritt, 01:29:16.200 --> 01:29:18.000 ich mache eine Funktion, die ist leer, 01:29:18.180 --> 01:29:20.220 und wenn die Argumente reingereicht sind, 01:29:20.260 --> 01:29:21.740 dann mache ich erst mal einen Debugger an. 01:29:22.300 --> 01:29:24.180 Ich gucke halt, was für Argumente sind das jetzt hier 01:29:24.180 --> 01:29:26.300 und wie müsste denn der Code aussehen? 01:29:26.320 --> 01:29:28.240 Dann schreibe ich zwei Zeilen mehr und mache wieder einen Debugger rein. 01:29:28.240 --> 01:29:46.100 Also in manchen Sprachen ist das ja auch noch viel mehr so, dass man das dann auch, dass die IDE das auch unterstützt und man dann quasi die Funktion restarten kann an der Stelle, wo man halt gerade war. Dann schreibt man ein bisschen mehr Code, restartet die wieder. Also die Smalltalk-Leute machen das besonders gern, die es noch gibt. 01:29:47.380 --> 01:29:49.540 ja, also ich kenne 01:29:49.540 --> 01:29:51.320 auf jeden Fall auch in Python Leute, die halt sich das so 01:29:51.320 --> 01:29:52.640 angewöhnt haben, dass sie halt 01:29:52.640 --> 01:29:55.180 Tests schreiben, die Bagger anmachen und dann 01:29:55.180 --> 01:29:57.340 kann man halt erstmal so gucken, was macht man denn eigentlich 01:29:57.340 --> 01:29:59.040 für Objekte, was haben die für Methoden und wie, 01:29:59.520 --> 01:30:00.560 ja, was macht man denn da jetzt? 01:30:00.580 --> 01:30:01.400 NB-Dev so ein bisschen. 01:30:02.660 --> 01:30:05.240 Ich habe auch versucht mal 01:30:05.240 --> 01:30:06.740 einen zu überzeugen von 01:30:06.740 --> 01:30:09.300 Jupyter Notebooks und so, aber ich bin begeistert 01:30:09.300 --> 01:30:11.280 davon, dass er dann so, ja, nee, benutze ich nie, finde ich 01:30:11.280 --> 01:30:13.100 blöd und dann so, ja, dann habe ich gesehen, wie der 01:30:13.100 --> 01:30:15.060 entwickelt und der tatsächlich hat 01:30:15.060 --> 01:30:17.240 quasi das, was ich in Jupyter Notebooks mache, macht der 01:30:17.240 --> 01:30:19.460 im Debugger. Ja. Das kann man 01:30:19.460 --> 01:30:20.740 tun, das geht schon. 01:30:21.120 --> 01:30:23.140 Aber es ist halt, okay, ja. 01:30:24.620 --> 01:30:25.600 Wenn man jetzt noch einen Debugger 01:30:25.600 --> 01:30:27.460 hätte, der vorwärts und rückwärts steppen kann 01:30:27.460 --> 01:30:29.180 und wo man zwischendurch den Code verarbeiten 01:30:29.180 --> 01:30:31.120 kann, dann passt das schon. 01:30:31.940 --> 01:30:33.120 Ja. Aber ich glaube, 01:30:33.180 --> 01:30:35.180 PDB ist eine der Sachen, wo ich das Gefühl 01:30:35.180 --> 01:30:36.880 habe, dass das auch so ein bisschen 01:30:36.880 --> 01:30:39.180 revitalisiert ist. Also, 01:30:39.280 --> 01:30:41.040 dass es da jetzt Coders gibt, die sich dafür 01:30:41.040 --> 01:30:43.080 interessieren und eben hoffen, da 01:30:43.080 --> 01:30:44.440 in den nächsten Versionen auch ein paar 01:30:44.440 --> 01:30:47.000 neue Features reinzukriegen. Ich glaube, auch in 01:30:47.000 --> 01:30:48.460 3.13 ist schon die erste Version. 01:30:49.560 --> 01:30:51.200 Zum Beispiel, dass wenn man so einen Breakpoint 01:30:51.200 --> 01:30:52.000 macht, dass dann 01:30:52.000 --> 01:30:54.820 dass man dann 01:30:54.820 --> 01:30:57.160 nicht erst in der nächsten Zeile dann 01:30:57.160 --> 01:30:59.060 wirklich anhält im Debugger, sondern 01:30:59.060 --> 01:31:01.260 schon in der Zeile selber, wo der Breakpoint ist. 01:31:01.620 --> 01:31:02.540 Ah ja, genau, genau. 01:31:03.060 --> 01:31:04.900 Da war auch irgendwie so eine Seltsamkeit, dass 01:31:04.900 --> 01:31:07.020 wenn man das vor einem Return gemacht hat, dass man 01:31:07.020 --> 01:31:08.800 dann halt irgendwie... Im Caller 01:31:08.800 --> 01:31:11.420 erst den Breakpoint gekriegt hat. 01:31:11.420 --> 01:31:13.360 Ja, also das sind schon 01:31:13.360 --> 01:31:14.040 einige Dinge hier. 01:31:16.340 --> 01:31:19.760 Um jetzt meinen Einwurf noch kurz zu retten, 01:31:20.940 --> 01:31:23.940 das war eine Präsentation von einem Spieleentwickler, 01:31:24.020 --> 01:31:25.380 die sich selber so ein System gebaut hat. 01:31:25.440 --> 01:31:27.980 Jochen, du hattest die, glaube ich, auf dem Tomorrow Corporation. 01:31:28.260 --> 01:31:29.280 Das war eine super Video. 01:31:29.280 --> 01:31:31.020 Die haben sich genau so einen Debugger gebaut, 01:31:31.480 --> 01:31:33.520 der vorwärts und rückwärts steppen kann 01:31:33.520 --> 01:31:35.540 und wo ich zwischendurch Code verändern kann 01:31:35.540 --> 01:31:37.080 und dann trotzdem die Auswirkungen alle sehe. 01:31:37.360 --> 01:31:39.060 Das war schon sehr beeindruckend, 01:31:39.140 --> 01:31:42.640 weil das halt tatsächlich so ein Debugging ermöglicht, 01:31:42.720 --> 01:31:44.800 am offenen Herzen, ohne Angst haben zu müssen, 01:31:44.800 --> 01:31:46.060 dass der Patient jetzt abstürzt. 01:31:46.340 --> 01:31:48.240 das ist schon sehr beeindruckend. 01:31:48.240 --> 01:31:50.500 Ja, und es war auch noch irgendwie da, dass es ein Spiel ist 01:31:50.500 --> 01:31:52.400 und man hat halt unten quasi beim 01:31:52.400 --> 01:31:54.380 D-Bagger so einen Schieber 01:31:54.380 --> 01:31:56.420 und das Spiel geht halt mit und man 01:31:56.420 --> 01:31:58.580 schiebt den so da und das Spiel läuft rückwärts 01:31:58.580 --> 01:32:00.780 und man sagt 01:32:00.780 --> 01:32:02.260 da so ganz trocken so zu, ja, 01:32:02.400 --> 01:32:04.260 das sind jetzt nicht irgendwie Screenshots oder so, nee, das ist 01:32:04.260 --> 01:32:06.240 das echte Spiel, was wirklich irgendwie neu 01:32:06.240 --> 01:32:06.880 gerendert wird. 01:32:07.600 --> 01:32:10.360 Dann schiebe ich hier mal die Funktion ein kleines bisschen um und lasse das mal 01:32:10.360 --> 01:32:12.140 wieder laufen von hier aus und jetzt ist auch 01:32:12.140 --> 01:32:12.780 dieser Branch drin. 01:32:12.780 --> 01:32:13.840 mal bitte diesen Vortrag. 01:32:14.800 --> 01:32:16.940 Ja, kann ich auch in den Show Notes mal verlinken. 01:32:16.940 --> 01:32:17.840 Ja, den könnt ihr auch in die Show Notes rein. 01:32:18.320 --> 01:32:20.840 Also ich hatte, ich glaube 01:32:20.840 --> 01:32:22.560 die Free-Threading-Leute, die 01:32:22.560 --> 01:32:24.640 müssen solche Tools auch benutzen, weil es 01:32:24.640 --> 01:32:26.740 ansonsten einfach echt zu schwierig ist. Und da gibt's halt 01:32:26.740 --> 01:32:29.040 auch für C, so Back-in-Time-Debugger, 01:32:29.120 --> 01:32:30.480 der, wie heißt der nochmal? 01:32:32.200 --> 01:32:32.840 Anfang des Jahres 01:32:32.840 --> 01:32:34.520 war ich zum ersten Mal in der Situation, dass ich mich 01:32:34.520 --> 01:32:36.520 genötigt gesehen habe, auch so einen zu benutzen. 01:32:37.000 --> 01:32:39.060 Weil wir so einen nur sehr selten 01:32:39.060 --> 01:32:40.560 stattfindenden 01:32:40.560 --> 01:32:42.160 Garbage-Corrector-Bug hatten und 01:32:42.160 --> 01:32:48.320 Und mit so einem Back-in-Time-Debugger kann man halt dann solche Probleme auch richtig gut lösen. 01:32:48.540 --> 01:32:54.560 Also das ist quasi so ein Tracing-Debugger, der macht so eine Aufzeichnung der gesamten Prozessausführung. 01:32:55.140 --> 01:32:57.420 Das kann man einfach hundertmal machen, bis der Crash stattfindet. 01:32:57.840 --> 01:33:00.400 Und dann kann man sich die Ausführungen beliebig oft wieder anschauen. 01:33:01.400 --> 01:33:03.920 Und das Interface ist quasi so wie so ein normaler Debugger. 01:33:03.920 --> 01:33:06.260 Ich kann halt Next machen und Sachen printen. 01:33:06.940 --> 01:33:12.100 Aber der Prozess wird nicht wirklich neu ausgeführt, sondern das ist quasi in Anführungszeichen nur ein Replay. 01:33:12.160 --> 01:33:14.020 von dem, was eben bei der 01:33:14.020 --> 01:33:16.340 crashenden Ausführung wirklich passiert ist. 01:33:16.960 --> 01:33:17.600 Und da kann ich 01:33:17.600 --> 01:33:19.960 da kann ich dann wirklich auch 01:33:19.960 --> 01:33:22.100 ein Backward Next machen und dann bin ich wieder eine Zeile 01:33:22.100 --> 01:33:23.940 davor. Oder ein 01:33:23.940 --> 01:33:26.200 Backward Finish und dann bin ich 01:33:26.200 --> 01:33:28.340 eben am Anfang der Funktion, die ich gerade ausführe. 01:33:29.440 --> 01:33:30.340 Oder halt auch so Sachen 01:33:30.340 --> 01:33:32.300 wie, ich mache ein Hardware Watchpoint, 01:33:32.500 --> 01:33:32.580 also 01:33:32.580 --> 01:33:36.340 das war wirklich Memory Corruption, die ich da 01:33:36.340 --> 01:33:37.820 debuggt habe. Und 01:33:37.820 --> 01:33:40.240 wenn du halt einen kaputten Speicher hast, dann kannst 01:33:40.240 --> 01:33:41.180 du dir so ein Watchpoint 01:33:41.180 --> 01:33:43.420 setzen, wo du sagst, wer hat 01:33:43.420 --> 01:33:45.860 diesen, also wenn dieser Speicher 01:33:45.860 --> 01:33:48.040 verändert wird, dann halt 01:33:48.040 --> 01:33:50.040 an. Und dann 01:33:50.040 --> 01:33:51.860 kann man quasi vom Crash 01:33:51.860 --> 01:33:53.840 sagen, man macht so einen Watchpoint 01:33:53.840 --> 01:33:55.880 für den kaputten Speicher und dann lässt man rückwärts laufen. 01:33:57.020 --> 01:33:57.880 Weil dann findet man 01:33:57.880 --> 01:34:00.040 quasi, wenn man rückwärts läuft, findet man den Code, 01:34:00.220 --> 01:34:01.840 der den Speicher wirklich kaputt geschrieben hat. 01:34:02.680 --> 01:34:03.020 Und 01:34:03.020 --> 01:34:05.080 das war wirklich richtig gut. 01:34:06.340 --> 01:34:07.500 Aber das war wirklich auch 01:34:07.500 --> 01:34:09.740 ziemlich magisch. Es ist sehr magisch. Es funktioniert übrigens 01:34:09.740 --> 01:34:11.560 auch nicht, also technisch ist das nicht so 01:34:11.560 --> 01:34:12.880 implementiert, dass es wirklich rückwärts läuft. 01:34:13.360 --> 01:34:15.360 Weil es ist ja Maschinen-Code, es geht für beliebigen Code. 01:34:15.920 --> 01:34:17.620 Stattdessen macht er nur Snapshots. 01:34:18.620 --> 01:34:19.480 Der geht dann zum letzten 01:34:19.480 --> 01:34:21.100 Snapshot und läuft von da vorwärts. 01:34:23.020 --> 01:34:23.640 Aber es 01:34:23.640 --> 01:34:24.620 fühlt sich halt trotzdem so an. 01:34:24.620 --> 01:34:26.960 Ja, gut genug. 01:34:27.420 --> 01:34:27.740 Gut genug. 01:34:30.180 --> 01:34:32.180 Okay, okay, ich habe hier noch den wichtigsten, 01:34:32.480 --> 01:34:34.420 ich habe hier noch den wichtigsten, 01:34:34.500 --> 01:34:36.860 die wichtigste Änderung in Python 3.13. 01:34:38.280 --> 01:34:42.140 Bei Dockstrings werden jetzt die führenden Leerzeichen entfernt. 01:34:42.640 --> 01:34:43.640 Oh ja, das ist ja auch was. 01:34:44.700 --> 01:34:48.060 Das hatten wir uns schon angeguckt im Rappel tatsächlich. 01:34:49.080 --> 01:34:50.560 Warum? Wofür ist das da? 01:34:51.600 --> 01:34:53.980 Wie viel Prozent des Codes ist weniger? 01:34:54.560 --> 01:34:55.020 Oder der Byte? 01:34:55.540 --> 01:34:56.260 Fünf Prozent. 01:34:56.400 --> 01:34:57.300 Fünf Prozent weniger. 01:34:57.300 --> 01:35:02.160 Aber einfach, weil es korrekt ist, oder? 01:35:04.480 --> 01:35:07.880 Man braucht niemals den Dockstring mit der Einrückung. 01:35:08.280 --> 01:35:11.900 Naja, 5% finde ich 01:35:11.900 --> 01:35:13.760 ganz schön krass. Also 5% sind Leerzeichen 01:35:13.760 --> 01:35:15.700 von eingerückten Dockstrings in 01:35:15.700 --> 01:35:17.840 unseren PYC-Dateien. Das ist irgendwie 01:35:17.840 --> 01:35:19.840 würde man jetzt 01:35:19.840 --> 01:35:21.140 erstmal so nicht erwarten. 01:35:22.160 --> 01:35:23.560 Green Development danach. 01:35:25.720 --> 01:35:27.700 Das liegt halt daran, dass wir alle so viele 01:35:27.700 --> 01:35:29.620 gute und ausführliche Dockstrings 01:35:29.620 --> 01:35:31.340 schreiben und ganz viel... 01:35:31.340 --> 01:35:33.020 Vor allen Dingen aus Leerzeichen bestehen. 01:35:34.400 --> 01:35:35.600 Ja, ich weiß nicht. 01:35:35.600 --> 01:35:37.220 Jochen schreibt keine Dockstrings, dem passiert sowas nicht. 01:35:37.220 --> 01:35:37.620 Doch, doch. 01:35:38.380 --> 01:35:39.860 Naja gut, wenn ich einen Klassen habe, 01:35:39.900 --> 01:35:42.760 Methoden-Dockstrings, dann sind die ja schon immer 01:35:42.760 --> 01:35:45.080 8 Bytes eingerückt 01:35:45.080 --> 01:35:46.100 pro Zeile Dockstring. 01:35:46.600 --> 01:35:46.940 Ja, richtig. 01:35:49.160 --> 01:35:51.040 Und das müssten ja eigentlich 10% sein, 01:35:51.120 --> 01:35:52.900 weil wir gehen ja nur bis 80 Zeichen pro Zeile. 01:35:59.440 --> 01:36:00.360 Ist das nicht 79? 01:36:01.780 --> 01:36:02.640 Ja, streng genommen 01:36:02.640 --> 01:36:03.340 ist es 79. 01:36:03.340 --> 01:36:04.540 Ja, oder 01:36:04.540 --> 01:36:06.460 79. 01:36:07.220 --> 01:36:11.100 Was habt ihr denn für moderne Displays? 01:36:11.120 --> 01:36:12.560 80x25, oder? 01:36:14.820 --> 01:36:15.140 Wenn du 01:36:15.140 --> 01:36:17.120 Python-Modus 4 auf deinem T64 schreibst. 01:36:18.380 --> 01:36:19.180 Es gibt Leute, 01:36:19.280 --> 01:36:20.320 die müssen auf ihrem Handy entwickeln. 01:36:21.160 --> 01:36:22.180 Ich habe PyPy auf meinem Handy. 01:36:22.640 --> 01:36:24.780 Ach, okay. Wie geht das denn? 01:36:26.640 --> 01:36:27.200 PyPy ist 01:36:27.200 --> 01:36:28.620 tatsächlich ein Paket auf 01:36:28.620 --> 01:36:29.980 Thermux. 01:36:31.200 --> 01:36:33.140 PyPy hat eine ARM-Version und dann kann man 01:36:34.140 --> 01:36:35.360 das einfach 01:36:35.360 --> 01:36:36.940 laufen lassen. Manchmal ist es auch nett, 01:36:37.020 --> 01:36:38.100 dann kann ich in der Bahn irgendwie, 01:36:38.820 --> 01:36:40.420 das ist halt so ein bisschen nervig zu tippen, aber 01:36:40.420 --> 01:36:42.720 man kann auch den JIT laufen lassen, man kann sich dann auch 01:36:42.720 --> 01:36:45.000 auf dem Handy anzeigen 01:36:45.000 --> 01:36:46.780 lassen, welchen Maschinencode 01:36:46.780 --> 01:36:48.720 der PyPyJIT jetzt gerade auf 01:36:48.720 --> 01:36:50.800 für den Python-Code, den man auf dem Handy 01:36:50.800 --> 01:36:51.980 laufen ließ, 01:36:52.680 --> 01:36:54.060 erzeugt wurde. 01:36:54.540 --> 01:36:56.220 Wenn man die richtigen Umgebungsvariablen weiß. 01:36:56.740 --> 01:36:58.660 Aber Thermux kann das leider noch nicht, dass man mit dem Daumen 01:36:58.660 --> 01:37:00.500 hoch und runter machen kann mit dem interaktiven 01:37:00.500 --> 01:37:02.780 neuen. Nein, nein, aber das ist Scrolling 01:37:02.780 --> 01:37:04.580 und ich meine jetzt durch die einzelnen Zeilen durch 01:37:04.580 --> 01:37:05.540 vom Editor, vom 01:37:05.540 --> 01:37:07.200 History Edit. 01:37:07.500 --> 01:37:09.300 Ich glaube, achso, du meinst so 01:37:09.300 --> 01:37:11.100 in der Konsole, ne, glaube ich nicht. 01:37:11.100 --> 01:37:12.840 Ja, schade. 01:37:14.660 --> 01:37:15.600 Habe ich, also jedenfalls 01:37:15.600 --> 01:37:16.680 zu dem Thermux habe ich auch eine, 01:37:17.920 --> 01:37:19.740 weiß nicht, wie lustig die für andere ist, 01:37:19.760 --> 01:37:21.660 ich fand die lustig, ist mir was auf einer 01:37:21.660 --> 01:37:23.160 Konferenz im Sommer passiert, ich war auf so einer 01:37:23.160 --> 01:37:26.120 akademischen Programmiersprachenkonferenz 01:37:26.120 --> 01:37:26.960 mit, also 01:37:26.960 --> 01:37:29.280 Forschern und Forscherinnen, die sich mit 01:37:29.280 --> 01:37:31.580 Compilern und Optimierung 01:37:31.580 --> 01:37:32.800 und Programmiersprachen und so auseinandersetzen 01:37:32.800 --> 01:37:35.360 und da war ich dann mit einem relativ 01:37:35.360 --> 01:37:37.660 bekannten C-Compiler 01:37:37.660 --> 01:37:39.600 Prof, oder John Reggeier 01:37:39.600 --> 01:37:41.580 heißt der, auf so einem Boot 01:37:41.580 --> 01:37:43.120 in Kopenhagen Bier trinken, also 01:37:43.120 --> 01:37:45.540 das Boot lag am Hafen, 01:37:45.580 --> 01:37:47.200 man konnte auf Deck Bier trinken und 01:37:47.200 --> 01:37:49.420 hab ihm dann auf dem Handy so eine Optimierung 01:37:49.420 --> 01:37:50.580 gezeigt, die wir in PyPy machen 01:37:50.580 --> 01:37:53.520 und er hat also mit PyPy noch nie irgendwas zu tun 01:37:53.520 --> 01:37:55.460 gehabt und schaut sich das an, so in ganz 01:37:55.460 --> 01:37:57.240 ganz kleinem Font und meinte so, 01:37:57.540 --> 01:37:59.480 warum ist denn da diese Extraoperation, die braucht er doch gar nicht. 01:38:00.260 --> 01:38:01.520 Und das war absolut 01:38:01.520 --> 01:38:02.520 richtig und 01:38:02.520 --> 01:38:06.560 Und der Grund war, dass die Divisionen in C und in Python 01:38:06.560 --> 01:38:11.860 halt sich unterschiedlich verhalten, wenn die Zahlen negativ sind. 01:38:12.400 --> 01:38:15.540 Und dafür braucht man halt in Python so ein extra XOR. 01:38:15.860 --> 01:38:20.700 Aber die Tatsache, dass er das quasi so mit dem 8-Punkt-Font 01:38:20.700 --> 01:38:24.000 über einem Bier, so auf dem Handy, mal eben so gesehen hat, 01:38:24.120 --> 01:38:28.020 quasi in einem ASCII-Format, was er noch nie gesehen hatte, 01:38:28.100 --> 01:38:29.740 das fand ich dann doch relativ krass. 01:38:30.160 --> 01:38:32.240 Tja, so Leute gibt es. Ich würde sogar fast sagen, 01:38:32.280 --> 01:38:33.600 das ist fast der Schluss von Thema 13. 01:38:33.600 --> 01:38:36.220 Ja, ich glaube, wir sind mit dem Thema eigentlich mehr oder 01:38:36.220 --> 01:38:37.680 weniger durch. Dann 01:38:37.680 --> 01:38:39.840 können wir eigentlich noch mal zu einem 01:38:39.840 --> 01:38:42.320 welchen Teil 01:38:42.320 --> 01:38:44.200 wechseln. Wir konnten 01:38:44.200 --> 01:38:46.420 zum Beispiel 01:38:46.420 --> 01:38:48.240 ein bisschen 01:38:48.240 --> 01:38:50.380 Meta-Geschichten 01:38:50.380 --> 01:38:51.680 machen. Meta-Geschichten? 01:38:52.480 --> 01:38:54.120 Ja, zum Beispiel hatten 01:38:54.120 --> 01:38:55.840 wir Anfragen nach 01:38:55.840 --> 01:38:58.160 Ach, das ist also ein Satz Meta-Geschichten. 01:38:58.260 --> 01:38:59.640 Ja, also 01:38:59.640 --> 01:39:01.320 wie sieht das eigentlich aus? 01:39:01.780 --> 01:39:03.520 Wollt ihr nicht mal ein Hörertreffen machen? 01:39:04.960 --> 01:39:05.960 Ja, wollen wir 01:39:05.960 --> 01:39:07.560 das? Und genau, das 01:39:07.560 --> 01:39:09.820 hängt, würde ich meinen, davon ab, 01:39:09.980 --> 01:39:11.760 ob es Hörer gibt, die 01:39:11.760 --> 01:39:13.900 das auch gerne machen wollen würden, 01:39:14.080 --> 01:39:16.340 weil ansonsten 01:39:16.340 --> 01:39:18.000 sitzen wir da alleine rum irgendwo. 01:39:18.260 --> 01:39:19.780 Das wäre ja auch irgendwie, also ich würde einfach mal 01:39:19.780 --> 01:39:21.800 eine Idee, jetzt können wir das natürlich auch machen, 01:39:22.160 --> 01:39:22.320 aber 01:39:22.320 --> 01:39:25.540 sagen wir mal so, man kann 01:39:25.540 --> 01:39:27.460 einfach eine Mail an 01:39:27.460 --> 01:39:29.540 hallo.vereinenpodcast.de schreiben zum Beispiel 01:39:29.540 --> 01:39:31.200 und wenn da jetzt fünf Mails kommen, 01:39:31.720 --> 01:39:32.960 dass man sich irgendwo 01:39:32.960 --> 01:39:35.460 Köln, Düsseldorfer Raum oder so 01:39:35.460 --> 01:39:37.500 treffen wollen würde, dann 01:39:37.500 --> 01:39:38.760 machen wir das einfach mal. 01:39:40.000 --> 01:39:41.120 Und genau, 01:39:41.660 --> 01:39:43.200 das ist eine Geschichte. 01:39:43.380 --> 01:39:45.240 Dann gab es eine Nachfrage nach... 01:39:45.240 --> 01:39:47.620 Ich würde das gerne noch 01:39:47.620 --> 01:39:49.560 erweitern, also falls da fünf Mails 01:39:49.560 --> 01:39:51.180 kommen, die sich im Stuttgarter Raum 01:39:51.180 --> 01:39:51.920 treffen wollen. 01:39:52.780 --> 01:39:55.120 Oh je, vielleicht müssen wir uns in der Mitte treffen, 01:39:55.220 --> 01:39:56.480 irgendwo in Frankfurt oder so. 01:39:57.320 --> 01:39:59.180 Ja, in Frankfurt? 01:39:59.420 --> 01:40:01.140 Nee, das ist 01:40:01.140 --> 01:40:03.200 bimodal, oder? Das ist Düsseldorf oder 01:40:03.200 --> 01:40:05.160 Stuttgart und dann kriegt man das hin. 01:40:05.180 --> 01:40:05.520 Alles klar. 01:40:06.460 --> 01:40:09.420 Da, wo sich mehr melden, da müssen 01:40:09.420 --> 01:40:11.260 wir dann hin. Da ist zuerst. 01:40:12.000 --> 01:40:12.120 Aha. 01:40:13.160 --> 01:40:14.060 Da ist zuerst. 01:40:15.260 --> 01:40:17.020 Ja. Okay, mal schauen. 01:40:17.120 --> 01:40:18.220 Ich bin mal gespannt, ob sich da jemand meldet. 01:40:18.700 --> 01:40:20.440 Das könnten wir machen. 01:40:21.440 --> 01:40:23.040 Genau. Ja, dann hat sich... 01:40:23.040 --> 01:40:24.700 Sollen wir T-Shirts machen, Jörg? 01:40:24.700 --> 01:40:25.540 T-Shirts. 01:40:27.320 --> 01:40:28.240 Ja, 01:40:28.540 --> 01:40:30.700 ja, können wir 01:40:30.700 --> 01:40:31.400 auch machen. 01:40:33.340 --> 01:40:34.720 Hat sich da gerade jemand freiwillig 01:40:34.720 --> 01:40:34.960 gemeldet? 01:40:37.680 --> 01:40:38.880 Müssen wir mal schauen. 01:40:39.380 --> 01:40:40.700 Ja, genau. 01:40:40.800 --> 01:40:41.820 Eine andere Anfrage war 01:40:41.820 --> 01:40:44.520 von jemandem, der irgendwie alte Episoden 01:40:44.520 --> 01:40:46.520 durchhört, dass wir wohl irgendwann mal gesagt haben, 01:40:46.600 --> 01:40:48.180 oh, wir machen mal einen Discord-Server oder so. 01:40:48.940 --> 01:40:50.740 Und dann kam 01:40:50.740 --> 01:40:52.240 die Frage, haben wir das denn mal gemacht dann? 01:40:52.720 --> 01:40:54.320 Ja. Und die Antwort ist ja. 01:40:55.140 --> 01:40:56.560 Aber wir haben nie drüber geredet 01:40:56.560 --> 01:40:58.440 und vielleicht machen wir das jetzt 01:40:58.440 --> 01:41:00.460 auch mal und packen einen Link zu dem 01:41:00.460 --> 01:41:02.500 Discord-Server einfach irgendwie auch in die 01:41:02.500 --> 01:41:04.260 Shownotes oder so. Und 01:41:04.260 --> 01:41:06.360 da kann man auch einfach dann mal draufgucken, 01:41:06.480 --> 01:41:08.100 weil tatsächlich haben wir das und 01:41:08.100 --> 01:41:08.880 ja, 01:41:09.080 --> 01:41:12.340 wir haben das aber nie kommuniziert, dass wir das haben. 01:41:12.480 --> 01:41:12.820 Daher 01:41:12.820 --> 01:41:16.000 ist da auch wenig los. Genau. 01:41:18.020 --> 01:41:18.220 Und... 01:41:18.220 --> 01:41:20.460 Wie ist es eigentlich mit den tollen 01:41:20.460 --> 01:41:22.420 Transkripten von unserem 01:41:22.420 --> 01:41:24.340 Podcast, lieber Jürgen? Ja, da habe ich jetzt 01:41:24.340 --> 01:41:26.380 am Wochenende, da gab es den PyDDF 01:41:26.380 --> 01:41:28.700 Herbstsprint und da habe ich 01:41:28.700 --> 01:41:30.680 angefangen, mich mal damit 01:41:30.680 --> 01:41:32.600 zu beschäftigen, weil ich dachte 01:41:32.600 --> 01:41:33.940 so, also ich meine, klar, dass man da 01:41:33.940 --> 01:41:36.480 kann man nicht, also in zwei Tagen 01:41:36.480 --> 01:41:37.960 kriege ich das nicht hin, aber 01:41:37.960 --> 01:41:40.480 ich habe zumindest angefangen und man kann 01:41:40.480 --> 01:41:42.620 jetzt auch, wenn man im Webplayer auf 01:41:42.620 --> 01:41:44.620 da ist so ein zusätzlicher 01:41:44.620 --> 01:41:46.600 Button bei den Episoden, wo es Transkripte 01:41:46.600 --> 01:41:48.860 gibt. Also falls ihr Taubseiten 01:41:48.860 --> 01:41:50.500 es trotzdem hören wollt, könnt ihr uns jetzt auch 01:41:50.500 --> 01:41:51.940 also lesen. Ja, genau. 01:41:52.860 --> 01:41:54.920 Das sieht aus wie so ein Dokument-Icon. 01:41:55.440 --> 01:42:01.380 Wenn man da drauf drückt, dann erscheint da irgendwie so ein Transkript-Tab drunter. 01:42:02.080 --> 01:42:06.480 Und das läuft auch mit, wenn man dann mit dem Player das abspielt. 01:42:07.120 --> 01:42:07.880 Und das geht schon. 01:42:07.980 --> 01:42:10.060 Aber das ist nur ein Teil von den Sachen, die man implementieren muss, 01:42:10.100 --> 01:42:11.360 wenn man Transkripte haben will. 01:42:11.520 --> 01:42:13.840 Da kommen noch diverse andere Geschichten dazu, mit denen ich noch nicht fertig bin. 01:42:14.400 --> 01:42:15.680 Aber das geht auf jeden Fall. 01:42:16.360 --> 01:42:20.060 Dabei ist mir dann auch eine Geschichte aufgefallen, die halt blöd ist. 01:42:20.060 --> 01:42:22.360 Ich dachte, das ist voll super, wir haben ja auch die Spuren noch. 01:42:22.860 --> 01:42:24.940 Das heißt, die Sprechererkennung 01:42:24.940 --> 01:42:26.580 brauchen wir gar nicht in einem Machine Learning Modell 01:42:26.580 --> 01:42:28.300 machen, sondern das weiß man ja schon. 01:42:29.040 --> 01:42:30.400 Ich haue einfach die 01:42:30.400 --> 01:42:32.480 Spuren getrennt durch Whisper durch 01:42:32.480 --> 01:42:34.540 oder so und dann kann ich 01:42:34.540 --> 01:42:36.080 auch sagen, wer das gesagt hat. 01:42:36.760 --> 01:42:37.540 Und dann habe ich festgestellt, 01:42:37.880 --> 01:42:40.720 die rohen Spuren 01:42:40.720 --> 01:42:42.500 vor Auphonic sind halt 01:42:42.500 --> 01:42:44.380 von den Zeiten her anders, als das, was 01:42:44.380 --> 01:42:46.560 nachher rausfällt, weil halt manchmal 01:42:46.560 --> 01:42:48.520 Stille rausgeschnitten wird oder manchmal 01:42:48.520 --> 01:42:49.460 wird das halt so ein bisschen 01:42:49.460 --> 01:42:52.460 transformiert und dann passen die ganzen Zeitstempel 01:42:52.460 --> 01:42:54.420 nicht mehr und dann geht das nicht. Und Jochen hat nicht aufgehoben 01:42:54.420 --> 01:42:56.220 die einzelnen Spuren. Ja, man kriegt von 01:42:56.220 --> 01:42:57.740 Auphonic auch die einzelnen Spuren zurück. 01:42:58.620 --> 01:43:00.340 Nach dem Mastering 01:43:00.340 --> 01:43:02.200 sozusagen, aber die habe ich nicht aufgehoben 01:43:02.200 --> 01:43:03.180 und die werden nach irgendwie 01:43:03.180 --> 01:43:05.680 zwei Wochen oder 20 Tagen irgendwie gelöscht. 01:43:06.220 --> 01:43:07.880 Das heißt, ich muss entweder alles nochmal durch 01:43:07.880 --> 01:43:08.660 Auphonic schieben 01:43:08.660 --> 01:43:11.940 oder irgendwie 01:43:11.940 --> 01:43:14.060 es gibt für die alten Folgen dann halt jetzt 01:43:14.060 --> 01:43:16.020 nur die Transkripte ohne Namen 01:43:16.020 --> 01:43:18.080 dran. Vielleicht ist das auch schon 01:43:18.080 --> 01:43:20.040 okay. Genau, und dann für die zukünftige mache ich 01:43:20.040 --> 01:43:21.880 das dann halt so, dass man dann auch die Namen an den 01:43:21.880 --> 01:43:22.380 Sprechern hat. 01:43:23.780 --> 01:43:25.900 Ja, aber Transkripte, da tut sich 01:43:25.900 --> 01:43:26.940 was, das kommt jetzt. 01:43:27.640 --> 01:43:29.520 Wir hatten das ja irgendwann schon mal so ein bisschen probiert, das war so relativ 01:43:29.520 --> 01:43:30.980 fürchterlich, aber so ist eigentlich relativ cool. 01:43:32.100 --> 01:43:32.260 Ja. 01:43:34.360 --> 01:43:34.640 Genau. 01:43:35.960 --> 01:43:37.400 Ja, wir wollten auch picken, oder? 01:43:37.660 --> 01:43:39.840 Picken wir nicht immer? Genau, picks, genau. 01:43:40.380 --> 01:43:40.780 Genau, genau. 01:43:41.480 --> 01:43:43.400 Ich muss ja wieder irgendwas für dich Triviales picken, 01:43:43.400 --> 01:43:45.480 dann fange ich mal damit an, weil ich ja immer irgendwas anderes 01:43:45.480 --> 01:43:46.000 denke und 01:43:46.000 --> 01:43:49.460 wieder, hat nichts mit unserer Folge zu tun, aber 01:43:49.460 --> 01:43:51.340 ich habe 01:43:51.340 --> 01:43:53.220 ab und zu mal Geld bezahlt tatsächlich irgendwie für 01:43:53.220 --> 01:43:54.720 ordentliche Freistellung von Bildern. 01:43:55.140 --> 01:43:56.900 Keine Ahnung mehr, warum, aber das war schon 01:43:56.900 --> 01:43:59.320 ein bisschen länger her. Es gibt ein tolles Paket, 01:43:59.380 --> 01:44:01.240 das ich entdeckt habe, das heißt RemBG 01:44:01.240 --> 01:44:03.200 oder sowas. Das macht einfach den 01:44:03.200 --> 01:44:05.280 Background weg als Kommando-Teilen-Tool von irgendwelchen 01:44:05.280 --> 01:44:06.600 Bildern, wenn man das will. 01:44:07.140 --> 01:44:07.860 Super praktisch. 01:44:09.860 --> 01:44:10.780 Falls man sowas braucht. 01:44:11.700 --> 01:44:12.060 Das war's. 01:44:13.480 --> 01:44:15.040 Jetzt dürft ihr vernünftige Sachen bekommen. 01:44:15.300 --> 01:44:17.200 Ich mach mal weiter mit den unvernünftigen Sachen, 01:44:17.300 --> 01:44:19.240 die auch überhaupt nichts mit der Episode zu tun 01:44:19.240 --> 01:44:20.860 haben, aber mit der Zeit, in der wir leben. 01:44:21.340 --> 01:44:28.500 Und zwar ist kürzlich die neueste, größte Primzahl gefunden worden. 01:44:28.840 --> 01:44:29.340 Ah, ja. 01:44:29.720 --> 01:44:34.040 Das ist eine Mersenne-Primzahl, die heißt M136279841. 01:44:34.860 --> 01:44:42.220 Also 2 hoch 136.279.841 minus 1 ist eine Primzahl. 01:44:44.060 --> 01:44:49.660 Waren sehr viele GPUs beteiligt an der Überprüfung 01:44:49.660 --> 01:45:07.200 Und das ist die erste seit 28 Jahren, die erste große Primzahl nach 28 Jahren. Diese Primzahl hat 41.024.320 Stellen. Und das allein ist schon eine schöne Sache. 01:45:07.200 --> 01:45:19.480 Aber das Schöne, was ich gefunden habe, was heute mein Pick ist, ist eine Initiative, die versucht, diese Zahl zu sagen, bevor die nächste größte Primzahl gefunden wird. 01:45:19.660 --> 01:45:24.100 Und zwar als verteilter Prozess. 01:45:24.920 --> 01:45:27.620 Da gibt es eine Webseite, die heißt saytheprime.com. 01:45:28.320 --> 01:45:32.100 Da kann man sich 419 Stellen geben lassen. 01:45:33.260 --> 01:45:36.260 Die nimmt man dann als Video auf, lädt das Ganze auf YouTube hoch, 01:45:37.160 --> 01:45:42.400 schickt den Link ein und die machen dann eine ganz, ganz, ganz, ganz, ganz große Playlist draus, 01:45:42.820 --> 01:45:46.700 die hoffentlich diese Primzahl insgesamt sagt. 01:45:46.880 --> 01:45:51.420 Und das Ziel dieser Initiative ist es, diese Primzahl einmal zu sagen, 01:45:51.620 --> 01:45:55.680 bevor die nächste größere Primzahl gefunden wird. 01:45:55.760 --> 01:45:57.180 Wahrscheinlich kann man sich einfach mit selber multiplizieren 01:45:57.180 --> 01:45:58.740 und dann nochmal wieder eins abziehen, dann hat man das schon. 01:45:59.980 --> 01:46:03.600 Ja, diese Zahlen zu rechnen ist nicht so schwierig, 01:46:03.900 --> 01:46:06.420 aber das Beweisen, dass es eine Primzahl ist. 01:46:06.780 --> 01:46:08.940 Was ist die Schätzung, wie lange diese Playlist, 01:46:08.940 --> 01:46:12.160 wie viele Jahre die spielen wird? 01:46:13.400 --> 01:46:14.660 Wie lange braucht man eine Zeit? 01:46:14.820 --> 01:46:18.200 Sie sagen vor, dass man 01:46:18.200 --> 01:46:20.440 mit 120 BPM 01:46:20.440 --> 01:46:22.000 spricht. Das heißt, es wären 01:46:22.000 --> 01:46:23.480 zwei Ziffern pro Sekunde. 01:46:23.880 --> 01:46:25.020 Das heißt, es wären 01:46:25.020 --> 01:46:28.600 ungefähr 20 Millionen Sekunden. 01:46:29.860 --> 01:46:30.620 Das ist gar nicht so viel. 01:46:32.360 --> 01:46:33.200 20 Millionen Sekunden. 01:46:33.200 --> 01:46:34.120 Eine Million Sekunden ist 01:46:34.120 --> 01:46:36.240 ungefähr eine Woche oder so. 01:46:37.080 --> 01:46:38.220 Jetzt müssen wir es mal 01:46:38.220 --> 01:46:38.720 ausrechnen. 01:46:38.720 --> 01:46:40.520 Das ist ein halbes Jahr oder so. 01:46:41.740 --> 01:46:42.940 Warte mal, das sind 01:46:42.940 --> 01:46:45.700 41 Millionen Sekunden 01:46:45.700 --> 01:46:47.440 durch. 01:46:53.440 --> 01:46:54.080 243 Tage. 01:46:54.960 --> 01:46:55.520 Dreiviertel Jahr. 01:46:57.560 --> 01:46:58.540 Darum geht es ja gar nicht. 01:46:58.580 --> 01:47:00.800 Es geht gar nicht darum, dass es jemand sich dann anhört, 01:47:00.940 --> 01:47:02.860 sondern es geht darum, dass es einmal gesagt 01:47:02.860 --> 01:47:04.280 würde. Wir können ja jedes Mal 01:47:04.280 --> 01:47:06.480 in einer Episode, so in einer kleinen Episode von dieser 01:47:06.480 --> 01:47:07.620 Primzah mit sind. 01:47:08.180 --> 01:47:09.160 Einfach im Hintergrund laufen. 01:47:11.320 --> 01:47:11.720 Die 01:47:11.720 --> 01:47:13.920 jeder, wer 01:47:13.920 --> 01:47:15.840 möchte, kann daran teilnehmen. Es gibt ein sehr 01:47:15.840 --> 01:47:17.600 schönes Video von Matt Parker, wo er die Zahl 01:47:17.600 --> 01:47:18.780 einmal anzeigt 01:47:18.780 --> 01:47:21.480 in seinem Video. Also er 01:47:21.480 --> 01:47:23.640 hat dann, in jedem 01:47:23.640 --> 01:47:25.620 Frame zeigt er glaube ich tausend Ziffern an und 01:47:25.620 --> 01:47:26.860 das geht dann eben über 01:47:26.860 --> 01:47:29.500 so und so viele Sekunden oder 01:47:29.500 --> 01:47:31.760 vielleicht zeigt er zehntausend Ziffern in jedem Frame. Auf jeden Fall 01:47:31.760 --> 01:47:33.480 irgendwie dreieinhalb Minuten lang zeigt er diese 01:47:33.480 --> 01:47:34.880 Zahl an und spricht über die Zahl. 01:47:35.940 --> 01:47:37.580 Und das ist quasi das Audio-Äquivalent 01:47:37.580 --> 01:47:39.620 und jeder kann damit mithelfen 01:47:39.620 --> 01:47:41.580 und ich finde, jeder von uns 01:47:41.580 --> 01:47:42.480 sollte das tun? 01:47:43.520 --> 01:47:44.900 Das ist mein Pick für diese Woche. 01:47:45.340 --> 01:47:47.420 Saytheprime.com. Ich habe tatsächlich auch über die 01:47:47.420 --> 01:47:49.460 Priebsal nachgedacht, weil es ist nämlich 01:47:49.460 --> 01:47:51.600 relativ, ich finde es relativ lustig, 01:47:51.680 --> 01:47:53.800 dass man die in Python problemlos 01:47:53.800 --> 01:47:55.500 ausrechnen kann. Das ist überhaupt kein Problem. 01:47:55.840 --> 01:47:57.160 Einfach mal zwei hoch 01:47:57.160 --> 01:47:59.540 136 Millionen zu rechnen, 01:47:59.660 --> 01:48:01.440 das dauert quasi keine 01:48:01.440 --> 01:48:03.420 bemerkbare Zeit. Das sind so 16 Megabyte 01:48:03.420 --> 01:48:03.960 Zahl ungefähr. 01:48:05.000 --> 01:48:07.060 Vielleicht ein bisschen ineffizienter dargestellt, aber 01:48:07.060 --> 01:48:09.280 die zu printen ist 01:48:09.280 --> 01:48:10.820 komplett unmöglich, weil 01:48:10.820 --> 01:48:13.620 im 2er-System ist das halt eine sehr einfache 01:48:13.620 --> 01:48:15.420 Zahl, das sind lauter Einsen. 01:48:16.500 --> 01:48:16.840 Aber 01:48:16.840 --> 01:48:18.980 im 10er-System, 01:48:19.160 --> 01:48:21.500 um zu wandeln, das ist halt 01:48:21.500 --> 01:48:23.560 nicht linear zu machen, sondern das ist irgendwie 01:48:23.560 --> 01:48:24.860 N log N oder so. 01:48:25.700 --> 01:48:26.400 Und ja, 01:48:26.920 --> 01:48:29.460 es ist ja eh inzwischen standardmäßig 01:48:29.460 --> 01:48:31.280 so, dass man große Zahlen nicht mehr 01:48:31.280 --> 01:48:33.020 printen kann, 01:48:33.220 --> 01:48:34.640 standardmäßig gibt es dieses Limit. 01:48:34.720 --> 01:48:36.080 Das war auch irgendwie ein Security Problem. 01:48:37.000 --> 01:48:39.700 Aber selbst wenn man das Feature ausschaltet, 01:48:39.920 --> 01:48:41.040 dann dauert es halt einfach zu lang. 01:48:43.160 --> 01:48:43.680 Ja. 01:48:45.120 --> 01:48:45.960 Zum Glück 01:48:45.960 --> 01:48:47.740 kann man die Zahl runterladen. 01:48:48.200 --> 01:48:49.900 Auf messen.org gibt es 01:48:49.900 --> 01:48:51.320 eine ZIP-Datei, 18 Megabyte. 01:48:53.100 --> 01:48:53.880 Falls man die 01:48:53.880 --> 01:48:54.860 braucht für irgendwas. 01:48:56.380 --> 01:48:57.820 An den Leuten statt X 01:48:57.820 --> 01:48:59.260 schicken, statt den X-Sourcen. 01:49:00.940 --> 01:49:01.460 So. 01:49:03.060 --> 01:49:03.580 Ja. 01:49:04.320 --> 01:49:05.540 Gut, das ist mein völlig 01:49:05.540 --> 01:49:07.860 unkorrelierter Pick, 01:49:08.020 --> 01:49:09.840 aber es passt irgendwie in unsere 01:49:09.840 --> 01:49:11.740 Zeit rein. Und das ist alles relativ neu. Also es ist 01:49:11.740 --> 01:49:12.900 vom 21. Oktober, 01:49:13.880 --> 01:49:15.160 als die Bestätigung kam. 01:49:16.240 --> 01:49:17.540 Jochen, was denkst du denn? Oder CF? 01:49:17.720 --> 01:49:18.340 Ich meine, keine Ahnung. 01:49:18.560 --> 01:49:21.800 Ich würde ja ungern die Reihenfolge 01:49:21.800 --> 01:49:22.420 an völlig 01:49:22.420 --> 01:49:25.520 absolut nichts mit dem Thema zu tun haben, 01:49:25.620 --> 01:49:26.580 denn Pics 01:49:26.580 --> 01:49:29.700 unterbrechen. Ich habe auch einen, der 01:49:29.700 --> 01:49:31.360 gar nichts mit dem eigentlichen Thema 01:49:31.360 --> 01:49:33.740 dieser Episode zu tun hat oder auch nicht mit Python oder sonst 01:49:33.740 --> 01:49:35.680 irgendwas. Und zwar 01:49:35.680 --> 01:49:37.900 ich war jetzt letztens auf so einer Podcaster-Konferenz 01:49:37.900 --> 01:49:39.740 auf der Subscribe11 01:49:39.740 --> 01:49:40.160 in Berlin. 01:49:42.520 --> 01:49:43.700 Dieses Crap 10 ist 01:49:43.700 --> 01:49:45.420 übrigens schon vier Jahre her oder so. 01:49:45.440 --> 01:49:46.740 Fünf, die waren 2019. 01:49:47.660 --> 01:49:49.260 Da waren wir auch. 01:49:49.560 --> 01:49:51.300 Da gehen wir zunächst auch. 01:49:51.480 --> 01:49:53.080 Nix war jetzt gerade fünf Jahre später. 01:49:54.140 --> 01:49:55.700 Zwischendurch waren da so leichte 01:49:55.700 --> 01:49:57.320 Pandemie-Schwankungen 01:49:57.320 --> 01:49:58.260 am Start. 01:49:58.980 --> 01:50:03.060 Es war auch kleiner. 01:50:03.520 --> 01:50:05.020 Es waren deutlich weniger Leute da als 01:50:05.020 --> 01:50:07.840 vor fünf Jahren. 01:50:07.840 --> 01:50:09.640 Und das lag vor allen Dingen 01:50:09.640 --> 01:50:11.300 daran, dass inzwischen 01:50:11.300 --> 01:50:13.520 so Infrastruktur auch 01:50:13.520 --> 01:50:15.360 weggebrochen ist, die vorher ganz gut 01:50:15.360 --> 01:50:17.520 funktioniert hatte, nämlich Social Media. 01:50:18.120 --> 01:50:19.440 Also das war so ein Ding, alle, die man 01:50:19.440 --> 01:50:20.880 traf, sagten, naja, also klar, 01:50:21.400 --> 01:50:23.020 früher konnte man sowas, aber heute geht das ja nicht mehr, weil 01:50:23.020 --> 01:50:25.420 Social Media ist ja tot, daher kann man das nicht 01:50:25.420 --> 01:50:27.440 mehr machen. Also man kann zum Beispiel für so eine Konferenz 01:50:27.440 --> 01:50:29.380 auch nicht mehr gut Werbung machen, weil man kann den Leuten nicht mehr 01:50:29.380 --> 01:50:31.400 davon erzählen, weil, ja, 01:50:32.080 --> 01:50:33.680 wo will man es den Leuten 01:50:33.680 --> 01:50:35.240 denn noch erzählen? Es gibt ja irgendwie nichts mehr. 01:50:35.960 --> 01:50:37.420 Und dann war halt 01:50:37.420 --> 01:50:39.500 so die Frage, okay, was kann man denn jetzt tun, 01:50:39.640 --> 01:50:41.480 wenn es das nicht mehr gibt? Und da war eine 01:50:41.480 --> 01:50:43.480 der Antworten halt, ah, naja, 01:50:43.540 --> 01:50:45.020 wir haben ja doch irgendwie ein Medium, 01:50:45.780 --> 01:50:47.500 wir baden da gerade unsere Hände 01:50:47.500 --> 01:50:49.360 sozusagen drin. Warum 01:50:49.360 --> 01:50:51.300 sagen wir nicht irgendwie in unseren 01:50:51.300 --> 01:50:53.460 Podcasts quasi, dass es solche 01:50:53.460 --> 01:50:55.540 Sachen gibt? Und 01:50:55.540 --> 01:50:57.220 dann war auch die Idee, dass man da so ein bisschen 01:50:57.220 --> 01:50:59.380 Werbematerial oder so schon mal fertig macht, 01:50:59.460 --> 01:51:01.500 dass man das eigentlich direkt verwenden kann. Das ist dann noch nicht passiert, 01:51:01.620 --> 01:51:03.520 aber ich dachte, das kann ich jetzt 01:51:03.520 --> 01:51:05.640 mal nutzen, um das zu sagen, dass es sowas gibt. Und wenn man 01:51:05.640 --> 01:51:07.640 irgendwie da Interesse dran hat, kann man da auch hingehen. 01:51:08.140 --> 01:51:09.460 Auch als Hörer, da waren zum Beispiel 01:51:09.460 --> 01:51:10.840 Du meinst die nächste in fünf Jahren? 01:51:11.620 --> 01:51:13.240 Nee, die nächste ist schon in einem halben Jahr. 01:51:14.060 --> 01:51:15.520 Die Frequenz so ein bisschen erhöhen 01:51:15.520 --> 01:51:17.440 und die nächste ist daher schon 01:51:17.440 --> 01:51:19.360 im Frühjahr nächsten Jahres und 01:51:19.360 --> 01:51:21.340 es gab am Anfang so eine Vorstellungsrunde, wo 01:51:21.340 --> 01:51:23.400 alle gesagt haben, was sie so tun und da waren 01:51:23.400 --> 01:51:24.840 tatsächlich ein paar Leute dabei. 01:51:25.080 --> 01:51:25.300 Eine 01:51:25.300 --> 01:51:30.820 Person hier auch aus Düsseldorf, die sie 01:51:30.820 --> 01:51:32.680 bezeichnet sich als Extremhörerin 01:51:32.680 --> 01:51:35.460 und es waren 01:51:35.460 --> 01:51:37.360 auch viele Hörer da. Es war sehr schön. 01:51:37.360 --> 01:51:39.420 Schöne Veranstaltung. Weißt du, wo die nächste ist? 01:51:39.860 --> 01:51:40.300 Auch Berlin. 01:51:41.400 --> 01:51:43.660 Gleiche Location, also Weißensee. 01:51:44.600 --> 01:51:45.800 Und in Mai... 01:51:45.800 --> 01:51:47.380 Wie viele Stunden ist man extrem höher? 01:51:48.980 --> 01:51:49.700 Pro Tag? 01:51:49.980 --> 01:51:51.580 Ja, viele, viele pro Tag. 01:51:51.600 --> 01:51:52.380 20 oder so? 01:51:52.920 --> 01:51:54.460 Und sie meinte, ich war 01:51:54.460 --> 01:51:57.640 auf einem Hörertreffen 01:51:57.640 --> 01:51:59.760 am Samstagabend von einem anderen Podcast 01:51:59.760 --> 01:52:00.860 und 01:52:00.860 --> 01:52:02.940 da ist halt so, ja, also 01:52:02.940 --> 01:52:05.680 es ist immer schwer zu sagen, 01:52:05.760 --> 01:52:07.220 wie viele Stunden Podcast ich denn jetzt so höre, 01:52:07.300 --> 01:52:08.740 weil ich höre immer auf irgendwie 01:52:08.740 --> 01:52:11.560 so zweieinhalbfacher Geschwindigkeit, 01:52:11.740 --> 01:52:12.960 worauf alle am Tisch so 01:52:12.960 --> 01:52:17.700 ja, da muss man sich langsam rantasten. 01:52:17.800 --> 01:52:18.660 Da fängt man nicht mit an. 01:52:18.820 --> 01:52:22.200 Man fängt zuerst an mit so 1,2 und dann 1,5 01:52:22.200 --> 01:52:23.840 und dann geht das immer langsamer. 01:52:23.860 --> 01:52:24.900 Schnell als 1,5 ist das schon. 01:52:25.720 --> 01:52:27.540 Ja, aber inzwischen kann ich das halt auch gar nicht mehr 01:52:27.540 --> 01:52:28.560 auf einfache Geschwindigkeit hören, 01:52:28.680 --> 01:52:29.380 weil dann denke ich mir so was. 01:52:29.680 --> 01:52:30.960 Ja, bei den meisten kostet das für mich auch nichts. 01:52:31.240 --> 01:52:33.800 Ich finde es ja total lustig. 01:52:33.800 --> 01:52:35.500 Also man gewöhnt sich ja da wirklich total dran. 01:52:35.720 --> 01:52:37.680 höre, also ich bin nicht so extrem, ich höre vielleicht 01:52:37.680 --> 01:52:39.220 1,2 oder 1,5 oder so 01:52:39.220 --> 01:52:41.740 und an das Sprechen gewöhnt man sich total. 01:52:42.260 --> 01:52:43.800 Aber wenn man so eine Zeit 01:52:43.800 --> 01:52:45.660 lang irgendwas mit normaler Geschwindigkeit 01:52:45.660 --> 01:52:47.740 und dann erhöht gehört hat, die Jingle klingt immer 01:52:47.740 --> 01:52:49.780 falsch. Also selbst Jahre, 01:52:49.900 --> 01:52:51.180 ich höre jetzt, was weiß ich, 01:52:52.480 --> 01:52:53.720 wie heißt der Microsoft 01:52:53.720 --> 01:52:54.960 C-Sharp-Typ? 01:52:57.100 --> 01:52:58.000 Hansel Minutes? 01:52:59.420 --> 01:52:59.960 Höre ich 01:52:59.960 --> 01:53:01.940 seit Jahren 20% 01:53:01.940 --> 01:53:03.720 schneller, die Jingle klingt immer noch falsch. 01:53:03.960 --> 01:53:09.420 Ja, es gibt so gute 01:53:09.420 --> 01:53:11.560 Dingles, die hören sich auf unterschiedlichen Geschwindigkeiten ähnlich 01:53:11.560 --> 01:53:12.500 interessant an. 01:53:13.700 --> 01:53:14.560 Ich habe einen Python-Pick. 01:53:15.980 --> 01:53:17.420 Es gibt eine super 01:53:17.420 --> 01:53:19.500 kleine Studie von Erit Katril, das ist eine 01:53:19.500 --> 01:53:21.200 C-Python-Core-Entwicklerin, 01:53:21.880 --> 01:53:23.580 die eine Studie darüber gemacht hat, 01:53:24.500 --> 01:53:25.080 wie viel 01:53:25.080 --> 01:53:27.180 PyPI-Pakete Return, 01:53:27.380 --> 01:53:29.240 Break oder Continue-Anweisungen in 01:53:29.240 --> 01:53:31.300 Finally-Blöcken machen. Weil es gab 01:53:31.300 --> 01:53:33.100 nämlich so eine kleine Diskussion darüber, dass man, 01:53:33.220 --> 01:53:37.460 ob man vielleicht, also Except-Doppelpunkt, 01:53:37.540 --> 01:53:42.060 also ohne Angabe einer Exception-Typ abschaffen sollte. 01:53:42.180 --> 01:53:43.520 Irgendwann in einer der nächsten Versionen, 01:53:43.580 --> 01:53:45.860 da gab es total viel Gegenmeinung 01:53:45.860 --> 01:53:47.760 und dann haben sie das Vorhaben auch wieder aufgegeben. 01:53:47.900 --> 01:53:50.100 Aber eine der Ergebnisse von der Diskussion war eben, 01:53:50.100 --> 01:53:51.980 einfach mal zu gucken, wie sieht das denn mit Finally aus? 01:53:53.240 --> 01:53:54.980 Und Return, Break und Continuum in Finally 01:53:54.980 --> 01:53:56.520 haben ja so ein bisschen so komische Effekte. 01:53:56.600 --> 01:53:58.980 Wenn man Return macht, dann wird die Exception geschluckt. 01:53:59.660 --> 01:54:01.940 Also wenn ich quasi Try-Finally habe 01:54:01.940 --> 01:54:03.980 und der Code 01:54:03.980 --> 01:54:05.820 wirft eine Exception und in dem Finally-Block 01:54:05.820 --> 01:54:07.880 mache ich dann Return. Dann return 01:54:07.880 --> 01:54:09.820 ich halt einfach von der Funktion und die Exception 01:54:09.820 --> 01:54:11.980 verschwindet. Und deswegen 01:54:11.980 --> 01:54:14.000 hat Irit eben gesagt, sie schaut mal 01:54:14.000 --> 01:54:15.320 wie das in, 01:54:15.560 --> 01:54:17.680 hier steht irgendwo, wie viele Pakete sie sich angeschaut hat, 01:54:17.780 --> 01:54:19.660 die 8000 beliebtesten 01:54:19.660 --> 01:54:20.860 PyPI-Pakete 01:54:20.860 --> 01:54:23.680 analysiert, eben ein Skript geschrieben, 01:54:23.800 --> 01:54:25.760 was die abstrakten 01:54:25.760 --> 01:54:27.740 Syntaxbäume durchgeht und schaut, ob eben 01:54:27.740 --> 01:54:29.600 das Finally-Block hier mit 01:54:29.600 --> 01:54:30.660 break, continue und return 01:54:30.660 --> 01:54:34.060 drin vorkommen und dann von Hand analysiert, 01:54:34.060 --> 01:54:38.620 wie viele von denen quasi wirklich so sein sollen 01:54:38.620 --> 01:54:40.200 und wie viele von denen Bugs sind. 01:54:40.360 --> 01:54:42.200 Also es waren 120 Millionen Zeilen Python 01:54:42.200 --> 01:54:49.560 und darin waren 200 Fälle von Kontrollflussinstruktionen 01:54:49.560 --> 01:54:53.260 in Feinlieblöcken, davon waren 46 korrekt, 01:54:53.940 --> 01:54:58.380 aber diese 46 waren lauter Tests in irgendwelchen Lintern, 01:54:58.600 --> 01:55:00.500 die eben sicherstellen wollten, dass der 01:55:00.500 --> 01:55:02.360 Linter sagt, bitte verwende kein Return in 01:55:02.360 --> 01:55:04.280 Finally. Acht Fälle 01:55:04.280 --> 01:55:06.200 waren wirklich korrekt, also wirklich, wo 01:55:06.200 --> 01:55:08.080 das quasi gewollt ist, dass die Exception 01:55:08.080 --> 01:55:09.940 dann geschluckt wird. Und 01:55:09.940 --> 01:55:12.060 149 waren dann eben 01:55:12.060 --> 01:55:14.140 Bugs, die 01:55:14.140 --> 01:55:16.020 Katarina dann auch immer bei den entsprechenden 01:55:16.020 --> 01:55:18.040 GitHub-Repositories gemeldet hat 01:55:18.040 --> 01:55:19.720 und die meisten dieser Bugs werden jetzt gefixt. 01:55:20.600 --> 01:55:22.160 Also so sieht schon so ein bisschen 01:55:22.160 --> 01:55:24.120 aus, als wäre das jetzt nicht so das wichtige Feature und 01:55:24.120 --> 01:55:25.900 auch ein Feature, was vielleicht 01:55:25.900 --> 01:55:26.900 eher zu 01:55:26.900 --> 01:55:30.180 ja, zu 01:55:30.180 --> 01:55:32.860 Missanwendungen als zu korrekten 01:55:32.860 --> 01:55:34.400 Anwendungen führt. Sehr schön. 01:55:34.940 --> 01:55:36.660 Ja. Und wenn ihr wollt, habe ich noch 01:55:36.660 --> 01:55:38.640 einen mega nerdy Pick. Oh ja. 01:55:38.960 --> 01:55:39.680 Es gibt ein Paper, 01:55:40.880 --> 01:55:42.740 was ein C-Compiler für eine 01:55:42.740 --> 01:55:44.520 sehr kleine Teilmenge von C 01:55:44.520 --> 01:55:46.740 nach Shell 01:55:46.740 --> 01:55:47.160 übersetzt. 01:55:49.120 --> 01:55:50.420 Das ist 01:55:50.420 --> 01:55:52.240 vollständig genug, dass der C-Compiler 01:55:52.240 --> 01:55:54.260 sich dann, wenn er sich selbst 01:55:54.260 --> 01:55:56.360 nach Shell übersetzen kann, und dann 01:55:56.360 --> 01:55:58.300 kann ich quasi, wenn ich nur irgendeine 01:55:58.300 --> 01:56:00.400 beliebige Unix-Shell habe, kann ich einen 01:56:00.400 --> 01:56:02.080 sehr kleinen C-Compiler 01:56:02.080 --> 01:56:02.640 bootstrappen. 01:56:04.540 --> 01:56:04.560 Und 01:56:04.560 --> 01:56:07.140 also die haben auch Gründe, 01:56:07.520 --> 01:56:10.260 das sind irgendwelche Forscher, die gute Gründe 01:56:10.260 --> 01:56:11.140 dafür haben, warum sie das machen. 01:56:11.880 --> 01:56:12.640 Die haben Gründe. 01:56:13.060 --> 01:56:16.040 Die haben so Trusting-Trust-Gründe, also damit 01:56:16.040 --> 01:56:17.880 kann man halt sicherstellen, dass man keine langlebigen 01:56:17.880 --> 01:56:20.040 Backdoors im Compiler hat, aber 01:56:20.040 --> 01:56:22.180 die Gründe sind mir egal. Warum ich das toll finde, 01:56:22.180 --> 01:56:24.280 ist, es gibt ja immer 01:56:24.280 --> 01:56:26.160 diese Argumente, C ist eine schnelle Sprache, weil 01:56:26.160 --> 01:56:28.080 die ist compiled und Python ist eine langsame Sprache, 01:56:28.240 --> 01:56:29.760 die ist interpretiert und 01:56:29.760 --> 01:56:31.760 von solchen Argumenten halte ich gar nichts, weil 01:56:31.760 --> 01:56:34.080 das ist halt eine Eigenschaft der Implementierung, 01:56:34.660 --> 01:56:35.980 ob was compiled oder 01:56:35.980 --> 01:56:37.800 interpretiert ist. Ich kann halt kompilierte 01:56:37.800 --> 01:56:39.900 Python-Implementierung haben und interpretierte und 01:56:39.900 --> 01:56:41.960 das sagt jetzt, also das ist keine inhärente 01:56:41.960 --> 01:56:43.880 Eigenschaft der Sprache und das ist einfach so 01:56:43.880 --> 01:56:44.640 ein schönes 01:56:44.640 --> 01:56:47.660 Gegenbeispiel, dass ich quasi eine 01:56:47.660 --> 01:56:49.820 kompilierte Version von C habe, die halt 01:56:49.820 --> 01:56:51.440 trotzdem ultra langsam ist. 01:56:53.680 --> 01:56:54.120 Okay, 01:56:54.300 --> 01:56:54.700 sehr schön. 01:56:55.240 --> 01:56:56.020 Ja, sehr schön. 01:56:57.120 --> 01:56:58.600 Ja, ich würde sagen, das war ein passendes Schlusswort. 01:56:59.420 --> 01:56:59.560 Ja. 01:57:00.480 --> 01:57:02.880 Jetzt könnt ihr auch wieder runterdrehen, eure Geschwindigkeit beim Hören. 01:57:03.840 --> 01:57:04.240 Und 01:57:04.240 --> 01:57:07.020 wünschen euch einen wunderschönen Tag, 01:57:07.160 --> 01:57:08.940 wunderschöne Nacht, wunderschönen Morgen, wunderschönen 01:57:08.940 --> 01:57:10.480 Aufdehnen. Bleibt uns gewogen, 01:57:10.580 --> 01:57:12.680 hallo at peißenpodcast.de für alles Feedback und so weiter. 01:57:13.420 --> 01:57:13.800 Bis bald. 01:57:13.800 --> 01:57:15.040 Ja. Tschüss. 01:57:15.480 --> 01:57:16.140 Tschüss.