Transkript: Platonismus und Python - Data Class Builders

Hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode 66.

Oha.

Heute quatschen wir über das nächste Kapitel MFL in Python-Buch, falls euch das interessiert über Data Classes und warum das riecht oder nicht oder was Cooles und wer das sonst so ist mit Sachen.

Hi Johannes.

Hallo, hallo Dominik, hallo Jochen.

Hi Jochen.

Ja, hallo Dominik, hallo Johannes.

Ich hab gehört, lieber Jochen, du wolltest.

Du warst auf einem Podcast-Barcamp.

Genau, und dann habe ich so gesagt, wie wir Podcasts aufnehmen und dann

haben wir gesagt, das ist alles falsch.

Ja, das hat mich so leicht irritiert, aber dann dachte ich, ja gut, dann höre ich mal vielleicht, was so Leute zu sagen haben.

Wir haben ja vielleicht auch Erfahrung und so.

Weil wir unseren Podcast an anderen Podcast machen, als die ihren Podcast machen und deswegen machen wir das jetzt so, wie die anderen Leute, die nicht so einen Podcast machen, wie wir den Podcast machen, wie wir das richtig machen.

Also ich habe mich auch mit Leuten unterhalten und die haben dann mal so geguckt, ich glaube, das geht gar nicht so schlecht.

Ja, das geht schon, aber ich meine, wir machen das ja nicht so richtig professionell, sondern...

Nein, nein, das auch nicht.

Aber also zum Beispiel irgendwie ein Ratschlag war halt so, ja, sagt doch vorher, wenn ihr euch vorstellt, einmal macht das immer gleich quasi wie der Gefängniswerk.

Es wäre auch so eine Intro-Melodie oder so, wäre nicht so schlecht, dann dachte ich schon so, oh Gott, oh Gott, Gott.

Aber ja, ich habe gehört, es gibt Leute hier unter uns,

wenn meinen eigenen Jingle schreiben, dann mache ich den auf meinen Style und dann können wir ja gucken, wenn der Reflein runtergeht.

Kann man sich die Kurve angucken.

Ja, in meinen eigenen Jingle.

Immer wenn ich dabei bin, muss der am Anfang eingespielt werden.

Das ist eigentlich eine coole Idee.

Ja, okay, dann sieht die, wie viele Leute hören, noch Zukurve wahrscheinlich aus wie so Acapulco, Klippenspringer irgendwie ins Nichts.

Das vielleicht auch nicht so toll.

Ja, aber ich finde, wie wir es sonst so machen, wir haben ja eigentlich schon mehr eine Struktur als wir es denkst auch.

Also erstens kennen uns ja die Leute und wenn die sich dafür interessieren, wie wir sind oder interessieren würden, also ganz ehrlich, dann können Sie uns auch fragen, ne?

Hallo.pythonpodcast.de.

Also wir machen irgendwas mit Python, das hat man vielleicht schon mal rausgehört.

Ich glaube, das ist auch offensichtlich.

Und viel mehr muss man, glaube ich, gar nicht wissen.

Also muss man nicht, kann man natürlich gerne, dafür kann man ja fragen, oder uns kennen unseren Hörer treffen, das bald stattfindet.

Wir organisieren das nämlich.

Wir haben noch immer noch gar keinen festen Termin, aber ich würde wahrscheinlich auf August, September hinauslaufen.

Ja, aber ich fürchte, das müssen wir jetzt sagen.

Danke doch.

August oder September.

Das ist kein fester Termin, oder?

Nein.

Dann müssen wir jetzt nochmal kurz unserem Kalender übereinander liegen.

Also ich glaube, tatsächlich wird es eher Ende August bis Anfang September werden müssen wegen Schulferien.

Ja, Anfang September bin ich übrigens im Urlaub.

Ja, das musst du leider absagen, das geht halt nicht.

Na gut, dann wird es halt vielleicht eher sogar Ende September.

Okay, dann sagen wir, okay, wir schieben die Ankündigung auf nächste Episode, die dann hoffentlich im Juli.

Also es sollte noch gutes Wetter sein, wir wollen es nämlich draußen machen.

Und okay, wir hatten September auf, wirklich.

Was ist mit August?

Geht nicht gut.

Wie gesagt, das ist ein schönes Schwester.

Okay, geil, dann wir diskutieren das später aus.

Wir haben auf jeden Fall das Hörerentreffen.

Sagt gerne Bescheid, wenn ihr vorbeikommen wollt.

Es ist hier in der Gegend, also hier heißt Rheinland-Düsseldorf.

Wir können ja schon mal sammeln, also wenn ihr uns irgendwas an hallo.python-podcast.de schreibt, dann notifizieren wir euch, sobald wir genaueres wissen.

Genau.

Und es wird wahrscheinlich draußen irgendwie.

Draußen gibt vielleicht auch Sätzen Dinger.

Ja.

Okay.

Genau.

Ja.

Das so zur anderen Struktur, Jochen.

Wir machen immer News.

Ja, wir machen News.

Cool.

Dann machen wir doch gerade ein bisschen News.

Aber vorgestellt hat sich jetzt keiner, oder?

Der Jochen wollte ja zu schön hinfahren und jetzt hat sich keiner eingestiegen.

Wer bist du denn?

Deine sehr herzlich die wichtigen Leute.

Stellt euch mal vor.

Ja, aber man muss ja mal die anderen vorstellen.

Man kann sich ja nicht gut selber vorstellen.

Also ich stelle mal die Dominik vor, Dominik ist

schon nichts sein.

Ja, schon ist vorbei.

Also meine drei Hashtags sind Python, Eurorec und

Agentic, ja.

Okay, Mist, jetzt sind alle guten Hashtag schon weg, meins wären irgendwie, ja.

Setzt mal Python Podcast.

Ja, Ukulele, Ukulele ist auch so, genau.

Ich habe auch noch ein paar andere Instrumente, aber ja.

Und Johannes, sollen wir.

Ja, also ich, äh, hallo, ich bin Johannes.

Für die, die mich nicht kennen, ich bin gelegentlich hier im Python Podcast als Gast, weil ich diese beiden anderen Typen da kenne.

Ich komme

nicht aus dem Rheinland.

Du warst aber mal hier.

Ich war mal im Rheinland, ja, aber es hat sich dann als ich musste wieder weg.

Tja.

Und jetzt bin ich hier hat es übrigens 800 Sonnenstunden im Jahr mehr als bei euch im Rheinland.

Erstmal so nebenbei.

Deshalb bin ich auch so ein sonniges Gemüt.

Ihr seid so traurige.

Ja, richtig.

Also meine.

Du kennst übrigens alle aus dem Chaos-Umfeld so ein bisschen mehr oder weniger auch, oder?

Können wir schon sagen.

Ja, den Jochen habe ich im Computerclub kennengelernt.

Ja, genau.

Also, ja, mich auch.

Meine Hashtags.

Django, Mathematik und Spiele.

Spiele, richtig.

Absolut korrekt.

Ah, cool.

Hört man schon am Namen.

Ja.

So, eben.

Nomen-Sto, Omen.

Ja.

Okay, gut, dann können wir ja jetzt nahtlos mit den News einsteigen.

Perfekte Struktur.

Sehr gut, sehr gut.

Ich konnte nicht so viel sammeln, weil ich momentan total im Stratz bin.

Also ich bin privaten.

Ganz kurz nochmal zeigt über das Barcamp.

Also das ist jetzt vielleicht nicht so interessant für alle Python-Leute, aber für alle Leute, die Podcasts mögen schon.

Es gab da nämlich eine tolle Veranstaltung, wo man, also Barcamps kennt ihr vielleicht, aus dem Softwareumfeld, wo man ganz viele nette Podcast-Menschen kennengelernt hat.

Ich möchte nochmal Danke sagen für die tollen Kontakte, die ich da getroffen und kennengelernt haben durfte.

Ja, Grüße an hier Working Draft zum Beispiel.

Auch einen Podcast aus dem Schluss.

Ich habe nicht gut

gehört, aber gute Tipps waren ja zusammen eine Episoden aufnehmen.

Ja, mit Working Draft, der doch mal wieder eine Idee.

Und wir haben auch schon konkret geplant, was zusammen mit wo wir sind, ist vorne zu machen.

Die kennen wir auch gut und treffen uns immer wieder auf allen möglichen Konferenzen und so, aber genau, ist bisher noch nicht so richtig zustande gekommen, aber wir sind auf jeden Fall da auch noch dran.

Ja, das war so ein Tipp.

Irgendwie besucht euch auch einfach gegenseitig.

Auch ein guter Tipp war halt, ja, schaut nicht nur nach so irgendwie totalen Berühmtheiten oder so, auch wenn die, wenn das auf dem Papier oder so, erstmal, wenn man drüber nachdenkt, gut aussieht, aber.

Meinst du, Guido?

Ich wollte immer schon mal

Guido haben.

Ja, aber das ist halt mit Englisch vielleicht ein Problem.

Mit Sarah war das jetzt mal eine Ausnahme, aber.

Ja, aber da gibt es ja schon Leute.

Ja, gibt es auch, auf jeden Fall.

In der deutschsprachigen Welt gibt es Palsenmenschen.

Genau, genau, gibt es eigentlich auch genug.

Guido spricht immer schon Dutch.

Aber das Problem ist halt bei Leuten, die zu bekannt sind, auch, dass man die dann halt oft schon gehört hat.

Und wenn man nicht, weiß nicht, dass die dritte Episode mit.

Es gibt doch jetzt demnächst so einen tollen Python, den Film.

Ja, es gibt im Sommer, soll jetzt rauskommen, ich weiß gar nicht genau wann, genau, da gab es einen Trailer, habe ich gesehen.

Snacks on the Plane?

Ja, den gab's schon, aber scheint Python.

Nee, das ist so ein.

Python die Story, irgendwie, ich weiß

nicht, irgendwelche Leute machen das immer und über Even You haben sie zum Beispiel ein Ding gemacht, das war ziemlich gut, das habe ich gesehen.

Und über andere Leute.

Der Typ wird View.js und jetzt Roldown, habe ich gelesen.

Und genau, das gibt es jetzt auch über Python und soll wohl auch, also der Trailer sah auch gut aus und ja, wollen wir mal schauen, wie das so wird.

Genau.

Ja, naja, genau.

Wir sind auf so ein Podcamp gegangen, so ein Barcamp-Podcast.

Und immer Konferenzen für mich besonders attraktiv, wenn ich halt irgendwie zu Fuß hinlaufen kann.

Ich bin irgendwie bequem an der Stelle und das war halt hier in der Zentralbibliothek am Bahnhof in Düsseldorf, was auch ein total cooles Ding ist irgendwie.

Und weil man kann die ganzen Räumlichkeiten auch für alles möglich verwenden, man muss es nur irgendwie anmelden und sagen.

Und jedes Mal, wenn man da vorbeiliefen, gerade auf dem Gang, wie man es bei so Konferenz macht, kurz ein Gespräch wird keiner vorbei und hatte.

Ja, das soll aber eigentlich nicht so sein, weil eigentlich hat man dieses, irgendwie, man muss halt leise sein, in der Bibliothek Konzept da nicht mehr.

Es ist auch so, dass man da Essen mit reinnehmen darf und so.

Und man sagt da, also ich habe dann so eine Führung damit gemacht und die sagt, naja, nee, wir wollen das irgendwie anders machen und nicht mehr so wie früher.

Und man kann da auch was essen und man kann da auch irgendwie ein bisschen lauter sein, das ist alles kein Problem.

Und es gibt nicht nur Bücher, sondern es gibt auch so, weiß ich nicht, so Laserentfernungsmesser und 3D-Drucker und VR-Brillen und ein Podcast-Studio und ein Ding, wo man super acht-Filme digitalisieren kann und auch Alte Dias digitalisieren kann.

Und ein Videorekorder.

Und ein Musikstudio, wo man leider aber nicht drin laut sein darf.

Da darf man nur digitale Instrumente drin verwenden.

Weil daneben diese juristische Fachbibliothek ist, wo die Leute dann lernen für Prüfungen.

Und das hat sich dann herausgestellt, dass das eine ungünstige Kombination ist.

Das klagt nicht gleich.

Das, ja, gut, hätte man auch vorher drauf kommen können, aber das musste wohl irgendwie erstmal eskalieren und jetzt darf man da nicht mehr singen.

Eigentlich schade.

Naja.

Ja, schade.

Aber es gibt auch Backformen.

Ich habe das einmal gesehen, es ist Bücherei für Backformen.

Genau, so Bücherei der Dinge nennen die das.

Da gibt es auch so Fußball, Backformen und so Zeugs.

Also wirklich Geburtstagskids für alle möglichen Geburtstagspartys und so.

Also wirklich, wirklich, und man kann da halt sich hinsetzen und arbeiten.

Es sind 600 Arbeitsplätze in dem Ding.

Also es ist halt auch irgendwie echt groß.

Es sind zwei Fußballfelder groß.

Und es gibt jede Menge Räume für alles mögliche.

Und wie gesagt, man muss halt nur sagen, ich hätte gerne den Raum für den und den Zweck und dann überlegen die und dann sagen sie einem, nee, du stinkst oder ja, kannst du haben.

Und in der alten Zentralbibliothek, da war ich vielleicht zwölf oder sowas, da stand so ein Computer drin rum.

Und der war halt ganz gemeing gesichert, also dachten sie.

Und da konnte man so ein paar Sachen machen, heimlich.

Und dann Sachen ausprobieren.

Tja, das weiß ich, also da gibt es auch eine Menge.

Nämlich nach der Schule früher bin ich immer in die Bibliothek gefahren, das war.

Ja, das habe ich auch.

Ich hab nicht nur nach der Schule.

Aber ob ich da jetzt meine Kinder hinlassen würde, ich weiß nicht so genau.

Ja, das ist ja egal.

Aber also, wie gesagt, ich wusste gar nicht, dass es so ein Ort gibt und dass es irgendwie, dass man so coole Sachen macht.

Da gibt es auch Bücher über Peisenjochen.

Ja, da gibt es ja Flutchen.

Bücher gibt es auch.

Ja, ja, da werde ich mir nicht.

Aber es gibt eine Fernleihe, über die man halt eine Menge kriegt.

Darüber wollten wir gleich reden.

Und die liefert dann halt auch an die nächstgelegene Bibliothek.

Also man kann das auch online machen und dann kann man die Sachen dann lokal abholen.

Und bei uns ist die nächstgelegene Bibliothek irgendwie ein paar hundert Meter entfernt.

Genau, also wir fliegen auch mal zu unserer Stadtteilbibliothek.

Ja, und man kann die Bücher auch überall zurückgeben und so.

Also es ist wirklich, also ich war überrascht.

Es war überhaupt nicht.

Dort hat Tonis Ausleihen.

Das auch, ja.

Ja, genau, genau.

Also da hat das Ganze irgendwie stattgefunden.

Ja, also wir haben ein paar tolle Tipps bekommen für Marketing und was man nicht alles machen soll.

Das heißt, wir machen jetzt ganz viel Marketing.

Viel Spaß damit.

Für uns bestimmt gut, für euch, ja, ihr müsst halt damit leben.

Ja, nee.

Wir haben tatsächlich überlegt, ob wir ein Video mal aufnehmen wollen.

Genau, ob wir ein bisschen mehr Video machen.

Also ich habe das schon länger überlegt, aber ja, das war so auch eine der Geschichten, wo Leute sagen, ja, das muss man im Grunde irgendwie, wenn man Social Media Presence Interact.

Man muss das schon irgendwie machen.

Ja, man gewinnt halt einen Hörerkreis auf YouTube, oder?

Also dass die Leute, die YouTube gucken, die machen.

Ja, und gar nicht mal unbedingt die Podcast-Episoden selber, aber dass man zumindest da ist und da gefunden wird für die Leute, die halt nur auf YouTube sind und dann halt da einen Trailer hat, dass sie halt wissen, oh, es gibt den Podcast, ich muss da vielleicht irgendwie auf meinem Podcatcher der Wahl oder auf.

Total steil, Johannes.

Und da stehen die Fans hinterher auch vor deiner Tür und klopfen heimlich.

Groupies.

Ja, also oder was mich auch.

Was ich auch total cool fand, war, wie Leute darüber gesprochen haben, wie sie halt ihre Workflows halt so ein bisschen automatisieren mit so diversen Tools und was man da alles machen kann an Automatisierungen von irgendwie, ja, was man.

Oder über, ja, also es gab.

Da sind wir bei einer anderen geplanten Folge übrigens mit, aber nicht über Podcasts, sondern wir wollten auch bald nochmal wieder bei so Data Science Kram reden und dann auch nochmal über die ganzen neuen KI-Sachen.

Darf ich KI sagen?

Ich weiß nicht.

MCPs und so.

Ja, ich glaube, man darf KI musste sagen.

KI.

Achso, Entschuldigung.

Du hast eben so einen tollen Link geschickt, der dazu passt.

Ja, ich habe auch tatsächlich noch News, weil es gibt eine interessante Veröffentlichung vom MIT Media Lab mit dem Titel Your Brain on ChatGPT, die gerade so ein bisschen durch die News gegangen ist.

Ja.

Wo sie untersuchen, was das denn für Auswirkungen hat.

Also ich meine, es ist natürlich sehr reißerisch und die Studie hat 54 Teilnehmer, also es ist jetzt nicht kein repräsentativer Querschnitt durch die Gesellschaft.

Aber es gab wohl signifikante Unterschiede zwischen Menschen, die LLMs benutzen oder nur eine Search Engine oder Brain Only in Klammern, No Tools.

Das ist eine sehr schöne Bezeichnung.

Und was war besser für was?

Man kann sich Sachen besser merken, wenn man sie nicht von einem LLM erzeugen lässt oder wenn man sie es nicht von einem LLM vorkauen lässt.

Ja gut, das ist ja keine Überraschung, dass wenn man das wissen jetzt nicht selber erarbeitet hat, dass das dann flückt wird.

Ja, aber auch Suchmaschine.

Also auch wenn du normal bei Google oder bei irgendwas anderem eintippst und nicht diese KI, Kagi, ich benutze Kagi, benutzt.

Wenn man nicht diese KI-Zusammenfassung benutzt, ist die Retention wohl deutlich besser.

Und das Interessante ist eigentlich, dass

man so durch die News Everything it says.

Bitte, ich habe es gerade nicht verschwunden.

Das Interessante finde ich eigentlich, dass diese Studie so durch die News geht und dass die so überall zitiert wird, weil es halt schon so ein bisschen dieses Gefühl reflektiert von ja, vielleicht ist es doch nicht so gut für uns.

Ja, aber ist das nicht immer eine Neuigkeit?

Ich meine, die meisten, also viele Leute sind halt so doch eher so im Modus News.

Genau.

Meckender Rentner im Fenster mit einem Kissen und Kultur-Pessimismus kommt halt immer gut an.

Das ist halt immer eine Schlagzeile.

Aber Jochen, wir sind ja so langsam in so einem Alter.

Achso, genau, und hast du gesehen noch, jetzt haben sie für zwei Straßen weit haben sie die Straße gelb gestrichen.

Das habe ich nicht gesehen.

Unglaublich.

Also was die jungen Leute heute machen, das hätte es bei uns früher nicht gegeben.

Das waren nicht die jungen Leute, das haben sie richtig mit Teams gemacht, die dann angerückt sind und alles verschönern wollten, haben sie alles mit der stinkenden Farbe angestrichen und dann hinterher wollten sie einen Garten da drauf machen, ja.

Also der Dominik ist auch in dem Alter, wie ihr gehört.

Genau.

Ja, also ich verstehe, wie diese medialen Mechanismen funktionieren, die halt dazu führen, dass das halt immer Schlagzeilen und Neuigkeiten sind, aber ich habe große Zweifel, dass das quasi ein repräsentatives Bild davon zeichnet, was irgendwie so passiert.

Ist es sicherlich nicht.

Aber die Anzeichen davon, dass Leute auf diese Dinge vertrauen und dann auf solche Fakten reinfallen oder auf solche ausgedachten Sachen, ja, dass mal, dass Ungarn auch Holland genannt wird.

Ja, dieses Vertrauen ist da halt schon sehr groß.

Ich habe Chat gefragt, mit der meine Schule ausgesucht und ja.

Das wird da als Suchersatz benutzt.

Also ganz klassisch doch.

Ja, finde ich ganz toll.

Also da bin ich zu alt dafür, das finde ich ganz komisch.

Also Leute denken, das ist aber auch komisch, dass es nicht direkt die Wahrheit gesagt hat oder dass man da ja so ein paar Informationen hatte, die man so mal kurz überprüfen konnte.

Gut, das mit der Medienkompetenz ist halt ein Problem, aber das war auch schon immer ein Problem.

Ich meine, ich erinnere mich noch, als Internet und Google neu waren.

Oder das Fernsehen, genau, als das Fernsehen neu war, auch als das Radio neu war, irgendwie War of the Worlds, war auch ein großes Medienkonfetenz.

Damals, als man den Propheten noch wirklich glauben konnte.

Ja, also es ist ein wiederkehrendes Muster.

Bei Plato gibt es das schon, der Wetter da gegenüber.

Im Fall der Jugend, sowieso.

Also ich würde mal einfach sagen, man kann es so, Plato hat nicht recht gehabt.

Und das mit der Schrift war schon Fortschritt.

Und alle anderen.

Ich würde ihn jetzt aber ganz schön atzen.

Ja, aber ich denke, du bist den

kratzen nicht mehr.

Ja, auf der Seite natürlich schon, bin ich auch irgendwo ein Plato-Fanboy.

Das ist richtig, ja.

Ja, das können wir in der MCP-Folge nochmal genauer auslassen.

Ja, wobei, du hattest ja den Hashtag Mathematik, da habe ich ja einen Haken um da mich rein.

Ich habe jetzt eine Podcast-Episode gehört mit Terence Howe.

Ja, der jetzt auch anfängt.

Oder der jetzt auch angefangen.

Der macht auch viel Dinge macht.

Ja, ja.

Der macht vor allen Dingen viel mit Lean, also sozusagen eine Programmiersprache, mit der kann man, also schreibt man halt nicht Code, sondern quasi Mathe und.

Man schreibt schon Code, aber hinterher sagt er einem dann das.

Genau, kann der Compiler, der Kompiler hat ja nicht so ein Binary, sondern der gibt einem Zertifikat, dass das, was man halt hingeschrieben hat, folgerichtig war.

Und wenn man das ein Beweis war, dann ist es halt dann bewiesen.

Genau, und das macht es halt auch zugänglicher, das macht es halt auch möglich, dass mehrere Leute miteinander irgendwie kollaborieren, weil das Problem an der bisherigen Mattenotation, auch die ist natürlich ein Riesenfortschritt gegenüber früher.

Aber die ist halt so, wenn man jetzt so ein aktuelles Mathe-Paper nimmt und schlagt Seite 15 auf, dann kann einem niemand sagen, was da steht, ohne die Seiten 15 Seiten vorher gelesen zu haben.

Und das ist super anstrengend.

Und deswegen macht das keiner und dann kann man nicht so gut zusammenarbeiten, sondern muss sie da für sich das irgendwie, und das limitiert natürlich die Menge an Dingen, die man irgendwie tun kann.

Und jetzt können halt auch irgendwie Nicht-Profis quasi da Pull-Requests gegen lange Beweise stellen und kann halt automatisch checken, ob das halt so häufig stimmt, was sie geschrieben haben oder nicht.

Und dann, genau.

Das machen sie auch schon.

Die haben da ein total cooles Projekt, wo es darum geht, quasi nicht neue Sachen zu beweisen oder so, sondern die gesamte mathematische Theorie, die es so gibt und alle Lemmas, die man halt so hat, die alle mal formal mit Lean durchzubeweisen.

Und das dann halt in der Datenbank zu haben, sodass man halt später sagen kann, okay.

Im Endeffekt halt Mathematik, oder?

Also halt die das, was es gibt, so an Mathematik einmal.

Einmal komplett durchformalisiert zu haben und dass man es halt auch noch suchen kann, dass man immer sagen kann, okay, ich habe jetzt dieses Problem, welche Lemmas könnten wir denn da helfen?

Oder welche Tricks siehst du denn in den Dingen, die alle bewiesen sind, die man jetzt verwenden könnte, und dann kann einem auch ein LLM da vielleicht helfen.

Ja.

Also fand ich auf jeden Fall ein.

Ja, gewusst wie, aber man muss eigentlich on top von den Dingen stehen oder nicht nach neuer Information suchen, sondern nach was, was man selber quasi auch schon rausputzen könnte und das geht dann halt schneller.

So ein bisschen anders, glaube ich, als wenn man sich davon erstmal die Wettechline lässt.

Achso, it's different.

Ja, aber es ist auf jeden Fall, Mathematik ändert sich auch noch immer und mehr Leute können an Dingen.

Die hatten dann jetzt auch so ein Paper dazu und da waren halt dann 50 Autoren drauf oder so.

Wo ist ein Paper?

Das gab es ja, es gibt es ja sonst so in der Physik mit 1000 Autoren und in der Mathematik eigentlich nicht.

Ja, ist spannend.

Kennt ihr das Chicken Paper?

Hätten wir gerade so ein, wo gerade Paper nehmen.

Was ist das?

Chicken, Chicken, Chicken, Chicken, Duckzonker.

Also es gab jemanden, der hat es tatsächlich geschafft, ein Paper zu veröffentlichen, weil das alle Standards erfüllt, formalen Standards.

Ach so, okay.

Habe ich am Montag gehört, danke, Sascha.

Ja, jedenfalls, genau.

In dem Podcast habe ich auch, also ich bin ja auch so ein.

Das ist ein offiziell peer-reviewtes Paper.

Da kommen ziemlich viele Hühner drin vor.

Ja, genau.

Eigentlich nur Hühner.

Ja, alles tricken.

Ja, ja.

Ist auf jeden Fall eine sehr spitze Zielgruppe.

Genau, also was der, also ich würde ja sagen, also bisher war ich immer in dem, es gibt ja im Grunde zwei Lager, was Theorie der Mathematik angeht.

Es gibt halt so die Platoniker irgendwie, also das ist eine der wenigen Gebiete, wo halt, wo halt Platonismus irgendwie noch eine Rolle spielt.

Und die Intuitionisten oder so.

Und ich würde sagen, naja, gut, ich bin schon irgendwie da eher auf der Platon-Seite, weil, naja, wie soll das anders gehen?

Man kann ja auch quasi zum Beispiel experimentelle Mathematik machen, wo man einfach irgendwie zufällig Beweise generiert und dann überprüft mit einem Ding, das halt nicht alles beweisen, nicht alle checken kann, aber checkt, ob da irgendwas Interessantes, ob das wahr ist erstmal, ob das richtig ist und dann, ob irgendwas Interessantes rausgekommen ist.

Und dann manchmal fällt da irgendwas Interessantes bei raus.

Und dann, wie kann man das über so einen Prozess erfunden haben, sondern das muss man halt eher entdeckt haben.

Und auch so andere Dinge wie, weiß ich nicht, dass es Kreise gibt oder Dreiecke oder so, da hat man so intuitiv das Gefühl, naja, die gibt es schon irgendwie da draußen und die kann man eher entdecken, dass das halt 180 Grad sind in der Winkelsumme und das kann man nicht erfinden.

Oder das ist halt einfach so.

Und deswegen dachte ich immer so, ja, also quasi so Plato, äh, mathematischer Platonismus ist eigentlich schon so die richtige Geschichte und dann, genau, Intuitionisten seit Anfang des 20.

Jahrhunderts sagen so, nee, nee, das kann man aber vielleicht alles nicht so machen und das ist doch eher vielleicht eine Erfindung, das habe ich eher so für Quatsch gehalten.

Und der hatte jetzt aber ein super Argument für den mathematischen Intuitionismus und zwar, wie waren das noch?

Jetzt muss ich es auch richtig zusammenkriegen.

Jetzt muss ich

es zusammenkriegen, verdammt.

Mathematik immer besonders einfach.

Genau, achso, ja, richtig.

Das ging ungefähr so.

Der sagte halt, naja, also es gibt ja so Zahlen wie Pi.

Wir hatten es, glaube ich, auch in meinem Podcast schon mal irgendwann davor, als wir über Pi geredet haben.

Naja, das ist halt völlig unklar, zum Beispiel, also es sieht, Pi, die Dezimalbruchentwicklung Pi besteht jeden Test für Zufälligkeit.

Und ja, aber niemand weiß, ob es wirklich zufällig ist oder nicht, oder ob dich doch irgendeine Conspiracy da drin Verschwörung ist, die halt doch nicht zufällig sein lässt oder so, das weiß halt keiner und man hat auch keine Idee, wie man das rauskriegen kann.

Aber er sagt, naja, eigentlich ist es ja ganz einfach.

Also natürlich, wahrscheinlich, was man erwarten würde, ist, dass es zufällig ist, weil man kann relativ einfach beweisen, dass quasi die allermeisten reellen Zahlen zufällig sein müssen, sonst wäre einfach nicht genug Platz.

Wenn da irgendwelche Muster wären, dann könnte man das irgendwie diagonalisieren oder so.

Das darf nicht gehen.

Die allermeisten müssen zufällig sein.

Das ist was ganz Schlimmes, das ist ein ganz schlimmes Argument, Jochen, weil jetzt kommst du auf einen ganz schlimmen Punkt in der Mathematik.

Die allermeisten reellen Zahlen können wir nicht erfassen.

Die können wir nicht sehen.

Die können wir, die sind, das sind so völlig doof.

Das sind so völlig doofe Zahlen wie Pi.

Und das sind die allermeisten und wir kennen vielleicht drei davon.

Ja, ja.

Aber es sind die allermeisten.

Und das finde ich sehr unangenehm.

Genau.

Und Vorstellung.

Da gibt es ja dann dieses Bild von den, das hat ja bestimmt auch schon jeder mal gehört, von den Infinite-Monkeys, ja, so natürlich viele Aften, wenn die nur lange genug irgendwie auf ihre Schreibmaschinen eindreschen, dann kommt dabei auch mal Shakespeare raus oder so.

Jede von diesen Zahlen muss alle Werke von Shakespeare in der richtigen Reihenfolge und so enthalten.

Urheberrechtlich geschützt.

Wenn die echt zufällig sind, das kann nicht anders sein, das muss so sein.

Und jetzt ist halt natürlich die Frage so, okay, also wenn jede vonzel von diesen blöden Zahlen im Grunde das ganze Universum irgendwie enthält, weil, naja, also egal wie man das Universum beschreibt, diese Beschreibung muss da auch drin vorkommen irgendwo.

Wie kann das denn sein, dass das schon vorher existiert da draußen und wir es nur entdecken?

Oder ist es dann nicht so, dass man, ja, wenn man das jetzt erzeugen wollte, zum Beispiel über Kind offen.

Ja, gut, aber das geht ja weg, Jochen.

Da musst du nur sagen, das Universum ist quantifiziert und schon existieren diese Zahlen nicht mehr.

Ja, aber das, weil gut, okay, Universum ist sehr weit gefasst, jetzt nicht als physikalisches Universum, sondern mathematisches Universum eingeschlossen, wo alle mathematischen Objekte auch drin sind, inklusive Pi und so.

Und wenn man als Katholiker würde sagen, es existiert.

Zirkulär ist.

Ja, du sagst, es existiert, weil wir annehmen, dass das Universum, in dem die drin, dass das Universum, in dem wir drin sind, das Universum ist, in dem die existieren.

Nee, nee, ich würde sagen, also es gibt, ich meine jetzt nicht das physikalische Universum, sondern ganz weit gefasst, also auch die Welt, in der halt auch mathematische Objekte existieren, da ist halt alle, also als Platoniker würde ich davon ausgehen, eben sowas wie Pi, das existiert da draußen halt nicht in unserem Universum natürlich, im physikalischen Sinne, sondern quasi als Konzept, als Idee.

In einem anderen Universum, wenn es ein anderes gibt, müssen sie auch auf diese Idee kommen, weil diese Idee existiert halt unabhängig davon.

Und ich kann auch nicht getäuscht sein, dass es über meine Sinn oder so.

Ich finde, da gibt es eine Grenze, Jochen.

Ich verstehe, worauf du raus willst, dass das sozusagen was Universelles ist.

Egal welches Universum dir vorstellst, die Kreiskonstante ist immer.

Überall gibt es sowas wie Gravitation.

Brauchst du nicht mal.

Du brauchst nicht mal die Gravitation, du brauchst nur Mathematik.

In jedem Universum, das Mathematik enthält, gibt es die Kreiskonstante und die ist immer gleich.

Ist aber Mathematik keine Gravitation?

Geometrie immer gleich.

Nee, brauchst du nicht.

Nee, das hat nichts mit Physik zu tun.

Aber es gibt eine Grenze.

Jochen, ich glaube, dass es da eine Grenze gibt.

Weil es gibt Dinge, die sind ganz offensichtlich von Menschen ausgedacht.

Ja, klar.

In der Mathematik.

Die gibt es nur, weil wir.

Gravitation braucht nicht, da kannst du einfach fliegen gehen.

Und die Frage ist, wo ist die Grenze?

Wo sind die Sachen von Gott gegeben, wie man so sagt?

Dieses Zitat.

Die natürlichen Zahlen sind von Gott gegeben, alles

ist ausgedacht.

Menschenwerke, ja.

Aber da gibt es eine Grenze.

Sind die komplexen Zahlen nicht schon ausgedacht?

Die haben ja schon eine Entsprechung in anderen Dingen drin und die findest du überall in der Physik und so weiter.

Aber dann gehst du weiter, sind, keine Ahnung, ist die Monstergruppe ausgedacht, oder nicht?

Ja, ja, oder die Bivo.

Wobei die Monstergruppe ein schlechtes Beispiel ist.

Jetzt musst du gerade erkennen, was denn die Monstergruppe ist, also wenn du nicht uns drei meinst.

Es gibt so eine Klassifizierung von Gruppen und in vielen Bereichen der Mathematik ist es so, dass du fünf sehr schöne Beispiele findest.

Da gibt es die ganz genau die natürlichen Zahlen und die ganzen Zahlen und dann, die kannst du so erweitern und da gibt es irgendwie fünf verschiedene Kategorien und dann gibt es noch drei zusätzliche, die einzeln sind und die eine hat fünf Elemente und die andere hat sieben Elemente und dann gibt es noch die Monstergruppe, die hat 880.973 verschiedene Elemente.

Irgendwie so komische Zahlen.

Und weil die da so rausfällt aus dieser schönen Klassifizierung, hast deinen schönen Setzkasten mit den ganzen ordentlichen Gruppen drin und dann hast du drei so komische dazwischen und dann hast du da noch die riesige Monstergruppe daneben.

Hat die den Namen Monstergruppe.

Okay.

Die ist ein schlechtes Beispiel, weil die fällt halt aus diesen Klassifizierungen raus.

Aber ganz viele von diesen Dingen sind, finde ich, sind schon eindeutig ausgedacht.

Die sind so, weil wir die Definitionen so gewählt haben.

Und daraus fallen die Sachen raus.

Aber ja, das ist eine schwierige Frage.

Ja, aber ich will auch eben, wenn man sagt, okay, ich meine, man kommt ja an, selbst wenn die existizieren, man kommt ja an die Dinger nicht ran, wenn man es jetzt ausrechnet, dann fallen da zwar diese langen Zahlen raus, aber dann braucht man Energie und Energie hat man aber nicht unendlich viel.

Das heißt, also Shakespeares Werke daraus zu kriegen, wird schwierig, da braucht man irgendwie nahezu unendlich viel Energie.

Das heißt, man könnte ja sagen, okay, vielleicht existieren die.

In unserem physikalischen Universum.

Ja, ja, genau.

Ja, aber ich finde das halt schon irgendwie, damit könnte man schon was sagen, weil wenn ich da wahnsinnig viel Energie investieren muss, um da was, kann ich zwar beliebige Sachen daraus kriegen, aber dann wird es halt dann doch wieder eher so.

Also wenn ich das sozusagen in unsere Existenz holen will, dann muss ich halt irgendwie.

Dann plötzlich unterliege ich wieder all diesen Beschränkungen und dann ist es doch wieder mehr erfunden, weil ja was.

Zeit vielleicht?

Kann sein, dass es gibt, aber ich komme halt nicht dran.

Aber wenn das mit Zeit könnte es ja vielleicht gehen, weil in der Zeit könntest du noch eine andere Dimensionen versteckt haben, die dann nicht nur lineare.

Aber das bringt nichts.

Die kannst du ja nicht unendlich.

Stimmt's ja?

Ich würde ja sagen, das ist im Grunde das gleiche.

Ob du jetzt Zeit oder Energie, das kannst du ja gegeneinander aufrechnen.

Da gibt es vielleicht eine Abkürzung, so eine Meta-Abkürzung.

Ja, keine Ahnung.

Ich glaube, da müssen wir mal eine Separation.

Müssen wir mal separat.

Müssen wir vielleicht auch irgendjemanden fragen, der da mal.

Keine Ahnung, das waren so meine Gedanken beim Hören vom Podcast.

Vielleicht finden wir ja einen Mathematiker, der.

Was weiß.

Ja, das ist auch vielleicht eher in der Mathematik.

Ja, nee, aber solche Diskussionen sind in der Mathematik schon, die kommt immer wieder, gerade in den früheren Semestern.

Sobald man mal ins, sobald man ins Grundstudium abgeschlossen hat, dann hat man es akzeptiert.

Das ist die Mathematik, die gibt es halt.

Und da gibt es auch nicht alles.

Ich hatte mal eine sehr lange Diskussion mit einem, der einem Studenten von mir, den ich tutoriert habe, der offensichtlich auch schon einen Hang zu Esoterik hatte und der dann gesagt hat, ja, aber du musst alles untersuchen.

Warum untersuchst du das hier nicht?

Und dann habe ich ihm bewiesen, ja, wenn ich das untersuche oder wenn ich diese Annahme treffe, dann führt das zu Paradoxa.

Dann falle ich direkt raus, brauche ich gar nicht weitermachen.

Das hat er aber nicht akzeptiert, sondern er wollte mir dann versuchen zu erklären, dass das aber eine Sinneserfahrung ist und du musst alle Sinneserfahrungen versuchen, als Wissenschaftler musst du alles akzeptieren.

Das ist aber nicht so, sondern als Mathematiker geht man da pragmatischer vor und sagt, ja, aber da brauche ich nicht weitermachen, weil das bringt mir nichts.

Du willst ja eigentlich nur Statistiker, du hast ja nur eine Approximation gemacht von dem, was du glaubst, was dabei rauskommt und dann doch dich auf deine eigene Sinneserfahrung verlassen, die irgendwie da so ein bisschen in die Glocke in die Mitte.

Mathematik und Sinneserfahrung.

Ja, das

hat keine riesige Überschneidungsmenge.

Das ist ja genau der Versuch, quasi von den Sinneserfahrungen zu abstrahieren.

Aber ja, was natürlich schwierig ist.

Ja, sagen wir mal zu den tatsächlich praktischen Dingen.

Ich habe auch ein News-Ding, weil.

Eins hat er noch.

Ja, genau.

Weil das können wir vielleicht, jetzt können wir das sagen.

Jetzt haben wir die ganzen Leute vergrault irgendwie mitherren.

Trauern wir das jetzt auch noch zu.

Aber wolltest du nicht irgendwas sagen, dass ein Learnings vom Barcamp, was man nicht machen sollte?

Achso.

Wir machen es aber gnadenlos egal.

Und zwar, wir machen gleich noch was über MCP.

Oder ich kann dazu was erzählen?

Nein.

Machen wir nicht?

Nein.

Wir machen eine eigene Folge zu

MCP Programm.

Machen wir eine eigene Folge zur MCP?

Ja.

Okay.

Ich finde ja, MCP ist das Master Control Programm.

Genau, das fand ich auch.

Ich habe da Vortragsfrage.

Oder Metoklopramid, je nachdem, wie man möchte.

Na gut, dann machen wir das heute eben nicht, aber das müssen wir echt dann bald machen, weil sonst weiß ich das alles nicht mehr.

Ich weiß, das ist gerade.

Na dem Jochen unter den Nägeln.

Ja, Mathematical Compute.

Liebe Hörer, schreibt uns an hello at python-podcast.de, ob ihr diese Folge dringend hören wollt oder nicht.

Ja, MCP-Folge.

Meinst du, jetzt hört doch jemand zu?

Ja, aber das News-Item wäre an der Stelle, irgendwie hier ex-CTO von OpenAI hat irgendwie von einem Venture Capital Fonds irgendwie zwei Milliarden gekriegt, ohne irgendwas.

Bei einer Validierung von 10 Milliarden oder so.

Also der ursprüngliche Entwickler von ChatGPT ist halt auch dabei.

John Schulmann und ein paar andere Größen.

Also, ich meine, die ganzen ursprünglichen Leute sind ja alle nicht mehr bei OpenAI.

Und naja, also das ist halt völlig irre.

Die haben kein Produkt und nichts und kriegen halt so viel Geld, das ist echt Wahnsinn.

Aber wenn man sich für MCP interessiert, der aktuell beste Podcast, den man hören kann, eine Podcast-Episode, ist tatsächlich irgendwie von einem Partner von diesem Venture Capital Fonds, von einer Partnerin mit Interview mit David Soria Para oder ich weiß gar nicht, wie man es ausspricht, der einer der beiden ist, die sich das ausgedacht haben und das ist irgendwie echt ganz nett.

Ja, also, aber dieser ganze Bereich ist momentan völlig irre.

Das erinnert mich echt sehr stark an diese ganze Dotcam-Bubble Ende der 90er und es ist irre, ja.

Naja.

Genau.

Aber dann machen wir das nochmal in einer anderen Episode.

Ja, dann an der Stelle ist jetzt endgültig Zeit für.

Dann machen wir jetzt was haben wir jetzt?

Unfuck it.

Aber ein radikaler Wechsel.

Achtung, jetzt kommt ein radikaler Bruch.

Data Class Builders.

Ah, okay.

Ja, weil bei Unfuckett.air sind, das wollte ich noch einmal kurz erwähnt haben.

Da hat der Johannes eben geschickt.

Das war schön.

Link in den Shownotes.

Genau, für Business Leaders oder for Senior Developers.

Wichtig ist.

Ja, Kapitel 5.

Ist ein etwas kürzeres Kapitel und ich fand es sehr gemischt beim Lesen.

Ich fand, es ist so ein bisschen, es mäandert so ein bisschen und bringt dann so ein paar Themen einfach noch so mit rein.

Sollen wir erst über das Ende reden, warum das ein Codesmail ist oder warum das keiner ist?

Ja, ich stimme dem überhaupt gar nicht zu.

Was ist denn das Argument?

Warum sollte das denn ein Kurzmail sein?

Du findest, das ist ein Codesmail.

Das habe ich nicht gesagt.

Also vielleicht geht es erstmal in ein Kapitel geht.

Es geht darum, wie man Datenobjekte einfach, welche instanziert es vielleicht falsch.

Dekariert es mit Data-Class.

Es ist eine Klasse, die nur Daten hält und keine Funktionen hat.

Wie so ein Namedtuple.

Ja, zum Beispiel.

Das ist eine, also gleich auf der ersten Seite sind drei Mechanismen genannt.

Oder auch wie ein Flydochen ist.

NamedTupel.

Nee, das nicht.

Kommt direkt auf der zweiten Seite, steht direkt drauf, das nicht.

Also es gibt Collections.nameduple, das ist schon lange in der Python-Schnallerbibliothek seit 2.6.

Haben sicherlich viele schon mal gesehen.

Können wir gleich noch erklären, was das ist.

Dann gibt es eine neue Variante davon.

Typing.nameduple.

Und der heißeste Scheiß ist natürlich Dataclasses.dataclass.

Ein Dekorator, der diese ganzen Sachen mitnehmen soll.

Am Ende geht es immer darum, Klassen zu machen, die nur Attribute haben.

Und im Endeffekt ist das auch alles nur so ein bisschen Zucker oben drauf gestreut, weil man könnte prinzipiell diese ganzen Sachen alle mit Dicts machen oder sogar mit Tupels, wenn man möchte.

Das heißt, das Einzige, was man gewinnt, und das Einzige ist hier in sehr großen Anführungszeichen, dieses Wort einzige, das Einzige, was man gewinnt, ist, dass das Programm besser verständlich wird.

Ruff flintet zum Beispiel vom Typing Import Name Tupole und sagt, naja, es ist Collections Name Tupole, bitte.

Sag, darfst du nicht, weil.

Ja, sagen die das, okay.

Ich bin so ein bisschen, ich bin nicht ganz hundertprozentig mal einverstanden mit den Sachen, die Ruff sagt.

Und ich habe heute auch einen Ruff Cycle gefunden.

Wo ich einen Hinweis gekriegt habe von Ruff, der gesagt hat, der Generator ist unwichtig, ist nicht wichtig, mach bitte eine Dikt-Comprehension draußen.

Dann habe ich eine Dikt Comprehension draus gemacht und habe gesagt, ah, das ist eine nütze Dick-Comprehension, mach bitte einen Dikt-Aufruf mit Generator drin draus.

Sehr amüsiert.

Wie man es macht, ist falsch.

Naja, Ruff hat ja auch so ein bisschen, ist ja schon so ein bisschen opinionated.

Also nicht alles, was da von Ruff kommt, ist ganz richtig.

Und es gibt schon einen wichtigen Unterschied zwischen Nameduple und NamedTupel, was auch in dem Kapitel erklärt wird.

Also die sind schon unterschiedlich.

Aber jetzt, wo wir wissen, was eine Data Class ist, eine Klasse, die keine Funktionen hat, sondern nur Daten halten soll, kommt direkt in der Einleitung, sagen sie, ja, das ist eigentlich nicht so gut.

Es wird in diesem Kapitel mehrmals darauf hingewiesen, dass namhafte Personen Data Classes durchaus als Code Smell sehen oder als Einstiegspunkt und als das ist noch nicht fertig ansehen.

Und das Hauptargument, so wie ich es verstehe, ist, dass wenn du eine Data Class hast, dann bedeutet das, dass du eine Klasse hast, die nur Daten enthält und keine Funktionen hat.

Und du musst ja aber trotzdem was mit den Daten machen.

Und das bedeutet, dass die eigentlich schon Funktionen hat, nur dass die irgendwo anders drinstehen.

Weil es nur ein Vehikel ist und das wäre blöd.

Weil du mit Daten halt irgendwas machen musst.

Und eigentlich bedeutet Data Class dann in dem Sinne, dass du deine Funktionen, die zu den Daten gehören sollten, irgendwo anders hinschiebst.

Und dass du die irgendwo anders hast.

Und ich stimme diesem Argument überhaupt gar nicht zu.

Das hört sich für mich sehr nach, an also ich meine, diese Namen, die mir da gesagt bekommt, Martin Fowler und Kenntback, hört sich für mich sehr nach Kingdom of the Nouns an, es hört sich für mich sehr nach Java an, es hört sich für mich sehr an nach der Code ist wichtiger als die Daten.

Und das stimmt halt in ganz vielen Fällen nicht.

In ganz vielen Fällen sind die Daten viel wichtiger als der Code.

Was du da drin hast, welche Fälle du hast, wie du drankommst, ist in ganz vielen Anwendungsfällen, zumindest in denen, die mir so begegnen, viel wichtiger, als dann, dass die Funktion direkt dabei steht und dass du die direkt dazu packst.

Das ist der eine Aspekt.

Du gibst der Funktionalität mehr Gewicht als den Daten.

Und das ist oft nicht der Fall.

Mir fällt das Zitat jetzt nicht ein, aber da gibt es eines von Linus Torvalds, wo er sagt, naja, so das ist halt quasi oft ein Fehler von Leuten, die quasi das Licht noch nicht so richtig gesehen haben, dass sie halt Wert auf Algorithmen oder sozusagen auf Dinge legen.

Und wenn man dann mal irgendwann später da so weiß, was man tut, dann guckt man sich eher so die Datenstrukturen an und wie die eigentlich aussehen sollen.

Und dann ist das mit der Funktionalität, ist dann ganz klar und einfach, hoffentlich.

Und ja.

Aber ich würde auch denken, dass, genau, also für mich, mich erinnert das auch total an irgendwie objektorientierte Programmierung Ende der 90er, ist halt irgendwie das Heilmittel für alles.

Aber inzwischen würde man ja sagen, so, naja, das aktuelle Heilmittel für alles ist halt Domain-Driven Design.

Und aus der Perspektive ist es halt, gibt es halt zwei unterschiedliche Arten von Dingen, für die man halt Klassen hat.

Und das ist halt, eine sind halt Entities, also Dinge, die halt irgendwie eine Identität haben, die halt wichtig ist.

Und das andere sind halt so Value-Objects und bei denen ist es halt wurscht.

Also sowas wie zum Beispiel ein Objekt, das halt einen Geldbetrag repräsentiert.

Und das Wichtige ist halt der Wert von dem Geld und aber nicht, welchen Geldschein man hat, das ist völlig egal.

Und für solche Value-Objects sind halt Data Classes halt auch total super, weil wenn das halt State hat und dann braucht man halt natürlich vielleicht schon Methoden und so.

Also ich würde auch denken, also das ist differenzierter, ja.

Es gibt noch einen zweiten Aspekt, der mir da fehlt in dieser Argumentation.

Dann geht es ein bisschen in das, was du eben gesagt hast, die Leute, die das ich noch nicht gesehen have.

Wenn man über Klassen nachdenkt und die sieht als Anzahl von Funktionen anders, then is this another Blick auf das, what man does.

It is another Blick auf the programming and what a program can.

And zwar ist es ein Blick auf einzelne Objekte.

Then it's object, was irgendwie hervorgehoben ist.

This is name das Objekt, an dem ich gerade dran bin, in dem ich gerade drin bin.

When I aber den Blick habe auf eine Data Class, dann geht es mir oft gar nicht so sehr um eine einzelne Instanz oder ein einzelnes Attribut von dieser Data Class.

Sondern verändert sich mein Denken hin zu, was ist denn, wenn ich tausend davon in der Hand habe?

Was ist denn, wenn ich eine Tabelle von diesen Objekten in der Hand habe?

Und dann ist auf einmal gar nicht mehr das Einzelobjekt wichtig, sondern dann ist auf einmal die Gesamtheit der Objekte wichtig.

Was ist denn, wenn ich eine Million von diesen Geldbeträgen bekomme?

Was kann ich denn dann damit machen?

Und diese Art zu denken oder auch diese Art zu modellieren, ist in der klassischen OOP nicht naheliegend.

Weil im klassischen OOP denkt man eben oft über einzelne Objekte nach, weil du eben eine Klasse schreibst, die eine Instanz hat.

Und für diese eine Instanz hast du diese Funktion dran.

Und wenn du die Funktion auf der einen Instanz aufrufst, dann hast du diesen Blick auf die eine Instanz.

Und das ist was, was, das ist schwer zu greifen und schwer zu erklären, aber das verändert das Denken über Programmstrukturen und das verändert das Denken über die Inhalte von einem Programm.

Und das ist was ganz Gefährliches zu sagen, meiner Meinung nach, dass das ein Codesmail ist, weil du nur diesen einen Blick auf Programmierung haben darfst.

Deshalb, ich bin da sehr skeptisch, wenn Leute sagen, Data Classes, ja, es ist schon okay, aber hier, das fängt direkt an, Data Classes are like children, they are okay as a starting point, but to participate as a grown-up object, they need to take some responsibility.

Das heißt, die grob übersetzt Datenklassen sind wie Kinder, das ist okay, wenn man damit anfängt, aber wenn man sie wie richtige Objekte verwenden will, dann müssen sie schon auch Funktionalität haben.

Sehe ich gar nicht so und finde ich tatsächlich nicht gut, diesen Blick so zu haben.

Aber vielleicht meint das so ein bisschen was wie, ich weiß nicht, dann zu Paydantik überzugehen, was ja fast sowas ist wie eine Data-Klasse.

Mit so was wie Validierung dran dann noch oder so.

Ja, aber auch das ist noch, Paydantik sind natürlich, ja, sind schon Data Classes auch, oder?

Ja, ich würde, das sind halt, da gibt es dann eben, genau, das ist ein bisschen, das kommt jetzt in dem Buch nicht so vor, weil das halt auch teilweise aktuellere, also das Buch ist ja relativ aktuell, aber gerade so der auf, da sozusagen das Standardlip, ne?

Pydentic, ja, genau, beschränkt sich mehr so auf die Standardlip, aber wobei ja auch das Vorbild von Data Classes in der Standard-Lib ist, Atlas ist halt auch nicht, ja, Hunex sollten wir vielleicht

mal bitte an.

Genau, ist ja auch nicht.

Genau, aber sozusagen Pydentic ist ja danach erst so richtig populär geworden, würde ich sagen.

Oder jetzt auch noch neuer Message-Spec, gibt es ja auch schneller und keine Ahnung.

Aber da muss man vorsichtig sein.

Also ich glaube, da vermischt man dann, also Pydentic, es ist natürlich auch praktisch, aber es vermischt halt zwei so Sachen.

Es ist einmal diese Klassen-Bildergeschichte mit den Annotationen, damit man halt sozusagen das halt kompakt hinschreiben kann, was man da für Attribute dran hat.

Das ist bei Pydentic ja genauso.

Und dann gibt es halt diesen Validierungsteil, der ist aber irgendwie anders, weil das hast du halt in Data Classes und halt bei Nametuple oder so eigentlich nicht.

Mal bei typing.nametuple hast du Validierung.

Nee, gar nicht, genau.

Und da muss man halt extrem vorsichtig sein.

Also ja, ich meine, es kann natürlich auch sehr praktisch sein, aber es gibt da auch eben von dem Entwickler von Atus einen sehr schönen Vortrag von der letzten PyCon US, wo jetzt auch die Vorträge rausgekommen sind.

Und der heißt, glaube ich, Design Pressure.

Und das ist eigentlich nicht.

Der Enqueter heißt Design Pressure.

Nee, der Vortrag heißt Design Pressure.

Aber ist das nicht Hinek Schlawak?

Genau.

Der ist doch auch Deutscher, oder?

Ja, ja, genau.

Den sollte man auch echt mal fragen, weil der hat immer tolle Artikel zu diesen ganzen.

Der hat tolle Software geschrieben, tolle Artikel geschrieben, macht tolle YouTube-Videos, toller Typ.

Müssen wir mal fragen.

Wenn du in dieser

Episode zeige ich vorher, ob er diesen tollen Podcast kommen möchte.

Genau.

Vielleicht wäre er auch toll, dann so ein bisschen glanz könnte er auf unseren Fall.

Wer weiß.

Mal schauen.

Ja, genau.

Und ja, eigentlich ist das ein Vortrag über Software-Architektur.

Der hat ja auch Reviewer für hier das Architekturbuch, was ich immer empfehle, also das Software Architecture with Python.

Und er hat auch schon häufiger Vorträge über Software-Architektur gehalten.

Und das ist auch wieder so einer.

Und der startet mit dem Hot Take, irgendwie so Dinge wie Pydentic oder irgendwie diese Geschichten-Data-Validation-Dinger, das macht eure Architektur von eurem Programm kaputt.

Ihr Trottel.

So, und jetzt zeige ich euch mal, warum das so ist.

So, gut, man braucht halt irgendwie so ein, meinte so, ja, das macht man in New York, ich komme ja aus der YouTube-Welt, dann macht man das so, dass man so einen Hook platzieren muss oder muss man drauf delivern oder believe what happens next.

Genau, genau.

Und wenn man das halt schafft, dann ist es gut.

Und wenn man es nicht schafft, ist halt doof.

Aber mal schauen, genau.

Und ja, also da, und ich, aber ich würde sagen, im Grunde hat er da ganz recht, ja.

Also ich meine, wenn man jetzt das so macht, dass man halt Pydentik-Modelle verwendet, halt als Data Classes Ersatz und die dann halt quasi benutzt, um die eigene Domain, ich weiß ja gar nicht, ob es da für irgendeinen guten deutschen Begriff gibt oder so, dass also der Bereich, in dem die eigene Business-Logik stattfindet, zu beschreiben, dann hat man halt schon einen bösen Fehler gemacht eigentlich.

Oder dann hat man sich in der Ecke monövriert, aus dem man schlecht wieder rauskommt.

Ja, und da muss man aufpassen.

Also ich meine, man kann das ja auch richtig verwenden, aber es ist halt nicht so einfach.

Also das ist halt schon gefährlich.

Also insofern bei Paydantik, also ist es auch ein sehr cooles Projekt, aber man muss halt echt aufpassen, dass man da nicht, dass also das, also wenn man damit auf irgendein Problem zielt, dann hat der Pydentic-Lauf auch immer so die Tendenz, so weich zu werden und so auf den eigenen Fuß runter sich zu neigen und bei deinem falschen Moment schießt, dann hat man noch einen Fuß.

Kannst du nochmal kurz vergleichen oder erklären, was du meinst, wann das passiert?

Naja, also wenn du zum Beispiel von anstelle einer Data Class halt ein Pydentic-Modell verwendest.

Warum ist das blöd?

Naja, weil du dann zum Beispiel Pylentic importierst in deiner Wissenslogik.

Und dann bist du davon abhängig.

Ja, und genau, du hast halt dann diese Concerns irgendwie miteinander vermischt und dann kriegst du alle möglichen Arten von üblen Designproblemen, Architekturproblemen.

Genau.

Welche?

Naja, also zum Beispiel, wenn das dann halt jetzt nicht schnell genug ist und du willst jetzt was anderes, eine schnellere Art, irgendwie die Sachen zu, weil du hast das jetzt gekoppelt an, du speifst das als JSON raus und liest JSON rein und so, was ja Pydentic auch ganz gut kann.

Und jetzt stellst du halt fest, so, oh, jetzt, oder gibst das über eine API raus und jetzt stellst du halt fest, so, oh shit.

Aber, also ich meine, das ist relativ schnell, aber das ist nicht so schnell, wie es geht.

Also es geht natürlich, es gibt da Dinge draußen, die sind deutlich schneller als Pydentic.

Und jetzt stellst du halt fest, so, okay, irgendwie Pythonic ist zu langsam für mich.

Du wirst Pydentic niemals austauschen können, da kannst du ja ein Ding neu schreiben.

Das ist halt, äh, kannst du einfach völlig vergessen.

Und ja, das ist halt, wenn man, wenn man das halt quasi nicht so nicht so gebaut hat, dass man halt Pydentic austauschen kann, dann hat man halt.

So ähnlich wie bei man halt von den Django, wenn man Models Model erbt, ne, also oft kann das ja auch okay sein und bei Pythonic kann das ja auch oft okay sein, aber wenn du halt ein Großprojekt hast und dann hast du halt irgendwann, willst du Dinge anders machen, dann kann es gut sein, dass das nicht mehr geht.

Ja, knie.

Ja, ja, okay, klar, natürlich.

Ja.

Ich fand das jetzt nicht so, dass Killer Gegner win.

Sollen wir mal zurückkommen zum Buch?

Ich glaube, da sind tatsächlich noch ein paar interessante Sachen drin.

Diese, es werden ja hier drei Alternativen genannt.

Also Collections.name, Tuple, Typing Name, Tuple und Data Class.

Warum nicht TypeDict?

Ja, das ist tatsächlich hier, da lese ich, ich zitiere, Typedikt may seem like another Data Class Builder.

Ja, ist es nicht.

Aber Typedikt does not build concrete classes that you can instantiate.

Genau, es ist ein Klassen.

Das macht keine 25 oder sowas, geht ja nochmal drauf ein.

Genau, also das macht nicht solche Klassen, wie wir sie hier brauchen, sondern das ist nur.

Type-Annotations für Dickt, aber es funktioniert anders.

Genau, und es ist eine böse Falle.

Also ich habe weiß nicht, wie oft ich das schon gesehen habe, dass Leute denken, dass sie dann sicher werden und aber nie MyPayer oder sowas ausführen.

Und dann, wenn man es nochmal ausführt, kriegt man halt gesagt, so ja, also das, was du da machst mit dem Type-Dick, das ist uns alles falsch.

Hat nie einer gemerkt.

Hat dir das Klaot erzählt?

Nee, das begegnet sowas ständig.

Hat sich jemand ausgedacht.

Okay.

Aber im Endeffekt funktionieren doch diese drei, diese drei Verfahren alle irgendwie gleich.

Du musst irgendwie eine Definition schreiben und du sagst, ich möchte jetzt eine Klasse haben, die soll einen Namen haben und die soll folgende Attribute haben.

Und die werden dann getypt und getyped-hintet.

Ja, entweder getyped oder auch nicht getypt.

Musst du ja nicht unbedingt getyped haben.

Und selbst wenn du es getypt hast, kannst du sie immer noch anders verwenden.

Kannst du immer noch.

Selbst wenn du deine Data-Class schön mit Types versehen hast, kannst du ja immer noch reintun, was du möchtest.

Also ein Tupel wäre jetzt immutable, dann muss ich einen Frozen machen bei der Data-Class, ne?

Ja.

Genau, aber das hat mit auch das hat mit den Types nichts zu tun.

Du kannst auch, also auch das Typing.name-Tupe kann ja andere Sachen nehmen.

Das ist ja erstmal nur eine Absichtserklärung.

Ich beabsichtige, dass dieses Attribut nur ein Int sein kann, aber da hält ich niemand davon ab.

Du kannst auch eine Liste reinmachen, wenn es nicht.

Das ist ja generell bei Python so.

Okay, aber ich finde es interessant, weil im Wesentlichen gibt es da zwei verschiedene Syntaxmöglichkeiten.

Und die eine, das ist die, die von Nametuple kommt, wo man halt sagt, ich möchte ein Nametuple haben und dann rufe ich die Funktion oder rufe ich den Konstruktor Nametuple als Konstruktor auf und sage eben, diese Datenklasse soll den Namen, hier haben sie das Beispiel Coordinate haben, also Koordinate haben und die hat zwei Attribute, Lat und Lon.

Und dann kriege ich da eine Klasse raus.

Oder besser gesagt, ich kriege einen Konstruktor raus für eine Klasse.

Ich kriege ja nicht meine ganze Klasse raus, sondern ich kriege nur den Konstruktor raus.

Und das ist so ein bisschen irgendwie so eine textuelle Beschreibung.

Und ich habe da immer so ein bisschen Hemmung.

Das fühlt sich so ein bisschen an, als ob man irgendwie um diesen, ja, um so Python außen rum geht und um den um den Interpreter außenrum geht und dass man irgendwelche langsamen magischen Sachen macht.

Aber ich glaube tatsächlich, man muss da weg davon.

Man muss sagen, okay, dieses Herstellen der Klasse, das ist langsam, aber das ist, das ist ja egal, weil das macht man nur einmal.

Das Instanziieren, das ist dann so schnell wie ein Tupel.

Und das ist nicht, und die verbrauchen auch nicht mehr Speicher.

Also diese Namen werden nicht bei jedem bei jeder Instanz dazu gespeichert.

Ist nicht wie bei einem Dictionary, sondern es ist eben ein Tupel.

Und im Endeffekt ist es ein Tupel mit so einem kleines bisschen Karamellsoße oben drauf gestreut, wo man eben nicht Index 0, Index 1 und Index 2 hat, sondern wo man eben eben Latitude und Longitude sagen kann.

Und das bedeutet dann Index 0 und Index 1.

Ja, das sieht

viel schöner aus, tatsächlich.

Also, also lange Zeit war Nametuple auch irgendwie deutlich schneller.

Also wobei nichts ist so schnell wie tatsächlich einfach quasi, wenn man eine Klasse instanziiert.

Aber Nametuple war dann halt die schnellste Alternative.

Und wenn man jetzt früher war das halt oft so, oder ist auch halt.

Wenn man halt Attribut-Lookup macht, dann ist das bei Nametuple natürlich schneller.

Also irgendwas, Instance, Punkt, irgendein Attribut.

Weil Tuple ist Index, oder?

Genau, genau.

Und inzwischen macht aber Data Classes und auch, glaube ich, named Tupel, wenn man davon erbt, per Default irgendwie Slots.

Vielleicht erzähle ich jetzt auch Unsinn.

Das muss man irgendwie mal nachgucken, aber ich glaube, das ist tatsächlich so.

Das fasziniert.

Das hat gar keine praktische Auswirkung.

In keinem Fall, den ich je hatte, hätte das eine Auswirkung gehabt, dass die Konstruktion von diesen Datenobjekten zu langsam gewesen wäre.

Das heißt, das ist auch wieder so ein Jagdn-Fall.

Das ist so eine so eine Angst, die ich in meinem Kopf habe, die aber eigentlich in dem Moment noch nicht berechtigt ist.

Große API-Responses oder wo du Zeugs reinkriegst, weil da kann das schon so, weil du so halt irgendwie 10.000 Dinger in Objekte verwandelst und dann ist halt deine Objekte Zeug im Sand.

Wenn der JSON reinkommt, hast du ja eh schon verloren.

Ja, aber es gibt ja schnell JSON-Puzzer.

Aber wenn du es, du musst es dann nochmal zu Objekten machen.

Ja, du kriegst

ja auch einen Dick.

Wie auch immer, für mich der Takeaway ist, ich habe da immer so ein bisschen Hemmungen.

Ich habe immer so ein bisschen Hemmungen, so ein Name-Tool zu machen.

Weil das nicht so richtig in die Syntax passt, weil das anders aussieht, als als andere Sachen aussehen.

Aber es ist gar nicht schlecht.

Es ist gar nicht falsch, ein Name-Tupel zu machen.

Nee, aber was meinst du?

Das sieht anders aus.

Also ich finde, wenn du das jetzt in dieser vom Typing oder vom Collections importierst, dann kannst du ja Klasse schreiben.

Sieht ja fast aus wie eine Data-Class, sondern dass du nicht App Data-Klasse importierst.

Genau, das kannst du machen.

Das sieht auch normal aus.

Das ist auch was, was ich empfehlen würde.

Das kannst du machen, aber dieser Konstruktor, der Named-Tuble-Konstruktor, also das ist tatsächlich alles klein geschrieben und dann musst du da Strings reingeben.

Ja, das ist ein bisschen.

Was daran auch komisch ist, ist halt, also einmal, ich finde es auch ehrlich gesagt ein bisschen hässlich.

Ich meine, das ist uralt, ja, das gibt es schon ewig.

Das ist super praktisch.

Das ist natürlich manchmal super praktisch, wenn man halt irgendwie auf alten Interpreterversionen rumguckt, aber genau, das funktioniert wahrscheinlich bis, also da gibt es nichts mehr, was noch läuft, was irgendwie älter ist.

Das funktioniert wirklich überall.

Aber also was halt auch blöd ist, ist, dass man, dass es halt, das geht zwar auch, dass man da Methoden dranhängt, aber das ist auch voll umständlich.

Da muss man dann halt auch erstmal irgendwelche Methoden erzeugen.

Und dann muss man das Ding irgendwie da dranhängen und so.

Und es geht alles, klar, aber es ist halt schon so, wenn das als Methode dran steht, ist das schon leichter verständlich, wie das passiert.

Ja, da kann man ganz viel hässliche Magie mitmachen.

Ich glaube, wenn man so Codecost spielt oder sowas, dann ist das eine Disziplin, die man so spielen kann.

Und wenn man Leute verwirren will oder so ein bisschen obfuscation, ne?

Nee, nee, nee, das ist nicht gut.

Nee, dann gehen wir über zum Typing-Name-Tuple, weil Typing-Name-Tuple hat nämlich Klassensyntax.

Und die ist tatsächlich, ich finde die sehr schön.

Es wird gleich noch ein Problem beschrieben werden, was ich auch tatsächlich sehe, jetzt wo ich es gelesen habe.

Aber es ist so ein bisschen so, wie man es sich vorstellt.

Wenn man, wenn man aus einer anderen Sprache kommt, dann sagt man, ich möchte eine Klasse haben und die soll folgende Attribute haben.

Und das ist hier genauso, weil die Klassensyntax halt so ist, dass ich sage, Class, dann den Klassennamen, abgeleitet von Nametupe, was aber so ein bisschen nicht ganz richtig ist.

Weil die MRO da gar nicht drin ist, weil das nur in Meta-Klasse ist, weil er nämlich gar nicht tatsächlich einen Name-Tube macht.

So ein richtiges Tupe.

Genau.

Und dann innerhalb von der Klasse gebe ich einfach die Attribute an, die ich haben möchte, mit ihrem Typen.

Also hier in dem Fall beispielsweise Latitude Doppelpunkt Float und Longitude Doppelpunkt Float.

Und das bedeutet, dass diese Klasse automatisch einen Konstruktor bekommt, der eben diese zwei Attribute nimmt, entweder named oder unnamed.

Das hast du der Hauptanin.

Du möchtest jetzt nicht irgendwie eine Klasse schreiben, wo du reinschreibst, in Init, nimm folgende Argumente, Latitude und Langitude und dann machst du Self, Init, Lot, gleich, lang und da.

Genau, kannst du alles selber machen, aber es wird ja alles abgenommen, wenn du das hier machst.

Genau.

Durch Metaklassenmagie.

Und im Endeffekt.

Jetzt ist schon das zweite Mal, dass ich jetzt wieder das Trinkspiel mache, was wir letztes Mal angefangen haben, Johannes.

Ja, ich weiß.

Das ist mein Wort, was zu oft kommt.

Wir sagen es jetzt nicht nochmal.

Bei Data Classes ist ja im Grunde genommen das Gleiche.

Du sagst, welche Klassennamen du haben möchtest, welche Attribute du haben möchtest, welchen Typen du haben möchtest.

Und da ist natürlich leicht, weitere Methoden hinzuzufügen.

Die schreibst du einfach in den Klassenkörper rein.

Ja.

Das mache ich auch nicht.

Das ist ja eigentlich schon rausricht hier im Data Class.

Aber ich mache das tatsächlich relativ häufig, dass man irgendwie auffällt, so ich hätte noch gerne kein und doch das Maximum, die Summe berechnen von irgendwas.

Ja.

Das war schon super praktisch.

Ja, ja, natürlich.

Das ist auch richtig.

Also, genau.

Das ist ja

dann das, was hier der Ankel Bob würde sagen, das ist gut, bist du auf dem richtigen Weg.

Das implemented sein.

Nein.

Genau.

Es ist interessant, weil da ist ja so ein bisschen Trickery drin ja.

Hier, dieses Name-Tool, dieses Typing-Name-Tool, das ist ja gar keine normale Klasse, sondern es ist ja eine Metaklasse.

Ja.

Was ist denn jetzt so eine Meta-Klasse?

Eine Meta-Klasse.

Welches Kapitel ist das für die Folgen brauchen wir dafür noch?

Das ist weiterhin, glaube ich.

Also ein Spiel.

Dynamic Attribute and Property.

Wir verschieben das.

Da ist ein Metaproblem, das Kapitel 24.

Ja, also.

Kapitel 24, also.

Nur noch 19 weitere Episoden und schon sind.

Über das Buch Fluent Python.

Ja.

Dazwischen natürlich noch die anderen.

Okay, aber dann, äh, dieses Kapitel macht dir jetzt hier eine total interessante Biege.

Weil das nächste ist ja jetzt, ah, übrigens, wir müssen Type Hints machen.

Wir müssen noch ein bisschen über Typing sprechen.

Ja, ja, ja.

Und das fand ich interessant, als ich es gelesen habe, weil das hatte ich, das war so ein Twist, den ich nicht erwartet hatte.

Er hat deswegen darüber gesprochen, weil er gesagt hat, dass es total cool ist, wenn man jetzt Match Case benutzt.

Und das liegt darauf daran, dass das nicht so gut ist.

Ja, aber das ist dann der dritte, das ist der nächste Twist.

Achso, ja, das wurde ja gerade so eingeführt, als das Buch rauskam.

Ich glaube, deswegen ist da so die Emphasis auch so ein bisschen.

Ja, vielleicht war es auch nicht genügend für ein, ups, jetzt geht hier mein Aufnahmekomputer geht geradeaus.

Vielleicht ist es auch noch nicht groß genug für ein eigenes Kapitel, aber ich finde es interessant, dass hier so Type Hints oder Type Annotations so in einem ganz anderen Kapitel versteckt wird.

Und auch nicht so, dass man es jetzt, also ich habe mir ja die, das habe mir ja die Inhaltsangabe hier die Sachen durchgelesen, alle, aber da hat es nicht so mitgerechnet, dass das jetzt hier so eine Abbiegung macht und dann sagt, achso, übrigens, lassen Sie über Typen sprechen.

Ja.

Also sie kommt natürlich nachher nochmal, aber

ja, ja, ist natürlich schon auch so ein bisschen naheliegend, weil man muss halt jetzt dann irgendwie, wenn man schon erklärt, wie das da bei diesen Class-Bildern funktioniert, dass man halt über die Typ-Annotation im Grunde halt schon sagt, was das dann sein soll, dann muss man ja auch erklären, wie das funktioniert.

Und dann kann man ja, dann muss man ja irgendwie andere Annotations irgendwie erwähnen und dann, ah, dann ist man ja mittendrin in den Typ-Annotationen irgendwie.

Ja, man muss da so ein bisschen in den Wald reinlaufen und sich dann noch so ein bisschen drin verlaufen, ja.

Also ich verstehe es schon, aber es war irgendwie, was habe ich

nicht erwartet.

Und da kommt auch das eine Problem raus mit den Data Classes.

Also wenn ich so eine Data Class schreibe, dann habe ich ja diesen Dekorator vorne dran, Data Class, Data Classes.

Dann schreibe ich Class den Klassennamen, also in dem Fall jetzt hier Class Coordinate, und im Klassenkörper schreibe ich dann die Attribute, die die Instanzen haben sollen.

Und das wird hier in dem Kapitel sehr deutlich gemacht und das finde ich auch sehr richtig und sehr gut, weil das da tatsächlich eigentlich eine Abwendung ist von dem, was Python normalerweise macht.

Weil wenn ich normalerweise hier ein Attribut reinschreibe, also wenn ich Latitude gleich X reinschreibe und Longitude gleich Y, dann ist es ja erstmal ein Klassenattribut.

Und hier in dem Fall, wenn ich jetzt aber Latitude Doppelpunkt float, also Latitude getypt mit dem Float-Typ hinschreibe, dann ist es auf einmal ein Instanzattribut.

Und this unterschied is here in a given lesson diskutiert, weil that really sehr wichtig ist, weil es sehr leicht ist, diesen Unterschied zu machen.

These beiden sind sehr nah aneinander anders sehr gleich aus, machen aber dann andere Dinge und sind eigentlich anders als das, was in Python so normal ist.

Das heißt, da muss man schon besondere Vorsicht machen.

Du musst doch mal bitte den Unterschied genau erklären zwischen diesem Instanzattribut und dem Klassenattribut.

Ich habe nämlich schon mehrfach Menschen gesehen, die das so gewohnt waren, dass das halt dann immer ein Instanzattribut ist, was man da direkt unter die Klasse schreibt, dass sich das erst bitte festgestellt hat, dass das.

In anderen Sprachen ist es ja auch so.

Wenn du in Java oder C oder sonst wo bist, dann ist es genauso.

Dann sagst du, die Klasse soll folgende Instanzattribute enthalten.

Und in Python ist es aber anders.

In Python sagst du, die Klasse soll folgende Klassenattribute enthalten.

Der Hauptunterschied zwischen Klassenattributen und Instanz ist halt, dass ein Klassenattribut ist halt für alle Instanzen der Klasse gleich.

Und das ist halt wahrscheinlich überraschend.

Also diese Eigenschaft ist mir auch schon mehrfach blöd auf die Füße gefallen.

Aber so ist es halt, genau.

Da muss man vorsichtig sein.

Alles heißt, wenn du das irgendwo an einer existierenden Entität, dann wäre das für alle Gesetz?

Ja, also wenn das eine Klasse ist, du sagst halt jetzt, schaffst du es irgendwie, dass tatsächlich irgendwie ein Klassenattribut default-mäßig zum Beispiel eine Liste ist, also indem du das auf Ecke-Klammer auf Klammer zusetzt oder so, dann.

Oh, das ist jetzt aber ganz herzlich, was du machst.

Du und du überschreibst das nicht nachher nochmal irgendwie in einem Konstruktor oder so, was ja dann oft passiert, dann ist es kein Problem mehr, weil in dem Moment, wo man es im Init neu setzt oder so, ist es dann eine Instanz, ist es dann ein Instanzattribut und nicht mehr ein Klassenattribut, merkt man auch nichts von, ist vielleicht ein bisschen gefährlich.

Aber wenn das nicht passiert, dann passieren plötzlich wilde Dinge, weil dann ist das halt für alle Instanzen gleich.

Und es funktioniert zwar, dass man da Sachen appendet, aber da sind dann halt nicht nur die Sachen, die man selber appendet hat drin, sondern alle anderen auch.

Deswegen ist eine Konvention, wie man das macht, und zwar kann man das nennen, Cache unterstrich irgendwas.

Dann hast du einen Cache für alle Instanzen dieser Klasse, dann kannst du ja damit merken, alle Errors, die aufgetreten sind, ever oder sowas.

Ja, also das hat durchaus Gründe, weshalb man sowas haben will.

Ja, klar.

Ist ganz gut, aber damit kann man sich hart infuschieren.

Also tatsächlich, da hatten wir, glaube ich, auch schon ein paar Mal gesagt.

Dieses Instanzieren von leeren Dicts oder Listen ist in Python generell sehr gefährlich.

Wenn man das als Default-Argument macht, sollte man nichts.

Ja, ganz, ganz gefährlich, ja.

Und generell Klassen, also ich mache ja oft Programmierkurse und das ist wirklich schwierig zu verstehen, was eine Klasse ist und was eine Instanz von einer Klasse ist.

Und wie die zusammenhängen und was die zusammentun und warum die das so tun.

Und das ist echt, echt schwierig.

Und jetzt gibt es hier eben genau diesen subtilen Unterschied hier.

Das eine, das sieht genauso aus wie das andere, aber wenn du nicht Doppelpunkt-Int hinterschreibst, dann ist es auf einmal eine Klasseninstanz.

Und das ist schon, das ist wirklich was sehr Subtiles.

Und das geht eben weg von dem, was Python normalerweise macht.

Normalerweise schreibst du in die Klasse die Klasseninstanzen rein und hier schreibst du auf einmal, wie in anderen Programmiersprachen, wo es sich natürlich anfühlt, schreibst du die Instanz Eigenschaften rein, die Instanzattribute.

Wobei der dann natürlich zum Beispiel Data Classes schon auch auf die Finger haut, wenn du da irgendwie einfach eine Liste hinschreibst oder so, dann sagt dir da so, nee, nee, nee, das kannst du aber nicht machen.

Du musst ja irgendwie dann Default, wie heißt das Ding, Field?

Ja, eine Factory muss der Feld Factory angeben, genau.

Aber da kommt es natürlich rum.

Es gibt ja viele Mutable Classes oder viele Dinge, die du da reintun kannst, die eben nicht.

Das ist nur jetzt für Liste und für Dictionary und für Set.

Es ist special cased, weil die so häufig vorkommen.

Genau, ja, also das ist gefährlich, das stimmt.

Das ist, ich weiß auch nicht, wie ihr das so macht.

Also normalerweise, also sicher, also auch wenn man jetzt Konstrukturen hat von normalen Klassen, da ist es ja auch gefährlich, wenn man da irgendwie zum Beispiel sagt, annotiert, das ist jetzt eine Liste und dann sagt man gleich und dann Ecke Klammer auf, Klammer zu.

Und so viele Leute denken sich wahrscheinlich nichts dabei, wenn sie das tun, aber das ist halt auch schon brutal gefährlich.

Also ich mache immer List or none gleich none.

Ja, aber dann ist das

Pattern, das muss man sich einfach merken.

Das ist ein doofes Pattern, aber man muss es sich einfach merken.

Aber das ist ja auch nicht so schön, weil einmal ist dann deine Typ-Annotation halt so ein bisschen, also einmal ist sie halt hässlich, würde ich jetzt mal so sagen.

Mit diesem Pipe-None, das ist halt schon so, uh.

Es gibt doch diesen schönen Unknown-Typed hin dann.

Optional, nämlich auch hässlich, aber

Unknown gibt es ja noch dazu.

Ja, aber Unknown, uh, da ist ja schon, wer kennt das?

Uh.

Oder Annie.

Ich habe noch einen dritten Type-Hint, der da so ein bisschen spezieller war, dass das klar ist, dass das irgendwann mitstellen könnte.

Also was ich an der Stelle mache, also mir gefällt das alles nicht, ja.

Also okay, Leute machen das, aber also ich finde auch, ich finde auch, es funktioniert nicht richtig.

Wenn man jetzt den statischen Typchecker sagt, das kann jetzt auch None sein, dann hat man damit so einen riesen, dann hat man sich einen riesen Haufen Würmer.

Dann sagt er immer dann, er tatsächlich irgendwann im Code halt immer, hey, du hast ja nicht auf None geprüft und dann lintet er das alles, weil du musst vorher immer so ein Assert is not none machen.

Ja, oder noch schlimmer, also wenn es dann halt nur nervt, ist ja, ist ja noch, was noch schlimmer ist, ist halt, dass Bugs dann halt irgendwie unerkannt, dass halt, du kannst plötzlich a legal state representieren.

Und normalerweise sagen wir immer so, ja, also make illegal state unrepresentable.

Das sollte gar nicht passieren dürfen.

Der Type-Tracker sollte dir sagen: so, nee, das darf nicht none sein.

Und du hast dieses None ja nur benutzt, damit du es initialisieren konntest.

Das ist ja, hat ja gar nicht.

Wenn in deiner Logik nicht None vorkommen darf, was ja dann oft bei diesen Initialisierungsgeschichten gar nicht so ist, dann darf das da nicht drinstehen.

Und wenn du es trotzdem möglich machst, dass es drin steht, dann machst du halt eine Büchse Backwürmer auf, die dich ja irgendwann beißen werden.

Und die Frage ist halt nur, warum ist das.

Und was machst du oder umgekehrt?

Ja, umgekehrt, du machst es wie in Java, wo jeder Typ optional ist und hast dann auf einmal in jeder Scheißfunktion, in die du reingehst, musst du acht Variablen auf Null überprüfen.

Ja, das ist natürlich auch genau, das ist auch hässlich.

Also insofern ist es dann.

Nee, also ich würde sagen, aus der Perspektive betrachtet, musst du eigentlich sagen, nee, das darf nicht none sein dürfen und nicht optional sein dürfen.

Die allermeisten Sachen, die man so hat, die sind nicht optional.

Also du wirst sagen, das ist eine leere Liste.

Und wenn da eine leere Liste

reinkommt, musst du das neue initialisieren.

Ja, das war da auch wieder verwirrend.

Nee, kannst du ja auch nicht gut machen.

Nee, was ich an der Stelle mache, ist, ich nehme ein Trick.

Oh, eine Sentinel.

Eine Sentinel.

Ja, genau.

Von Luc Plant hat er das gesagt, da habe ich das her.

Und zwar definiere ich mir einen Typ namens Auto und der ist definiert über eine Klasse Unterstrich-Auto.

Und das Ding macht nichts, außer dass es nach Falls evaluiert.

Und in den Boolean-Kontext.

Auto, Auto, Auto, Auto, Auto, Auto, Auto.

Und den Typ Any hat.

Und dann musst du nicht oder irgendwas sagen, sondern Any geht halt überall durch.

Das heißt, wenn du mal ein Auto hinschreibst, dann kann man die Typ-Annotation richtig lassen und Auto geht halt trotzdem durch.

Aber Annie geht überall durch, das ist doch falsch.

Nee, aber das ist so.

Also dadurch, dass Auto Any hat, ist, egal welche Typ-Annotation du vorangeschrieben hast, ist es richtig.

Das ist übrigens PEP 696, oder?

Und das weiß ich nicht, ich kann die nicht außer nicht, aber

wie, du kennst nicht alle PEPs aus, wenn du sagst.

Ja, Entschuldigung.

Schwer enttäuscht.

Und dann kannst du halt in einem Konstruktor zum Beispiel dann halt sagen, if das Ding oder if not das Ding, dann machst du.

Das kannst du ja mit None auch nicht machen.

Bei None musst du dann krocktalweise immer sagen, if das da ist none, dann setzt es neu.

Und ja, also.

Ja, okay, aber wie würdest du das mit dem Auto machen?

Das habe ich jetzt nicht verstanden.

Da das ist Auto.

Es ist halt Auto.

Und also das importiere ich dann irgendwo her.

Und also der Default-Wert ist Auto, die Annotation ist so, wie sie halt sein soll.

Also zum Beispiel und dann sage ich, if das Ding, if not das Ding, dann setzt es neu.

Okay, aber wenn jemand eine leere Liste reingeben würde, würdest du es dann auch

neu setzen.

Also der Unterschied ist tatsächlich nur, dass er halt ein None will hast.

Aber dann würde ja, wenn das halt nicht okay wäre, dann würde ja der Toucher kein Mac haben.

Also du hast halt nicht, aber

du hast einen semantischen Unterschied eingeführt.

Ja, du schreibst halt nicht if not foo, dann, also ne, du schreibst if not foo, dann foo nur setzen, oder ne, weil das halt Auto ist immer fault, du sagst nicht, foo ist none, weil dann sparst du halt einfach das None, sondern.

Genau, ich spare mir das None und ich spare mir die Is-Geschichte und ich mache es halt so, wie es Leute mit None gibt.

Weil die X-Geschichte könntest das ja, du könntest ja auch noch ist sagen.

Das könnte ich auch machen.

Ich würde tatsächlich sogar sagen, du musst das machen, weil nehmen wir mal an, ich rufe diese Funktion, die du mir gerade eben gesagt hast, oder diesen Konstruktor, rufe ich auf mit dem Parameter und der Parameter ist eine leere Liste.

Und ich behalte die aber außen vor und benutze die an einer anderen Stelle nochmal.

Das heißt, ich appende da Sachen rein.

Das hast du jetzt genau den Use Case, den Python so gefährlich macht, den hast du jetzt kaputt gemacht.

Und jetzt überlassen Sie jetzt, wir starten jetzt eine Umfrage, schreiben sie uns an hallo.python-podcast.de, ob das gut oder schlecht ist.

Schlecht.

Ja, genau.

Also ich bin auch noch nicht endgültig zufrieden.

Ich hätte nur sagen,

damit die Hörer was sagen.

Aber also ich mache es halt jetzt gerade so.

Ich leide dann auch mal ein bisschen drunter, dass zum Beispiel LLMs, die halt das gewohnt sind, dass Leute da Nan oder Nan schreiben, dann die sind immer total verwirrt.

So, was will der denn da jetzt?

Und dann sagt er mir schon wieder, ich soll dieses Auto verwenden.

Hä?

Ich verstehe nur Bahnhof.

Machen sie

irgendwelche komische Sachen.

Und ja, ja, gut, ich schreibe das dann auch immer in die entsprechenden Rules mit rein, aber es hilft ja auch nur so begrenzt.

Es ist ein Kreuz, ich weiß auch nicht.

Der Code ist einfach zu wenig standardkonform, der ist zu wenig gewöhnlich.

Kann man den dann noch lesen, wenn er über ein Auto steht, weiß ja jeder, was gemeint ist?

Nee, das wissen Leute dann halt dummerweise auch.

Das ja auch schon passiert.

Wenn das das LLM schon nicht weißt.

Ja, genau, LLMs wissen es nicht.

Okay, aber das Kapitel macht ja jetzt noch eine zweite Abbiegung der Dominik, hat es ja schon erwähnt.

Und zwar Richtung Pattern Matching Class Instances.

Auf einmal kommt hier in dem Kapitel noch Pattern Matching.

Hooray!

Was?

Das ist ja schön, Pattern Matching, oder?

Zweiter Twist in the End.

Ja.

Da war ich ja überhaupt gar nicht drauf vorbereitet.

Dominik, warum magst du Pattern Matching?

Erklär mal.

Weil ich damit relativ verschiedene.

Das ist erst blöd, weil das mag man eigentlich nicht.

Also ich kann verschiedene Objekte entgegennehmen und die checken und dann gucken.

Okay, und

wie geht das?

Erklär mal, wie das geht.

Du machst ein Match und ein Case auf, match dann deine Variable, die du hast und gibt es dann verschiedene Cases.

Also du hättest gerne irgendwas ist, schwieriges Beispiel, so eine Koordinate.

Dann gibst du rein, dass das eine Koordinate sein könnte und dann hat er tatsächlich den Pfad, okay, hier ist eine Koordinate.

Und wenn du danach zum Beispiel sagst, ist eine Straßenadresse, dann guckt der, okay, ist eine Straßenadresse, passt da rein und gehst weiter.

Und du kannst da bestimmte Attribute omiten, indem du die einfach auf dann setzt, falls das verständlich ausröscht ist.

Und kannst damit relativ schön Cases abfangen und hast irgendwann ein Standard-Case.

Also so ein bisschen so if- then, ne, if, Elif, Elif, Elif, in.

Gut lesbar, finde ich.

Also ich mag das sehr gerne.

Ja.

Du kannst auch Types machen und kannst Guards machen und sowas.

Ja, man kann da sehr viele Sachen an.

Das verdient fast eine eigene Episode.

Da muss man eine eigene Episode zu machen, haben wir noch nicht gemacht, haben wir auch schon häufiger geplant, aber ja, genau, das müssen wir machen.

Man kann auch da, ich finde, ja, also es ist super mächtig, ich brauche es ehrlich gesagt nicht so oft.

Ja, das ist ein großer Fan davon.

Ich finde das großartig, das ist eins der besten Language Features, was es gibt, aber ich habe es noch nie verwendet.

Ganz komisch.

Also ich meine, ich glaube, das ist halt auch für Leute, die jetzt oft Parser für irgendwelche Sachen schreiben oder so.

Oder halt so Domain-Specific Languages für irgendwas haben.

Die brauchen das wahrscheinlich oft.

Aber das macht halt nicht so oft.

Also ich, also das erste Mal habe ich Pattern Matching gesehen.

Da war ich noch ein junger Mann damals und das war ein Erlang.

Ah, ja, ja, ja, gut.

Und da ist es ja ein Core Language Feature.

Da ist es ja so ein, ja, hier, da hast du eine Funktion.

Und natürlich, das erste, was die Funktion macht, ist immer erstmal Pattern Matching.

Und die benutzen das für alles.

Wenn du hier einen Nun reinkriegst, ja, klar, dann geht die Funktion des, wenn das Pattern hier ein Nun ist, dann musst du erstmal hier wissen, dass jedes machen.

Und da ist es ja nicht, da geht es nicht so sehr um Parser, sondern da geht es ja schon irgendwie auch um Schnittstellen und um Datenaustausch.

Und ich habe in meinem Kopf schon immer den Gedanken, dass man, wenn ich eine Schnittstelle schreibe, dass ich da irgendwie so ein Pattern-Matching reinmachen könnte.

Aber irgendwie hat es noch nie so richtig gut gepasst.

Ja.

Weiß auch nicht.

Ich weiß auch nicht.

Kann man in die Exception-Types gucken oder.

Ja, aber die fange ich doch in dem Accept, in den Accept-Blocks schon ab, die verschiedenen Exception-Types.

Da gibt es auch schon einen Syntax für.

Und für die verschiedenen Instanztypen, die muss ich eh irgendwie in Funktionen reinverzweigen und ach, ich weiß irgendwie nicht.

Ich würde es gerne mehr benutzen.

Ich weiß nicht, ob das den Problem an mir ist oder ob das ein Problem an.

Also ein Problem war eine ganze Zeit lang auch, also jedenfalls, als das Feature total frisch war, für mich jedenfalls auch, dass ich mir gedacht habe, ich muss ein bisschen vorsichtig sein, dass ich das jetzt nicht irgendwie mich zu sehr darauf verlasse, dass es das gibt, weil es ist ja noch ganz neu und viele verwenden halt noch ältere Python-Versionen.

Und vermutlich super langsam.

Ja, genau, aber das ist ja jetzt inzwischen 13 ist jetzt schon die älteste Version, die man so, mit der man normalerweise so zu tun hat.

Nee, 10, 3.

Also 3.10 meinst du.

Ja, genau.

Und eine 13 ist es, genau, nicht 13 meinte ich nicht.

Nee, nee, 3.10, genau.

Ja, 3.10, ja, das ist, würde ich sagen.

Und da ist es ja dazugekommen.

Also insofern würde ich sagen, jetzt ist sicher, dass man es eigentlich immer verwenden kann.

Insofern, ja, muss man gucken, ob es da nicht doch mehr Use Cases gibt, als man so denkt.

Aber es ist auch fiese Syntax.

Also ich habe mir dazu auch schon ein paar Vorträge angeguckt.

Und man kann sich auch da wieder leicht in den Fuß schießen.

Ja, was nicht so ganz intensiv ist, dass wenn man so die Bild in Typen nimmt, also man sagt irgendwie Match Unknown und dann machst du einen Case-List or Tuple.

Und wenn man die dann nicht instanziert mit den Klammern, dann ist es immer true.

Der nach der Funktion guckt und nicht guckt, ob es eine List oder ein Tubel ist.

Genau.

Ja, kann man sich ja auch mit den Fuschis tippen.

Ja, und dass der Default-Fall auch immer irgendwie, wenn nichts anderes gefunden wird, ist auch irgendwie etwas, was halt in anderen Sprachen anders ist.

Naja.

Oder dass man den am besten immer handeln sollte, genau, in Python, dass man.

Ja, aber

das ist doch auch nervig.

Ja, gut, aber nicht

klassische Programmierung, dass man immer das Elst für alles, was man nicht erwartet, schreibt.

Wenn man das Els weglassen kann, dann lässt man es weg.

Je mehr man weglassen kann, umso mehr kann man weglassen.

Das ist doch viel besser.

Eigentlich schon.

Ja, und dann ist das Kapitel auch schon vorbei.

Dann kommt nur noch hier so ein bisschen.

Also Else makes the Universe explode.

Also immer, wenn der Else-Case einsteht, dann alles abreißen.

Alles vernichten.

Nee, komm.

Ist das Quantumsort, ja.

Kennt ihr den Quantumsort-Algorithmus?

Der ist ein O von 1-Sortier-Algorithmus.

Du machst eine zufällige Permutation von deinem Input und

machst auch rüber, ob es

sortiert ist.

Und wenn sie nicht sortiert ist, zerstörst du das Universum.

Und das in dem Universum, in dem sortiert bist, ist das, überlebst du immer.

Schnell, geht nicht mehr.

Dieses Kapitel macht mehrere interessante Wendungen und es schneidet einige Sachen an, die interessant sind, die aber so ein bisschen über Data Classes hinausgehen.

Ich muss ja sagen.

Macht ihr denn lieber Data Classes oder lieber Name-Tupels?

Lieber Data Classes.

Ja, ich auch.

Lieber Data Class.

Ich weiß jetzt gar nicht so genau, warum.

Ja, weil das gutes Marketing hat.

Es steht auch hier in dem, also hier im Abschnitt Further Reading, da sind natürlich viele Verweise dann drin.

Und da steht auch drin hier bei der PyCon US 2018, da gibt es einen Talk von Raymond Hattinger, den wir auch wir alle schon gesehen haben.

Und ich gehe davon aus, dass die Hörer den auch alle gesehen haben, der heißt Data Classes, the Code Generator to End All Code Generators.

Und das hört sich ja schon sehr hochtrabend an.

Und ich muss sagen, ich habe mir den Talk angeguckt und ich habe danach Data Classes verwendet und das war gar nicht so beeindruckend.

Ja.

Es ist irgendwie gar nicht so viel, was einem das macht, was einem das gibt.

Deswegen auch direkt an dem Tupel.

Ja, also

man darf da gar nicht so viel drauf geben.

Da werden viele Worte darüber gesagt und es wird viel drüber gesprochen, aber es ist eigentlich was total Simples, was total Kleines und Nettes und einfaches und das, ja.

Ja, also es gibt halt so Anwendungsfälle, dafür wenn ich es halt sehr gerne für.

Also zum Beispiel eben in so, so für, also wenn man jetzt halt so Event-Driven Architecture hat, dann für die Events und Commands, da sind ja da Classes halt super.

Genau, für alle Arten von Value-Objects, wo man halt nichts drauf gibt, was das denn konkret für ein Objekt ist, wo nur der Wert von irgendwelchen Dingen interessiert, da ist das total super.

Und für alles andere nehme ich normale Klassen.

Also genau, das ist so mein Daumenriegel für diesen Kram.

Und ja, ich glaube, in allen Fällen, wo ich Data-Class verwende, könnte ich wahrscheinlich auch Name Tupel verwenden.

Ja, aber es ist schon bequemer, dass man die Namen schreiben kann, das ist schon cool.

Das kannst du bei NameTuple auch.

Ja, ja, genau, aber dann kannst du nicht ein normales Tupel nehmen.

Nee, nee, aber Nametupel ist das schon.

Also ich würde nutzen, was ich nicht.

Ich würde, glaube ich, fast nie ein normales Tupel nehmen.

Sondern statt einem normalen Tupel immer ein Nametuple, weil ich gerne die Namen verwende und ich mag indiziere es nicht so.

Ja, okay.

Ich verwende Tupel sehr häufig.

Ja, ich würde so im Beispiel...

Vielleicht für Multiple Return-Werte.

Genau, beim Zurückgeben von irgendwelchen Sachen ist es halt ja automatisch.

Aber da benutzt du ja auch den Index nicht, da benutzt ja Unpacking.

Und dann ist ja schon diese Tupel, ist dieses Tupel so ein bisschen.

Da wird sie dann nicht ein Name-Tupel verwenden, ja.

Ja, doch, also warum nicht?

Als Return-Wert ein Name-Tupel, dann hast du schon Type-Annotation und kannst danach auf die Attribute des Dings wieder zu beachten.

Viel zu viel Arbeit.

Einfach zwei Werte zurückgeben, zack.

Zack, zack, dies und jedes.

Dies und dieses oder vielleicht auch das.

Und dafür werden Match Case wieder gut.

Ja, sorry.

Ich glaube, wir haben das besprochen.

Wollt ihr noch was erzählen?

Also, genau, was wir noch tun könnten, ist irgendwie, wir machen noch Pilgs und ich weiß nicht, ob irgendjemand anders anfangen möchte.

Ja, ja, haben wir das nicht?

Okay, also.

Das ist auch was Gutes.

Ja, also was ich gerne picken würde und ja, ich weiß nicht, ob die so viele Hater haben wir gar nicht, aber das wäre ein guter Hook für die Hater.

Wir hätten erst einmal ein, wenn ich mich aktiv erinnere.

Und zwar, was mir momentan tatsächlich.

Nacht zum Hyp 3 mit dem Tun, da war ich auch schon vor.

Ja, aber also was mir, was mir tatsächlich momentan richtig viel Spaß macht, ist ein Tool von Anthropic und zwar heißt das Claude Code.

Und das ist quasi so ein LLM-basierter Kommandozeilen Dings verleihen.

Ja, weil, ne, genau, was das ist.

Ja, schwierig.

Ja, also das Ding ist einfach nur, es ist halt ein LLM und es läuft in einer Schleife und macht halt Dinge.

Und das funktioniert.

Also ich will jetzt gar nicht so definieren, was das ist.

Hast du Claude schon einen Rootzugriff auf deinen Rechner gegeben?

Das mache ich nicht, aber in Projekten, wo ich weiß, wenn das committed ist oder gepusht, dann kann es das halt auch weglöschen, ist nicht so schlimm.

Ja, gibt dir nochmal ein, zwei Server, da kannst du dich austoben, ein bisschen Budget dafür.

Ich habe

mal gefragt, also auch Claude, ob das jetzt eigentlich mich ersetzt oder ist das, ne, was ist das so für eine Beziehung?

Muss ich Angst haben oder argumentiert mich das eher oder sowas?

Und Claude meinte dann so, hey, ist eher so eine Bromance.

Ja, okay.

Glaube ich bei dir, Dominic.

Das glaube ich bei dir.

I agree.

Bromance zwischen dir und KI.

Aber also ich würde es einfach mal, also man kann das nicht gut beschreiben, man muss das mal ausprobieren.

Und da ist es eigentlich schon sehr cool.

Also ich benutze das jetzt in letzter Zeit super häufig.

Und das hat mir schon echt viel.

Häufig untertrieben, weißt du, wenn du Jochen beim Arbeiten zu gucken.

Rechnet die ganze Zeit nur noch

so, nö, ja doch, vielleicht.

Och, mach nochmal so.

Ja, aber das ist auch schon wichtig.

Also ich gucke schon noch drauf und ich.

Also das heißt, das drauf gucken ist das, was sich vom Vibe unterscheidet.

Ja, ja, nee, das ist nicht Vibecoding, was ich, also ich nenne das manchmal bloßhafterweise Vibecoding.

Das ist nicht Vibecoding.

Um die Leute, um die Leute zu ärgern, die.

Keine Sorge, aber das ist nicht Vibecoding, das weißt du.

Ja, es gibt ja zwei Menschen, glaube ich, die sich mit dem Begriff Vibecoding so ein bisschen fertun.

Das Simon zum Beispiel sagt, das wäre gar nicht so.

Ja, also die ursprüngliche

Begriff total blöd ist, weil der dafür eigentlich was total anstrengend ist.

Das war mal gut definiert und zwar als Vibecoding ist halt dann, wenn das Ergebnis und der Code egal sind und du halt nur sozusagen basierend auf dem Vibe haben.

Weemand anders sein Wort verwendet hat, was nicht so ist, wie er es haben möchte.

Ist doch auch Old Manual Z Cloud.

Ja, aber er hat schon recht, also das war ursprünglich mal so definiert und jetzt benutzen es halt alle irgendwie anders und das ist natürlich schon ein bisschen doof.

Ist egal, jedes Wort Vibe ist halt nicht mal anders definiert.

Ja, aber es gibt in dem Bereich halt schon so viele Worte, die halt ihre Bedeutung verloren haben, dass jetzt so das ja, okay.

Na gut, es ist auch wurscht, kann man auch nicht mehr zurückholen.

Meinetwegen ist es auch Vibe-Coding, aber also ist es tatsächlich so, dass ich damit halt viele Dinge irgendwie jetzt so machen kann, die vorher mühselig waren und jetzt sind sie halt nicht mehr so mühselig.

Und auch quasi das über Copy-Paste und oder halt über Cursor oder sonst wie Copilot kann man das ja auch machen.

Das hat auch schon alles ganz gut funktioniert, aber Cloud Code ist tatsächlich für mich nochmal eine deutliche Verbesserung.

Also das ist halt, macht alles nochmal deutlich angenehmer.

Das ist schon mega gut.

Aber da möchte ich tatsächlich für alle, die es noch nicht kennen, die meisten kennen es wahrscheinlich, MindPick machen.

Und zwar ist das tatsächlich, wie in meinem Ausschuss weiß ich nicht, NATN.

IO.

Ich finde normalerweise so Logo-Sachen ziemlich schlecht und schwachsinnig und scheiße, aber das Ding ist erschreckend gut.

In Business-Prozessen direkt anbinden an der Postgres, an SAP, an was auch immer du gerade brauchst.

Und du kannst es dir so zusammenklicken.

Machst du da einen Telegram-Channel dazu und dein Discord und hast einen Bot und ziehst da so zwei Lines irgendwie zusammen und machst dann noch einen Prompt dahin und setzt dann da noch eine Nachfrage für das Ergebnis vom Prompt, passt das dann in JSON, kannst einen kleinen Python-Snips reinbauen.

Also wenn ich Low-Code mir überlegen würde, würde ich das wahrscheinlich auch so machen.

Das ist, also ich würde sagen, das ist sehr gefährlich für unsere Profession auch.

Also weil ich kann nicht jetzt jeder Marketier hinsetzen und sagen, so, hey, ich bin Coder und macht sich miteinander so ein Business-Prozess, wo man vorher halt gut bezahlte Software-Ingenieure für braucht.

Das ist schon so ein bisschen schon nicht schlecht.

Also, ne, da sind wir wieder bei dem Pick, den ich eben schon gespoilert habe, den der Johannes verraten wollte.

Nee, das ist nicht mein Pick.

Aber das macht es ja schon so ein bisschen.

Das ist ja der Zeug teilt viel Zeugs, viel Code, den man halt kaputt machen kann.

Oder halt auch nicht, ne?

Oder ist der kaputt?

Wen braucht man dafür?

Die richtigen Ingenieure wie

uns, um das wieder zu reparieren?

Oder schafft das dann Cloud Code selber?

Naja, also ich meine, funktioniert.

Für den Anwendungsfall, dass du halt überhaupt erstmal irgendwie rausfinden willst, ob das etwas ist, was du gebrauchen kannst oder nicht.

Dafür ist das wahrscheinlich noch nicht so schlecht.

Nein, Locken, aber das ist ein Irrtum, es geht nicht nur darum, rauszufinden, was das ist, was du willst, weil das ist genau das, was die, ich sag mal, Mediocre-Devs immer schon verkauft haben.

Irgendeinen Scheiß, der gerade so aussieht, als wird er funktionieren, und nach zweimal Gegenpusten zusammenbricht.

Und das ist kein Unterschied mehr zu dem, was du dir einfach da viben kannst.

Und das ist das, mit dem die meisten Leute irgendwie in der Branche irgendwie ihren Umsatz gemacht haben.

Und das ist der jetzt einfach quasi obsolet.

Oder was halt ein, der das

so gespielt hat.

Weiß ich nicht, du bist ja immer noch dann abhängig auch da von dem Service und so.

Also, naja.

Business Leaders, ne?

Unfuck it I, how did you find us?

My therapist recommended you.

Are you very sorry?

Yes, no, fuck you.

Genau.

Ja, also ich muss, ich stimme zu, dass das halt von den ganzen Dingern, die es da draußen gibt, halt tatsächlich irgendwie gut gemacht ist.

Ich persönlich, für mich hat das nicht so appeal, weil ich denke mir so, na gut, ich schreibe halt Python, das macht für mich jetzt halt mehr Aufwand.

Ich kann schon programmieren, ich brauche das nicht.

Ja gut, aber so eine Postcast-Schnittstelle mit zwei Klicks, ne?

Ja, aber also ist für mich jetzt nicht so ein Aufwand, aber ja, gut.

Wir werden sehen.

Vielleicht, ja, keine Ahnung.

Aber mein Pick

geht in eine ganz andere Richtung.

Turn a caffein into Code?

Ich picke Unregistry.

Ich bin ja ein Docker-Anhänger.

Und ein Problem, was man aber hat mit Docker-Containern, ist, dass wenn man die lokal gebaut hat auf seiner Entwicklungsmaschine, dann muss man die irgendwo hintun, damit die deploybar werden.

Das heißt, wenn ich die auf meinem Produktionsserver dann ausrollen möchte, dann müssen die irgendwo sein.

Dieses irgendwo heißt normalerweise Registry.

Ja, Docker-Hub, die kannst du nehmen, wenn der Open Source machst, wenn du keine Geheimnisse, wenn du alle deine Sachen offenlegen willst auf der Welt.

Ansonsten ist es eine RTV.

Das ist echt scheiße.

Artefactory Nexus oder in die Amazon in so eine private Registry für Amazon.

Aber jetzt gibt es hier ein Projekt, das heißt Unregistry.

Und damit kann ich direkt von meiner Maschine auf die Servermaschine ein Image pushen, ohne über eine Registry zu gehen.

Der Trick ist, also das geht natürlich manuell auch her.

Ich kann natürlich manuell dieses Docker-Image exportieren und kann es tippen und dann per SCP rüberkopieren und so weiter.

Aber das ist zum einen nervig und es ist auch langsam, weil jedes Mal das komplette Image übertragen werden muss und nicht nur die Schichten, die man neu braucht.

Und das macht Unregistry einfach alles im Hintergrund.

Das heißt, der Trick ist, das tut so, als ob es eine Registry wäre.

Und wenn du sagst, hier push mal auf den Server, dann macht es dort einfach kurz eine Registry auf, dann pushst du da hin.

Und dann ist es bei dem Server, bei dem Produktionsserver einfach im lokalen, in den lokalen Images drin.

Und das ist großartig, weil das macht viele Deployment-Prozesse einfach super viel einfacher.

Du kannst dann aber nicht History und sowas ist dann halt weg, ne?

Wie meinst du History?

Hast du bei Docker-Containern nie.

Na doch.

Jeder Tag, den du pushst, ist dort.

Also du hast kein zentrales Repo mehr und das ist genau das, was du möchtest.

Okay.

Wenn du die Sachen aufbewahren möchtest, dann brauchst du eine Registry, ja.

Ja, achso.

Achso, wenn du, also du meinst History von Images.

Ja, okay, das hat.

Nee, das ist ja eben unregistry.

Das hast du jetzt nicht mehr.

Und das will ich auch in ganz vielen Fällen einfach nicht haben.

Ja, es ist eben meistens noch ein Müllbalast der Trumpf.

Ich habe immer nur Latest.

Es gibt nur Latest.

Aber wenn du das Customer gemacht hast, Johannes, da musst du ja dann wieder zurück anstanden, dass du Vorwart gibst.

Ja, gut, aber das habe ich dann noch lokal.

Na gut.

YOLO, YOLO DRIVEN Development.

YOLO Vibe.

Ja, danke fürs Zuhören.

Das war gleich.

Kommt zum HörerInnen-Treffen vorbei und wir freuen uns auf euch hier.

Warten wir das gleich noch?

Ja, Ende August, Ende September.

We are discussing that in another episode.

Okay.

Und machen wir es.

Ja, dann bleibt uns gewogen.

Hallo.pythsonpodcast.de.

Dankeschön und bis bald.

Macht's gut.

Ciao, ciao.