Transcript: Was, wenn alles ein dict wäre?

Ja, hallo liebe Hörerinnen und Hörer. Wir kommen beim Python-Podcast, Episode 36.

Heute wollen wir mit euch ein bisschen über die technischen Implementierungsdetails von Dictionaries reden.

Jochen ist natürlich wieder da. Hi Jochen.

Hallihallo, Dominik.

Dominik, genau. Und heute ist auch wieder Johannes dabei. Hi Johannes.

Hallo zusammen.

Ja, moin.

Ja, wir fangen wie immer ein bisschen News aus der Szene an und was uns sonst noch so einfällt und dann gehen wir so ein bisschen in das Thema rein.

Ja.

Ja. Also du wolltest

unbedingt noch über den Copilot reden, habe ich gehört.

Ich wollte das.

Ja, ich auch. Der Jochen ist derjenige, der immer

darüber sprechen möchte. Ja, wir haben schon zweimal

darüber gesprochen. Aber jetzt hat auch Jochen

ihn ausprobiert. Jetzt hat auch

PyCharm hat jetzt auch Copilot.

Deswegen, genau.

Genau, ich habe irgendwann die erlösende Mail von

GitHub bei mir bekommen, sodass ich jetzt im Beta-Programm

auch mit drin bin. Und genau, da muss ich das

natürlich direkt mal ausprobieren. Und ich hätte da eigentlich gar keine

so hohen Erwartungen, obwohl du immer schon so davon

vorgeschwärmt hast. Ja, du hast immer gesagt, ach, was für ein Krass,

ist ja völlig egal. Ja, das kann ja nicht, also wenn man

jetzt irgendwie so durchschnittlichen Code

davon irgendwie in den Leuten kriegt, das kann ja nichts

das kann ja nichts taugen.

Aber ich muss sagen, ich bin

doch sehr überrascht, dass das manchmal

wirklich, wirklich hilfreich ist.

Sogar Jochen findet das hilfreich.

Sogar Jochen findet es hilfreich. Ja, ich finde es auch sehr cool.

Also ich finde vor allem diese Autocompletion cool. Er lernt irgendwie

aus seiner eigenen Codepace und weiß so ein bisschen, was

du als nächstes vorhaben könntest oder er macht manchmal so einen guten

Vorschlag. Ist natürlich nicht immer,

ist auch nicht immer richtig, aber manchmal ist er staunlich richtig.

Ja. Ja und manchmal

findet man halt Dinge dadurch

erst, die man, also ich

mache jetzt manchmal auch so ein bisschen

JavaScript beziehungsweise TypeScript

und

manchmal weiß ich einfach nicht, wie Sachen

gehen. Also ich habe keine Ahnung, wie das geht

und dann fange ich irgendwie mit einem variablen Namen an

und dann kriege ich so einen ganzen

Codeblock und der tut genau das, was ich

eigentlich machen wollte.

Also du musst halt wirklich aufpassen, was für

Namen du den Dingen gibst. Wenn du den guten Namen gibst,

ist der viel besser, als wenn du schlechte Namen gibst.

Da muss man sowieso aufpassen,

und immer gute Namen finden. Genau, aber wenn man das dann halt

macht und dann auch einen guten Doxtrain schreibt oder einen Kommentar

dazu, dann lernt er sogar noch aus diesen Doxtrains,

aus den Kommentaren was dazu. Oder halt, also

was halt bei mir vorgefunden wird, ich mache halt den

Methodennamen beispielsweise oder den Klassnamen oder

die Funktion und die Argumente und

Type-ins und dann weiß er ziemlich oft, was

zu tun ist, wenn ich den Doxtrain noch mache.

Dann schreibe ich im Doxtrain rein, was er tun soll und dann

der Vorschlag, der ist schon echt gut.

Also auch, da gibt einer halt auch Implementierungsvorschläge

an, die man vielleicht nicht gedacht hat oder sowas schon.

Ja, also da,

das ist durchaus

aus sehr...

Und ich weiß, warum Jochen den gut selber...

Weil er sich ja immer selber am eigenen Code-Repo orientiert.

Er orientiert sich an Jochens eigenem Code und dann denke ich auch

natürlich immer, oh, was für ein toller Vorschlag.

Ja, ja.

Das hat den Stil.

Also,

Kritik würde ich sagen,

es ist auch besser geworden,

wenn man diese Nightly-Versionen nimmt.

Ich habe zuerst die Standard-Version genommen

und man kann halt die

aktuelle Bleeding Edge-Geschichte nehmen.

Die ist, finde ich, nochmal ein gutes Stückchen besser.

Was manchmal

nicht so gut funktioniert, also was, womit

Copilot halt irgendwie unerwarteter

Weise, weil man denkt, das ist eigentlich eine einfache Geschichte,

große Probleme

hat,

wo er das große Problem hat, ist Klammern.

Also die Klammern richtig zu setzen,

also zum Beispiel zu machen,

Klammern richtig zu, oder

halt irgendwie, dass das halt

nur Sinn macht, wenn es runde Klammern sind. Manchmal macht er auch

einfach eckige Klammern bei mir, so an Stellen,

wo Funktionen aufgerufen werden und dann

ist das natürlich, das funktioniert halt nicht.

Kannst du das nicht erklären,

Das ist doch irgendwie diese neuronalen Netze, weil die halt

nicht genügend Zustand für sowas haben, oder?

Ja, man muss denen halt irgendwie

die Syntax sozusagen irgendwie so einprügeln,

dass sie das halt nicht, dass das nichts Unscharfes ist

oder, aber das funktioniert vielleicht

nicht so richtig. Also meistens funktioniert das auch.

Ja, aber prinzipiell

hat dieses Netz ja kein Verständnis von

ich habe N-Klammern geöffnet und du musst jetzt

N-Klammern auch wieder schließen in der richtigen Reihenfolge.

Du kannst ja alle Vorschläge aussortieren, bei denen das

nicht stimmt oder du kannst ja danach noch auditieren oder sowas.

Ja, ja, klar, also es ist jetzt auch kein großes Problem

das ist halt irgendwie so ein bisschen erstaunlich

wo man sich denkt, naja, also das Schwierige, den

schwierigen Teil, den kann es eigentlich überraschend gut

nämlich irgendwie rausfinden, was man

da machen wollte und dann den Code schreiben

der zumindest so aussieht, als würde das richtig gut

und dann kommen halt so Dinge, wo man sagt

das kann ja fast, eine IDE kann das ja schon

so die Klammern richtig setzen

und das geht dann nicht mehr, ja gut, aber

ich meine, das sind Sachen, die wird man

halt mit der Zeit in den Griff kriegen, denke ich mal

und dann ist das schon

echt beeindruckend

Was man auch mal machen muss, ist so User-Daten

beispielsweise machst du irgendwie eine JSON

und dann machst du

einen Namen, eine E-Mail-Adresse oder so

und ein Passwort und dann machst du Autocomplete

und dann gibt dir halt eine Liste

von Usern irgendwie

mit seinem Passwort und so.

Das ist dann die Frage.

Das ist für den Demo-Benutzer perfekt.

Ja, oder sind die generiert oder echt?

Man weiß es aber nicht so genau, von wo die sind.

Das sind alle gelernt.

Ja, es ist wohl auch, wenn man so Zahlenfolgen eingibt,

dann gibt er einem interessante Instruktionen.

ein Screenshot gesehen, wo dann russische Funktionsnamen dazu kamen.

Also, okay.

Ja, ich bin ja mal gespannt, was dabei rauskommt.

Wenn man so was, man anfängt irgendwie so 3.1417...

Ja, ja.

Ab wie viel Nachkommastellung?

Ja, ja, vielleicht, vielleicht.

Also, ja, das ist ja...

Das ist noch keine AGI, das ist noch keine generelle Intelligenz, glaube ich.

Da habe ich letztens, ich komme vom Holzen aufs Stöckchen,

aber vielleicht ist das ja auch nicht so uninteressant,

und wieder einen ganz netten Podcast-Episode gehört mit Lex Friedman, wo Lex Friedman Stephen Wolfram interviewt hat.

Ja, der ist ja so ein Wunderkind und dann so ein bisschen hinter den Arm.

Eine sehr kontroverse Persönlichkeit.

Ja, polarisierend.

Warum? Jetzt musst du das genau aufklären direkt.

Ja, es gibt Leute, die lieben ihn total und der macht ja auch viele gute Sachen,

aber es gibt Leute, die hassen ihn auch total, weil der halt auch seine Meinung für sehr wichtig hält.

Achso, okay, ich wollte gerade sagen, wir wollen ja die Gründe und Anekdoten auch hören, es geht um seine Meinung, die er präsentiert

Ja, und er ist auch so ein, er hat so ein paar interessante Fixierungen, der findet, dass die ganze Welt aus State Machines besteht und muss alles mit State Machines machen

Und Rule 34 ist das einzige, was...

War das nicht Rule 38 oder so?

oder so. Ja, diese 30er-Regeln,

also das ist so eine Klasse von

State Machines

und die kannst du

durchnummerieren und die haben eine natürliche Ordnung

und dann findest du halt irgendwann

eine, die eine universelle Turing-Maschine ist

im Wesentlichen und

Stephen Wolfram sagt

halt mehr oder weniger, der schreibt ganze Bücher

darüber, was diese State Machine alles

kann und dass die das Universum enkodiert und das

ist natürlich

wenn du

wenn du die gesamte Wissenschaft umstellen willst auf State Machines.

Also ich habe immer noch keine Ahnung, was

Rule 38 ist, aber das Urban Digitry hat mir gesagt,

Rule 38 is a prison offense

in which someone is masturbating in public.

Ah ja, okay.

Also wenn du mal viel Spaß haben willst

und Private Mode an hast, dann google

doch mal nach Rule 34.

Rule 34, das ist glaube ich die

If it exists, there's porn of it.

Glaube ich. Das ist auch irgendwie

eine sehr wichtige Regel und tatsächlich stimmt sie

halt einfach immer. Aber

leider erstaunlicherweise.

as a type of font as a website for it.

Ach so, okay.

Das ist auch Rule 38.

Rule 30 sagen die.

Okay, aber das sind beides nicht die Regeln, die ich jetzt gerade meinte.

30 ist es.

Genau, um diese Dinger ging es

natürlich bei der Episode auch.

Ich finde das schon interessant.

Leute hatten

hohe Erwartungen an ihn, weil er war halt so ein Wunderkind.

Und dann ist aber irgendwie

dann doch nicht irgendwie so wirklich so

Einstein-mäßige

Ausmaße haben seine Theorien

da jetzt nicht angenommen, sondern

ein bisschen hinter den Erwartungen zurückgeblieben.

Aber tatsächlich ist er ja

genau eben der Meinung.

Er hat ja ein Buch geschrieben, das hat auch schon so einen Titel

New Kind of Science.

Den kann man ja auch nur nehmen, wenn man denkt, da hat man jetzt mal echt was

gefunden.

Er hat ein gewisses Selbstbewusstsein.

Aber er hat ja auch coole Sachen gemacht, also so ist es nicht.

und er ist halt auch super

ungeheuer produktiv, also es gibt so eine

er hat so ein Diagramm veröffentlicht von

wann er E-Mails schreibt und der hat eigentlich

immer 18 Stunden Tage und manchmal hat er

auch 24 Stunden Tage, also

er schlägt es einfach

durch Produktivität, diese ganzen

Kritikpunkte

Ja, also er hat ja auch so eine Firma, die macht

Mathematiker, auch eine super Software, also

ja

oder eben Wolfram Alpha, wie gesagt

Wolfram Alpha, genau, ja und

ja auch die Firma so zu nennen, also

und naja gut, aber

das ist, er macht ja wirklich

cooles Zeug, also so kann man eigentlich auch nichts sagen

und

das fand ich nur ganz interessant, weil es jetzt,

weil er auch da, da kam das Thema auch

auf Pi, ich meine, das ist ja auch

so eine Zahl, die einem ab und zu mal

irgendwie über den Weg läuft und er

Du meinst Tau halbe?

Ja, genau, ja stimmt, Tau

ist dann vielleicht etwas, was man häufiger noch braucht als Pi

und

genau, wie jeder

weiß, ist das Ding halt transzendent

rational und

hat eine Menge

super interessante Eigenschaften,

aber so fundamentale Sachen, die man jetzt, wo man

denkt, das müsste man doch eigentlich darüber wissen,

also wie zum Beispiel sowas wie

kommen denn

alle Ziffern in der

Dezimalbruchentwicklung von Pi mit der gleichen

Wahrscheinlichkeit vor? Also ist Pi normal

oder nicht? Das weiß man

halt nicht und zwar so gar nicht und hat auch

gar keine Ahnung, wie man das irgendwie hinkriegen könnte.

Dabei ist die Regel, die jetzt Pi erzeugt,

eben auch ziemlich einfach eigentlich.

und dann ist es doch irgendwie überraschend,

dass dabei eine Ziffernfolge rausfällt, die einmal

so total zufällig aussieht, wo man

nicht drüber sagen kann,

nicht mal die Verteilung der Ziffern

da drin sagen kann und die so aussieht,

als könnte man wirklich

nicht, man kann es halt auf nichts anderes reduzieren.

Man kann da drin, findet dann keine Muster.

Da kommt einfach

alles, was es überhaupt an Mustern irgendwie gibt,

kommt wohl offenbar daran vor.

Die Frage

ist halt, wie kommt aus so etwas,

aus so einer einfachen Regel, wie man

P bilden kann. Warum fällt da plötzlich so ein ganzes Universum raus?

Ja, das ist ja im Wesentlichen das, was der Wolfram auch sagt mit seiner Regel 30.

Das ist ja eine ganz simple Regel. Das ist die 30. die du ausprobierst, wenn du sie nach seiner

Ordnung machst und dann kommt so mordsmäßiges Chaos raus und alles, was du dir vorstellen kannst.

Das ist so eine generelle Sache

in der Mathematik. Irgendwann mache ich da auch mal noch einen längeren Diskurs drüber.

Dass man mathematisch gesehen aus sehr

einfachen Regeln, wo man denkt, ja, die

sind einfach genug, um sie im Kopf auszuführen,

Dinge

produzieren kann, die völlig

unabsehbar sind und völlig überraschend

auch, weil sie eben nicht mehr

sich an die Regeln halten, sondern weil sie dann irgendwelche

chaotischen Sachen produzieren und

das ist was

sehr Erschreckendes und das ist

aber auch gleichzeitig was sehr Schönes in der Mathematik,

weil man da eben Dinge finden kann,

die einen völlig überraschen, auch aus den

einfachsten Bausteinen raus.

Also, um das nochmal so zusammenzufassen,

Du hast gerade sich darüber beschwert, dass

die Wahrscheinlichkeitsverteilung

des Auftretens von einer Nachkommastelle

von Pi in der Gesamtsumme aller Nachkommastellen

von Pi, die bekannt sind,

nicht bekannt sind.

Also die kannst du ja nicht kennen.

Aber man weiß,

es könnte ja sein, dass irgendwann keine Neunen mehr

vorkommen, einfach gar keine mehr.

Ist das normalerweise so?

Nee, ist eben nicht normalerweise so.

Aber es könnte sein, wir können es nicht ausschließen.

Das ist die Sache, was der Jochen sagt, keine Ahnung

Ja

Und das ist überraschend, dass

man da so gar keine Ahnung hat, weil man denkt so

naja, das müsste man doch jetzt irgendwie, wenn man sich

irgendwie etwas an, wenn man die Regel wie Pi entwickelt

wird, hinschreibt und eine Funktion wie Pi ausrechnet

das ist wirklich so ein Verzeilen

muss man diese Zeilen nur ganz, ganz

lange und genau angucken und dann muss

einem doch klar sein, okay

da irgendwie, ne, neun, die kommen

genauso häufig vor wie alle anderen auch

Oder zumindest kommt immer mal wieder

einen neuen vor. Das ist ja schon eine Aussage,

die sehr schwer zu treffen ist.

Ja, aber das ist doch im Endeffekt, reduziert sich das

darunter auf das Halting-Problem, oder? Also,

wenn du das lösen kannst, dann kannst du auch das Halting-Problem

lösen. Was ist das Halting-Problem und was ist das Tau-Halbe?

Tau-Halbe

ist Pi.

Das gab es vor einer Weile mal, das Tau-Manifest,

wo jemand

behauptet hat, Pi ist eigentlich die falsche

transzendente Zahl.

Die richtige transzendente Zahl ist eigentlich Tau

und das ist

zweimal Pi, weil

dann ganz viele so quadratische Formen eben

einen Faktor 2 verlieren, der

diese Formen einheitlicher macht.

Es gibt auch ein Gegenmanifest

gegen dieses Tau-Manifest,

das quasi

das Gegenteil behauptet und sagt, das ist alles

Quatsch, weil es gibt genauso viele Dinge, die

mit Pi schöner aussehen als mit Tau.

Deshalb ist es nur ein Witz unter

Mathematikern, wo man Leute leicht

auf die Palme bringen kann.

Dann aber einfach nochmal kurz

die ganze Unbelegung. Was ist denn Pi?

Pi ist das Verhältnis zwischen dem Radius eines Kreises und der Fläche des Kreises.

Das heißt, wenn ich einen Kreis mit einem Radius 1 habe, dann hat er die Fläche Pi.

Und bei den meisten geometrischen Figuren ist es so, dass die Fläche sich relativ leicht berechnet.

Also wenn ich ein Quadrat habe und das hat Seitenlänge 1, dann hat es die Fläche 1.

und wenn ich

ein Dreieck habe, dann hat es die Fläche

1,5 mal 1.

Dann gibt es irgendwelche ganz leichten Formeln.

Beim Kreis ist es leider anders.

Da kommt eben die Zahl Pi raus

und die Zahl Pi ist eine transzendente Zahl.

Das heißt, die ist eine

nicht-rationale Zahl. Es gibt keinen Bruch,

der Pi

korrekt darstellen kann.

Es ist auch eine transzendente Zahl,

das heißt, die ist nicht algebraisch.

Das heißt, es gibt auch keinen Polynom,

was Pi als Lösung hat

und das macht es zu einer ganz besonderen Zahl

weil die Zahlen, die man normalerweise so kennt

Wurzel 2 und Wurzel 3 und Wurzel 5

und Wurzel 7 und

2 mal Wurzel 5 halbe

und so weiter, das sind alles algebraische

Zahlen, das heißt die sind Lösung von

irgendeinem Polynom und die haben dann eben diese

Eigenschaft, dass ich die in dieses Polynom

einsetzen kann und dann kommt 0 raus

Das geht mit Pi nicht

Es gibt für Pi kein Polynom

was Pi als Lösung hat

und deshalb ist es eine ganz besondere Zahl.

Nee, es gibt keins. Gibt es nicht? Also ist bewiesen, dass es nicht gibt?

Ja, weil es transzendent ist.

Und tatsächlich der Beweis, dass Pi

transzendent ist, ist eine sehr schwierige Sache.

Ist auch noch gar

nicht ungeheuer lange her.

Aber das

Ergebnis ist eben sehr wichtig, weil

das eine Klasse von Zahlen ist, von denen es

wesentlich

mehr gibt als von anderen Zahlen,

die für uns aber aus unserem menschlichen Verständnis her

sehr schwer erreichbar sind, weil wir eben

Brüche gewohnt sind und Wurzeln von

irgendwas, also

algebraische Zahlen. Das sind aber tatsächlich

so auf eine gewisse Art und Weise

die wenigsten reellen Zahlen.

Es ist eben

eins von diesen bekannten Beispielen

für eine Zahl, die sich anders verhält, als

man denkt. Und deshalb ist

sie in der Mathematik sehr wichtig, weil sie eben

eine transzendente

Zahl ist. Es gibt

noch ähnliche Zahlen, es gibt noch E.

Die Euler'sche Zahl?

Die Euler'sche Zahl, genau, und die hat nicht ganz so eine einfache Erklärung.

Sehr, sehr gut, Dominik.

Ja!

Die hat nicht ganz so einfache Eigenschaften, die ist nicht ganz so einfach zu erklären,

aber ist auch transzendent, ist auch, man weiß auch nicht, ob sie normal ist,

man weiß auch da die Verteilung der Sachen alle nicht.

Das heißt, diese Zahlen, die sind sehr, sehr schwer in den Griff zu kriegen,

obwohl es eigentlich sehr viele davon gibt.

und ja, das ist halt leider so.

Ja, und genau, also in gewisser Weise

haben die jetzt auch was mit eben

diesen ganzen theoretischen Informatikgeschichten

zu tun, weil sie sozusagen in gewisser

Weise

berechnungstechnisch

irreduzierbar sind, sozusagen.

Also man kann halt nicht,

eben, man muss es halt...

Man muss sie tatsächlich ausrechnen,

sonst kriegt man sie

nicht in den Griff. Und das Problem ist, das ist halt

teuer. Die auszurechnen, da muss man halt...

Ja, das ist ja auch so ein bisschen ein Sport,

dass die meiste

Anzahl Stellen von Pi ausgerechnet ist.

Ja, gab es sonst irgendwie wieder die Nachricht, dass da

die 60 Millionen Stellen oder weiß ich nicht

oder noch mehr, ich weiß gar nicht genau, wie viele...

Genau, also da kommt man dann halt wirklich sehr schnell in solche

Bereiche rein, wo es dann gar nicht mehr so sehr

um Prozessorleistung geht und gar nicht so sehr um

Smarthand geht, sondern da kriegst du dann so richtig die

Big Data Probleme. Wie schaffst du das auf einer Zahl

zu operieren, die 60 Milliarden Stellen?

Ich habe mich mal kennengelernt, der hat sich als Hobby

Aufgabe gemacht, Nachkommastellen von Pi

auswendig zu lehren, hat glaube ich die ersten 250

auch sagen können.

Okay, das ist schon mal nicht so schlecht. Ja, wir haben doch alle so einen Freund,

oder?

Ja,

es gibt auch irgendwie die Gesellschaft der

Freunde von Pi, glaube ich, und da muss man

irgendwie die ersten 100 Stellen auswendig können oder so,

damit man aufgenommen werden kann.

Vielleicht nochmal 142 von NMI,

geht das weiter?

Ja, 3,1,

das ist schon ungefähr richtig.

Wie du sagst, da gibt es auch so interessante Fälle, wo dann in irgendeinem Cut-Programm oder so

Das ist eine der bösesten logischen Bomben, von denen ich bisher so gehört habe

Dass jemand da den Wert von Pi irgendwie subtil verändert hat

So eher sechste, siebte Nachkommastelle oder sowas

Und dann waren halt alle Baupläne der letzten zehn Jahre alle falsch

Sehr schön

Kann man 3,12 sagen oder ist das auch immer falsch?

3,1415

ist so die

Standardweise, aber es ist eigentlich falsch, weil es geht ja mit

9 weiter.

Wenn man Pi

ich glaube auf 15 Stellen genau hat, dann

reicht es schon für alle physikalischen Sachen aus, weil

es dann irgendwie schon im Nanometerbereich ist und

so genau kannst du halt nicht mehr.

Und 3,142 ist zu grob noch

für sowas?

Ja, da hast du halt, wenn du

einen Kreis machst, der 10 Meter im Durchmesser

hat, hast du halt eine Abweichung

von einem Prozent. Also das ist dann schon

eine ganze Menge.

Jede

Programmiersprache hat eine konstante

eingebaut, die Pi heißt, Python übrigens

auch, math.py

und die hat

mehr Stellen, als man je in seinem

Leben brauchen wird.

Deshalb, völlig ausreichend.

Du hast gerade einen Bogen zu Python

gesagt, ich bin begeistert. Ja, wunderbar, oder?

Ja, sollten wir vielleicht irgendwie mal zurückkommen.

Das wird wieder so völlig unvorhergesehen, aber ich finde das eigentlich ganz interessant.

Das sollte doch heute eine sehr interessante Episode sein, oder?

Ja, da bist du die Leute halt durch.

Wenn man in die Möhre ran will, muss man auch ab und zu mal, keine Ahnung.

Man muss ja erst ausgraben, die Möhre.

Ja, rotten.

Gibt es noch was an News?

Ja, mit einem News, ich weiß nicht genau, ist irgendwas Interessantes passiert?

Django ist jetzt gerade die Prerelease-Kandidatin.

4.0 ist der

Pre-Release-Aufkommen.

Das hatten wir schon.

Ja, das letzte Mal hatten wir Alpha.

Ansonsten weiß ich nicht, gibt es eigentlich nichts.

Python 3.10 ist immer noch aktuell und immer noch

cool. Ja, meine letzte Folge hieß Python 3.10,

Jochen. Ja, gut.

Dann ist es trotzdem, ich wiederhole mich,

es ist immer noch aktuell und immer noch cool.

Ja.

Ja.

Es gab ganz lette

Artikel, einmal so über Python

im Bankenumfeld gab es einen, der

mit dem Bank-Python.

Großartig.

Wie, was?

Es gibt wohl eine Variante von Python,

die bei großen amerikanischen Banken eingesetzt wird

und die hat gewisse spannende Eigenschaften,

sagen wir mal so.

Wie heißt die?

Sie ist beschrieben als ein Fork des kompletten Bank-Python.

Bank-Python, jetzt habe ich es auf mich an.

Bank-Python.

Ja, okay.

Großartig.

Ich habe diesen Artikel gelesen und ich fand den super.

Ja, ich auch.

Und da sind auch so ein paar Ideen drin,

wo ich mir denke, ja,

da könnte man versuchen, sich eine Scheibe abzuschneiden.

An Oral History of Bank Python.

Genau.

L. Peterson.

Es sind auch

ganz viele Sachen drin, wo man sich denkt, naja, gut,

okay, gut, die sind halt in dem Jahr, in dem sie

den Fork gemacht haben, stehen geblieben und das war

vermutlich 1994 und

das ist jetzt halt so.

Aber es gibt

auch ein paar Sachen, die eigentlich sehr cool sind.

Also dieser globale State und dieses

globale Deployment und der Code

ist in der Datenbank und du kannst alles anfassen

und...

Barbara.

...sind schon viele Dinge, die man sich mal überlegen könnte.

Ja.

Jochen, den hast du vermutlich in meinen Weaknots gefunden, oder?

Ja, genau.

Ein bisschen Werbung machen für eigene Sachen.

Ja, richtig, genau.

Ja, ich hänge mit meinen Weaknots wieder total hinterher.

Ich muss da unbedingt was machen, aber ich habe irgendwie

keine Zeit, das ist schrecklich.

Das muss Teil des Prozesses werden.

Ja.

Das muss eine Gewohnheit werden.

Hast du hier nichts zu tun, Johannes?

Ich habe genügend zu tun, aber ich habe immer noch genügend Freizeit, dass ich Reddit lesen kann.

Und wenn ich statt Reddit Weaknotes schreibe, dann ist das doch ein Gewinn für uns alle.

Ja, das stimmt.

Ja, so viel Freizeit habe ich leider nicht.

Warte mal, Dominik, haben wir nicht erst Montagabend von 20 bis 24 Uhr Computerspiele gespielt?

Ist das Freizeit?

Nein, das ist Socializing.

Und es war erst um 20.36 Uhr haben wir angefangen.

Oh, ja gut, okay, dann.

Ja, und das, was wir lange gespielt haben, hat mich natürlich

nächsten Morgen noch fast gekostet.

Das ist ja auch klar.

Wir haben übrigens gespielt Max

Mechanized Assault and Exploration.

Okay.

Das ist ein Spiel, das kam das erste Mal,

ich weiß nicht, bei 98 raus.

Und so sieht's auch aus.

Es ist trotzdem

super. Es gibt eine, ja, ein MaxR.

Das ist eine Charakterversion. Wenn man die

Original, Anführungszeichen

Originalvideos und Sprites und sowas noch hat.

Das sieht gar nicht so schlecht aus, finde ich.

Naja, weil das Interface, also das ist

oft so, diese alten Sachen haben

oft gute Ideen, aber schlechte Interfaces.

Und das RTS ist eine unheimliche Komplexität.

Das ist aus der 96 schon, ehrlich.

So alt.

Fast so alt wie ich.

Wir haben es geliebt. Ja, und wir spielen das auch übrigens noch weiter,

allerdings, Johannes.

Ich dachte, wir spielen noch andere alte Spiele.

Ja, das werden wir auch mal schaffen, vielleicht nächstes Jahr.

Na gut, wie war das gleich noch mit Python?

Ja genau, dann machen wir jetzt

Python Dictionaries und so, ne?

Ja

Ihr wolltet heute über Dictionaries sprechen

Ja, richtig verstanden

Also was ist denn ein Python Dictionary?

Ein Wörterbuch, ein

Mapping von Dingen auf andere Dinge

Wie verstehst du denn ein Python Dictionary?

Also ich meine, der Jochen und ich, wir können uns gleich noch

über die Interna unterhalten und da gibt es viele spannende

Dinge, die man da besprechen kann

Aber Dominik, wie siehst du denn ein Python Dictionary?

Was ist denn für dich ein Python-Dict-Driven?

Ja, das ist erstmal ein geschweifte, geklammertes,

definiertes Objekt in Python, also das

kein Z ist, sondern das eine Zuordnung immer macht von

einem Key auf einen Wert

und wo halt der Lookup, also das, wenn man

nachgucken kann, sehr, sehr schnell geht, weil man schön

drauf zugreifen kann und dann gibt es direkt

einen Wert zurück, den es rausschmeißt. Das ist so, dass

wie im Python-Dict man ihn einfach, glaube ich, schnell benutzt.

Okay, Zuordnung von einem Key zu einem Wert.

Das heißt, ich könnte mir jetzt zum Beispiel

zum Key Dominic

deine Telefonnummer speichern.

und dann könntest du das

Phone Numbers nennen oder sowas und dann machst du das

gleich mit Jochen noch und ja. Und könnte ich mir aber nicht auch

deine Adresse dazu merken?

Ja, aber zu was? Also das ist ja

die Frage, wie du das strukturieren möchtest.

Da kann man ja beliebige

Objekte als Value hinterlegen.

Nee, das stimmt nicht. Achso, als Value schon, aber

Key als Key nicht. Nein, aber genau, als Value

hinterlegen, das heißt, da kannst du natürlich dann... Aber immer nur einen, oder?

Value, du kannst

einen Tupel reinpacken.

Okay, ich kann einen Tupel reinpacken, aber ich könnte mir jetzt nicht

2 mal zu dir zwei verschiedene Sachen merken.

Also das müsste ich dann selber machen.

Nee, tatsächlich. Also ein Key muss es

unique in einem.

Weil das ist ja in einem Wörterbuch

nicht so. Und in einem Telefonbuch ist

das auch nicht so.

Das ist so eine

Sache, die immer... Ich mache gelegentlich Python-Schulungen.

Übrigens im Dezember wieder. Naja, aber wahrscheinlich

ist dann so, dass wenn du das Lookup machst und dann Dominik

nachguckst und dann gibt es verschiedene Dominiks, dann hast du erst eine Liste

von Dominiks, die du zurückkriegst und in dieser Liste

stehen dann die einzelnen. Ja, aber ich kriege ja

und Jochen unterhalten sich über die Programmiersprache Python

das bekommt, dann ist ja der Zugriff auf ein Einzelmüller genau,

jetzt ist eigentlich nur eine Ebene tiefer.

Was ich da so tiefer drin verstanden habe,

ist, dass du irgendwie halt in den Speicher gemeldet wirst und das deswegen so schnell

ist, weil er dann einfach dann die Speicheradresse

nachschauen kann.

Ja, das ist ja die Magie des Hashtables.

Das Hashtable, das müssen wir auch gleich nochmal erklären,

was da ein Hashtable ist.

Was können denn Keys sein?

Weißt du das, Dominik? Weißt du das auswendig? Das ist total

spannend. Wenn ich den

Jochen frage, da weiß ich, dass der das weiß.

Ja, also ich weiß, was Strings

sein können, was Zupels sein können.

Ich weiß, dass es Integers sein können

Noch was?

Strings auch?

Ja, genau, Strings habe ich ja gesagt

Kann es auch ein Dictionary sein?

Nee

Doch, sind die hashable?

Und eine Liste?

Sind die hashable?

Das war schon eine sehr, sehr gute Frage

Die hashable

Das frage ich nicht, Dominik

Das weiß ich nicht

Die Regel ist

Tatsächlich ganz interessant

Ein Key von einem Dictionary muss etwas sein, was sich nicht verändern kann

Herrschable sind diese Typen alle

aber der Herrsch kann sich verändern

wenn sich das Objekt verändert

und deshalb

gibt es für Dictionary

für Liste gibt es Tuple

ich kann eine Liste nicht als Key verwenden, weil die sich verändern kann

ich kann aber ein Tuple verwenden und ein Tuple ist ja im Wesentlichen nichts anderes als eine Liste die sich nicht ver kann F Dictionaries und f Sets gibt es einen Datentyp der hei FrozenDict und FrozenSet

und das sind im Wesentlichen Dictionaries und Sets,

die sich nicht verändern können. Das heißt, wenn ich ein Set

als Key in einem Dictionary haben möchte, muss ich ein FrozenSet

draus machen. Und das ist auch so ein bisschen der einzige Sinn

für diese beiden Datentypen, dass du eben

ein unveränderliches Dictionary oder ein unveränderliches

Set haben kannst, um sie als

Key in einem Dictionary zu verwenden.

Und das machen wir, weil man ein Lookup haben will nach dem Motto,

wenn das da drin ist, dann gib mir dies.

Ja, oder

halt auch, wenn man sie wieder in ein Set packen möchte,

weil man möchte, dass da Schnittmengen

von Sachen bilden können oder feststellen

können, ob man das schon mal gesehen hat oder so.

Ja, oder die Reihenfolge spielt keine Rolle.

Das ist ja,

als Mathematiker

ist ein Set wie eine Liste ohne Reihenfolge.

und die interessante Reihenfolge

müssen wir uns auch merken, weil OrderedDict und sowas, weil das ja

früher nicht so ging, das glaube ich default ist.

Ja, muss man inzwischen nicht mehr. Früher musste man sich

OrderedDict immer merken, aber inzwischen sind alle Dicts

OrderedDicts, deshalb den Typ

OrderedDict gibt es noch, aber der macht irgendwie gar nichts mehr.

Ja, doch, doch, doch. Der hat noch einen reversed, aber

das ist alles. Ja, doch, der hat, die verhalten sich

unterschiedlich. Also

tatsächlich macht das durchaus Sinn.

Also man muss einfach mal, das ist vielleicht so ein bisschen,

vielleicht sollte man das nicht müssen, aber je nachdem

wie man Dict verhält,

wie sich das Dict verhalten

soll, das man verwendet. Also wenn man zum Beispiel

viele Insatz hat von Keys,

dann ist es besser, OrderDict

zu nehmen statt dem

Default-Ding. Also es gibt da

tatsächlich subtile... Warum, Jochen? Wie wächst das denn?

Wie wächst denn ein Dictionary?

Genau. Ich habe es vorhin nachgeguckt.

Soll ich es euch verraten?

Ja, verraten.

Ich hatte eh mal.

Ein Dictionary fängt an

mit null Buckets.

Wenn du ein leeres Dictionary hast, das ist tatsächlich speziell.

Das hat null Buckets, verbraucht 64 Byte.

Das ist übrigens unterschiedlich zwischen 32 und 64 Bit Maschinen, aber ich glaube, wir sind alle inzwischen auf 64 Bit angewandt.

Sobald ich eins einfüge, hat es acht Buckets.

Buckets sind Speicherplätze, erklären wir gleich noch, weil es eben zu dieser Hashmap gehört.

Und dann verdoppelt es sich jedes Mal, wenn es zwei Drittel voll ist.

Der Speicherbereich wird vorreserviert für alles, was wir reinhaben.

Genau, diese Datenstruktur, die heißt HashMap und die braucht leeren Platz, die kann nicht 100% voll sein und deshalb machen die halt immer eine Verdopplung, Verdopplung ist so eine Wachstumsstrategie, die gut funktioniert, auch bei Resizable Listen, die verdoppeln sich auch, das ist einfach so eine Wachstumsstrategie, die so eine gute Balance ist.

am besten wäre es, glaube ich, wenn man Wurzel 3

hätte als Wachstumsfaktor, das ist 2,3

oder irgendwas, aber dann hast du die ganze Zeit

krumme Zahlen und das ist auch nicht gut.

Ja, stimmt, das ist bei dem

Array-Modul,

bei dem eingebauten, das habe ich

mir mal näher angeguckt aus Gründen

und da ist das auch so,

weil das ist ja auch interessant,

das ist ja quasi sozusagen

wie eine Listefluss halt

statisch gefühlt, quasi, ja,

und man verbraucht tatsächlich nur den Platz,

also für den Integer braucht man halt nur,

je nachdem, das war natürlich bei 64-Bit.

Und da ist es auch so,

da kann man Append sagen hinten

und wenn man da was hinzufügt und

der Bereich der Memory-View innen

drin ist erschöpft,

dann verdoppelt sich das halt auch immer.

Ja, das ist eine klassische Strategie.

Okay, das bedeutet aber halt auch, man darf

sich nicht darüber

im Unklaren sein, so ein Dict-Journal verbraucht

relativ viel Speicherplatz. Wenn ich einen Eintrag

in ein Dict-Journal reintue, dann hat es direkt

240-Byte-Hauptspeicher verbraucht.

Das ist nicht ganz ohne

Wenn ich 6 Einträge

reintue, hat es direkt 480 Byte

verbraucht

Also es verbraucht relativ

viel Speicherplatz

Es geht hier nicht um Effizienz, sondern es geht um

Schnelligkeit

Und diese Schnelligkeit, die hat

Dominik schon angesprochen, es ist sehr schnell

Das heißt, es ist O von 1

Jeder Zugriff dauert immer gleich

lang, amortisiert

amortisiert über die Verdopplungen

weil wenn ich nämlich ein Dictionary habe, was sehr viele Einträge hat

und das verdoppelt sich dann, dann muss dieses Dictionary

angepasst werden

und eventuell verschoben werden

dann

kann es schon sein, dass es eine Weile dauert

aber amortisiert ist es auch von 1

jeder Zugriff, das heißt jeder Zugriff dauert

im Schnitt gleich schnell

also amortisiert bedeutet für Dictionary der gleichen

Länge?

Nee, das bedeutet im Schnitt

im Durchschnitt bedeutet das

jeder Zugriff braucht ungefähr gleich lang

und das ist eine konstante Zahl.

Es gibt einzelne, die dauern ein bisschen länger.

Ich habe diesen Worttransfer von amortisiert auf dem Schnitt hinbekommen.

Wenn du eine große Anzahl

Zugriffe machst, dann

ist die

Dauer

so, als ob du eine konstante

Okay, genau, weil das Umbauen quasi

Grenzwert Null hat.

Das Umbauen passiert selten genug.

Genau, dass es Grenzwert Null hat.

Deswegen wird es amortisiert.

Okay.

Also O von 1. Also O von 1 bedeutet, es ist kein Problem.

Genau, O von 1. Wir O von 1 schreiben.

Also wenn ich ein Element einfüge, dann dauert es O von 1.

Und wenn ich ein Element rauslese, dauert es auch O von 1.

Und beim Lesen ist es immer O von 1.

Also das ist nicht nur amortisiertes O von 1, sondern das ist O von 1.

Also das heißt tatsächlich, um nochmal einhören,

das so ein bisschen näher zu bringen,

dieser Zeitnotation, Big O, noch nicht so viel anfangen.

O von 1 bedeutet, es dauert quasi keine Zeit, das zu tun.

Doch, doch.

Es dauert immer gleich lang.

Es ändert sich mit der Menge.

der, also normalerweise, wenn du jetzt sagen,

O von 1 im Vergleich zu O von N

ist jetzt, bedeutet

das sozusagen, wenn deine

Eingabedatenmenge

halt nicht

N ist, dann wenn du eine Hashmap

hast, dann ist es halt immer noch O von, ist immer noch konstant.

Genau, aber das wäre... Aber bei was

andere, bei einer Liste ist es halt O von N, wenn du

darauf zugreifen willst, weil du musst ja alle Dinge angucken,

ob es das jetzt ist, was du haben wolltest oder nicht.

Aber O von 1 bedeutet halt, ich kann halt nichts

machen.

Also es ist halt so

und das ändert halt, genau, das heißt

also auch egal ob kleine oder große Datenmengen,

völlig wurscht, was da passiert und das heißt

der steht quasi in meiner Berechnung, ob ich da irgendwas

Algorithmus verbessern kann, zu vernachlässigen, weil das keine Rolle spielt,

ob das, das muss halt einfach so.

Ja, genau.

Und das ist was ganz witziges,

ich hatte mal

in der Python-Schulung einen Teilnehmer,

der da auch gut mitgemacht hat

und der war empört darüber,

das ist unmöglich, das kann gar nicht gehen,

das kann gar nicht sein.

Und dann haben wir tatsächlich einen kleinen Benchmark,

geschrieben und haben das einfach mal ausprobiert.

Und das ist eine sehr schöne Übung.

Das ist eine sehr schöne Sache, einfach mal

auszuprobieren, wie sich diese

Laufzeiten verhalten. Wie lange es dauert,

1000 Einträge einzufügen und

10.000 Einträge einzufügen und 100.000

Einträge einzufügen und die dann auch wieder rauszulesen

im Vergleich zu

einer Liste.

Also du hast einfach quasi die Keys

mit Brackets

dann gesetzt in einer Schleife oder was?

Genau. Und habe einfach

die Zahlen von 1.000 bis 10.000 als

Key und als Value, das spielt ja keine Rolle, wenn wir nur die Größe wissen wollen. Das ist dann ein sehr

unnützes Dictionary, weil das halt einfach, wie man sagt, zum Key 1 gehört

der Wert 1 und zum Key 10 gehört der Wert 10.

Aber wenn es nur ums Benchmarken geht, dann ist das eine einfache Sache.

Und bei einer Liste genauso, einfach mal eine Liste aus zwei Tupeln

zusammengebaut. Und dann in dieser Liste einen bestimmten

Eintrag suchen, ist halt O von N, weil durch diese Liste

von vorne bis hinten durchgegangen werden muss.

Und wenn ich jetzt den Eintrag 100 suche,

dann muss ich halt das erste Element angucken und fragen,

ist das 1? Nein.

Und das zweite Element, ist das 1? Nein.

Und das muss ich dann 99 Mal

machen. Beim 100. sage ich, ist das Element 100?

Und dann sage ich ja

und dann bin ich fertig. Bei einem Dictionary,

Hashmap, wir sprechen gleich, wie das

funktioniert. Im Moment Magie.

Dann

passieren halt 10 Rechenschritte

und dann steht da, okay, du hast

jetzt so 100, hast du dir 100 gemerkt.

und es spielt keine Rolle, ob das Dictionary

einen Eintrag hat, nämlich nur diese 100

oder ob es eine Million Einträge hat, das ist

immer gleich schnell. Genau, aber was

jetzt da interessant ist, hat zwei Dinge, also erstens

wie man dann, also das ist eigentlich ein falscher Datentyp,

aber wie man dann in der Liste das vielleicht

schneller suchen könnte, weil also theoretisch

könntest du ja in der Liste quasi auch daraus eine

Hashtable bauen, irgendwie aus allen Einträgen dieser Liste

einfach da nachgucken, wenn die Hashtables

sind, diese Datentypen oder sowas, ja genau

und dann halt überlegen sich irgendwie den Algorithmus,

wie man relativ schnell die Dinge in dieser Liste findet,

ohne, dass man halt über die ganze Liste

iterieren muss. Ja, aber da brauchst du eine andere

Datenstruktur. Wenn du nur die Liste hast, dann muss

die Liste an sich garantiert

dir das nicht. Die garantiert dir nur, dass es Elemente

in einer Abfolge gibt. Die nächste Frage wäre jetzt, wie halt

in der Stickt, was ja auch im Prinzip

eine Liste von Keys ist, jetzt erstmal so

in der Syntax, wie das dann in den Speicher

so reinkommt, dass man diesen Lookup machen

kann, dass man halt quasi

aus dem Wert des Keys

eine Speicheradresse bekommt quasi.

Ich möchte noch dazu sagen,

Ich möchte noch dazu sagen, du hast jetzt gesagt, das ist eine Liste von Keys, dem stimme ich so nicht ganz zu. Es gibt nämlich da drei Ansichten drauf. Es gibt die Keys, das ist ein Set, das ist eine Menge, die hat auch keine Reihenfolge.

schon, aber

früher nicht

also hat eine Reihenfolge

ja, aber es ist ein Set, weil

im Sinne von

die Reihenfolge

ist nicht

die Reihenfolge, die reingeschrieben worden sind

ja, das ist die Reihenfolge

die jetzt halt

irgendwann dazukommen sind, aber

wenn wir ein Dict von Python 3.4 nehmen, dann hat es

keine Reihenfolge

also in Python 3.5 kam ein Ordered Dict

Ne, also ein Ordered Stick gab es schon immer, aber

dass das sortiert ist, das kam in

3.6 dazu, wurde aber noch nicht garantiert

und ab 3.7

ist es halt auch garantiert, dass es so bleibt

Also in 3.6 war es ein

Implementierungsdetail und in 3.7 gehört es

zur Spezifikation

Aber wenn man sich so

ein ursprüngliches Stick mal anschaut

dann sind die Keys eigentlich ein Set

Die haben keine Reihenfolge

in dem Sinne

und die können auch keine Duplikate

enthalten. Und das ist genau das, was eine Menge ausmacht.

Also quasi ein Set of Sorted Set.

Ja, wobei die Sortierung

die

Reihenfolge des

Einfügens ist. Dann gibt es

die Values. Das ist auch ein View

auf diese Daten, die in dem

Diktator drin sind. Das sind halt die Werte, die da gespeichert sind.

Das ist im Wesentlichen eine Liste.

Die Liste der Werte. Und dann

gibt es noch die Items.

das ist eine Menge aus Tupeln, die jeweils Key und Value enthalten

und für mich sind die Items so ein bisschen das, was das Dictionary ausmacht

das ist das, was da drin ist

also damit kann man ja quasi auch über so ein Dictionary etablieren oder sowas

man kann es einfach als Methode dot notated aufrufen

und dann kannst du quasi for Key Value in Dict.Items

genau, for Key Value in Dict.Items

das ist so ein Muster, das sieht man ganz häufig, weil man da einfach durch

quasi durch das gesamte Dictionary durchgeht

Man könnte auch

sagen for key in dictionary

und dann sich jeweils

den Value holen, weil es ist ja

O von 1

Das kostet ja so gesehen

algorithmisch nichts

Das kostet ausführungsweise schon was

Wenn du eine Vorschleife machst über alle

dann ist das halt schon O von N

sozusagen

Nur im Einzelfall halt nicht

Aber die Value nochmal rauszuholen, wenn du die schon hast

Genau, also die

O-Notation von for key value

in DictItems

irgendwas tun und

for key in Dictionary

und dann den Value als Dict von

Key holen, ist identisch.

Aber die Laufzeiteigenschaften

sind natürlich für den zweiten Fall schlechter,

weil ich dann jedes Mal nochmal in das Dictionary

rein muss. Natürlich nur für einen

konstanten Faktor.

Aber konstante Faktoren.

Ja, konstante Faktoren.

Also wenn etwas nur

zehnmal langsamer ist, das ist auch ein konstanter

Faktor.

Macht schon einen Unterschied.

Ist schon ein Unterschied, ja.

Ja.

Genau.

Wie kann man denn Dicks bauen? Wisst ihr das?

Ich habe vorhin einen ganz coolen Trick gelernt.

Es gibt ja mehrere Wege,

Dictionaries zu bauen.

Ja, was meinte du?

Syntaxmäßig, jetzt gescheuchte Kammer oder

Dicht von... Wie ich ein Dictionary erzeuge.

Also du kannst es natürlich einmal machen als Dictionary

Contraintion, indem du sagst,

gescheuchte Kammer, Key,

Value, oder du machst

hat einfach die Definition einfach in den eckigen

Kammern, schreibst dann den Key und den Value hinterher

oder du schreibst eine Liste von

Keys und Values mit

Gleichzeichen dahinter und machst dann Dict raus.

Also Dict of.

Ja genau, das ist der normale, also das ist der

Konstruktoransatz.

Du kannst die Keys auch in der Schleife

einfach hinzufügen.

Du kannst auch irgendwie, keine Ahnung,

Tupel-Unpacking oder sowas,

die ganzen Adrekte reingieben

mit so Sternchen, Sternchen, Quarks und Tacks.

bzw. wenn du eine Sequenz von Tupeln reingibst, von zwei Tupeln, dann nimmt er die automatisch.

Eine Methode, die ich gerne verwende, ist dict.fromKeys.

Was macht das?

Naja, du gibst halt eine Liste von Keys und dann halt vielleicht einen Default-Wert oder so

und dann erzeugt er das Ding dann raus mit diesem einen Factory-Methoden-Aufruf von dem Dict.

Default-Dict gibt es noch irgendwie?

Das ist schon etwas anderes.

Müssen wir nachher noch drüber sprechen.

Das ist nämlich auch eine spannende Sache.

Ich möchte noch einmal kurz zu der Comprehension zurückkehren,

weil die ist nämlich was sehr, sehr, sehr Cooles.

Und die ist was, was auch für Leute, die

das nicht kennen, super schwer zu verstehen ist.

Diese Dictionary Comprehension ist eine der

coolsten Wege, die es gibt,

so ein Dictionary zu bauen, weil es halt im

Wesentlichen diese Schleife, die man dazu

braucht, in das Dictionary reintut.

Also in die Konstruktion

und das ist was

sehr, sehr mächtiges. Die Syntax davon

jetzt hier im Podcast zu besprechen ist vielleicht...

Nee, mach nicht so viel, das muss man sich angucken.

Das muss man sich ansehen, aber das ist auf jeden Fall was, was man

ansehen kann. Ich habe vorhin noch einen

sehr coolen Trick gelernt und das ist DictSip.

Also wenn ich eine Liste von

Keys habe und eine Liste von Values,

dann kann ich die sippen und dann

ein DictSignal draus machen.

Das geht aber nur für gleich lange

Listen, ne?

Sip nimmt auch unterschiedlich lange Listen,

und schneiden dann halt den Rest ab.

Aber das ist, glaube ich, nicht der Sinn der Sache.

Der Sinn der Sache ist, du hast schon die Keys und du hast schon die Values,

aber in zwei Händen und mit Zip kannst du sie

in eine schöne Reihenfolge bringen,

die du schnell...

Einmal Reißverschluss, bitte.

So, wie kann man denn da Sachen wieder rauskriegen?

Dominik, weißt du, ich frage dich jetzt ab.

Ich finde das total gut.

Was meinst du?

Wie komme ich an die Werte wieder dran?

Ja, du kannst einfach...

Wenn ich jetzt ein Telefonbuch habe,

wie kriege ich deine Telefonnummer raus?

Du machst halt zum Beispiel entweder ein Get oder halt mit der

Brackets-Syntax ziehst du die direkt raus.

Bei Get kriegst du den Default-Wert

zurück und du kriegst einen

Error, wenn du

daraus einfach so ein Key zu lesen ist, das es nicht gibt.

Genau, wenn du es mit eckigen Klammern machst, kriegst du

im besten Fall einen Key-Error.

Der heißt tatsächlich Key-Error, also

wenn man das abfangen möchte, ergibt es das.

Genau, also beim Get kannst du halt dann den Default dranhängen.

Es gibt noch zwei andere coole

Attribute, die heißen

Pop und PopItem.

Ja.

Und die sind quasi

destruktiv, sie sind destruktiver Zugriff.

Wenn ich sage,

dictionary.pop.dominic,

dann heißt es,

entferne den Eintrag für Dominic,

aber gib mir den Wert auch noch zurück.

Wie bei einer Liste.

Wie bei einer Liste, genau. Also, ja gut, halt mit diesem

Key-Zugriff. Bei Pop muss ich immer

den Key sagen, bei einer Liste müsste ich den Index

sagen. Genau.

Oder er gibt dir den ersten Wert.

was natürlich beim Dick nicht geht, weil das nur einer ist

genau, das heißt, Dick.pop muss

immer einen Key haben, es gibt da keinen

ersten oder letzten oder wie auch immer

also das kann ich nicht machen, aber es gibt

PopItem

und PopItem

das macht Lifo

LastInFirstOut

das heißt, es gibt dir tatsächlich den

letzten Eintrag, der

hinzugefügt wurde, zurück als Item mit Key und Value

ach, dann braucht man den Key nicht mehr, das ist natürlich

interessant, da kann man bestimmt... als Key und Value

das ist schon sehr cool

Das heißt, du kannst

so eine While-Schleife machen und kannst

dieses Dictionary sozusagen abarbeiten.

Ja. Und hast dann so eine Art

Dictionary-Queue. Und das ist

eine praktische Sache, die ich erst

heute gelesen habe. Ja, sehr schön.

Ja, ne, hab ich auch so noch nicht verwendet, aber

da fallen mir auch direkt viele Sachen zu ein, die man

damit cool machen kann.

Ja, wo man so ein Dictionary

zerlegen kann.

Ja, also es gibt noch

Set Default.

Das ist, ich weiß nicht,

und man weiß, Leute, erzählen sollte das, was die Methode noch gibt.

Das darf man nicht sagen.

Naja, die ist eigentlich nicht gut.

Also die liefert halt auch quasi das

zurück, aber mit einem

Default-Wert, den man dann noch angeben kann,

wenn das nicht existiert.

Ja, stimmt.

Wo ich anfange, das erklärt sich mir schon ein, dass das

vielleicht keine gute Idee ist.

Es ist, glaube ich, besser, da direkt ein Default-Dict zu hören.

Genau, das ist auch die Empfehlung, sollte man halt heutzutage

eher Default-Dict nehmen.

Oder ein Get und dann den Wert setzen.

Wolltest du noch was?

Was ist ein DefaultDict?

Dafür müssen wir erst wissen, was ein DefaultDict ist.

Dann erzähl mir, was ein DefaultDict ist.

Ein DefaultDict ist ein Dictionary,

eine Unterklasse von Dictionaries.

Das keine Keys hat, aber wenn du einen Key abrufen willst,

den es noch nicht gibt, dann gibst du den DefaultWert zurück.

Genau. Du sagst eben,

welchen Standardwert es haben soll und wenn du

einen Key abrufst, den es noch nicht gibt, kriegst du den Standardwert.

Und da gibt es drei

große Varianten davon.

Die erste ist die Lambda-Variante, wo du

eine Funktion reingibst,

die dann diesen Standardwert erzeugt

und das ist sozusagen

die allgemeine, das ist DefaultDict

du musst dem DefaultDict irgendeine sogenannte Factory

geben, damit er diesen Wert erzeugen kann

und da kannst du jede beliebige Funktion reintun

meistens ist das halt irgendeine kleine Lernintervention

aber es gibt schon zwei Funktionen

die du da verwenden kannst, nämlich List und Int

die nützlich sind

also wenn du DefaultDict

Klammer auf, List Klammer zu machst

dann heißt das, das ist ein Dictionary

und wenn du da einen Key abrufst

dann gibt er dir, wenn du noch nichts eingefügt hast

für diesen Key, eine leere Liste zurück

eine neue leere Liste

und genauso

für int, wenn du

ein DefaultDict

int hast, dann kannst du

jeden beliebigen Key abrufen und kriegst 0 zurück

Ja

Du kannst einen Counter

machen, das geht immer auf das

Ja, aber Counter gibt es auch

Da gibt es schon eine Klasse für, ja

Und die ist richtig cool, diese Counter-Klasse, die müssen wir uns auch gleich noch

Okay, wofür würde ich DefaultDict verwenden?

Das klassische

Beispiel ist, wenn man sich so ein Counter baut.

Aber nochmal, wenn du das gleiche, nochmal

auch, das gibt natürlich dann den neuen Wert zurück.

Genau, also wenn du einen Wert in

dieses DefaultDict

reinspeicherst, dann ist es wie ein normales Dictionary.

Also wenn es diesen Key schon gibt,

dann kriegst du das, was da gespeichert wurde. Das kann auch

was anderes sein als ein Int oder eine Liste.

Das heißt, es ist nicht eine Typisierung,

sondern es ist nur so dieser Fallback.

Da ist nochmal noch eine Zwischenfrage,

Kleiner Exkurs, wenn ich jetzt da ein Get mache auf so eine Liste, ja, auf so ein Default-Dict von der Liste

und ich habe dann eine leere Liste in der Hand und ich schreibe in die was rein.

Beim nächsten Mal auf denselben Key kippt ihr mir dann diese Liste, in der was drin ist.

Nee.

Oh.

Warum nicht?

Das wäre das, was Jochen vorher gesagt hätte, das wäre SetDefault.

Ah.

Weil du beim Abrufen entweder den Wert kriegst, der in der Liste, der in dem Dictionary drin ist,

oder den, den die Factory erzeugt.

aber der wird nicht automatisch in dieses

Dictionary abgelegt. Aber das ist doch

bei Listen, haben wir doch das Problem, dass dann das Objekt

der Liste dann es doch schon gibt und dass das

Objekt dieser Liste auf das dann ja... Genau, aber die wird nicht

in das Dictionary abgelegt.

Okay, das heißt, du musst die tatsächlich zuweisen.

Die du nur in der Hand hast und du musst die dann tatsächlich

zuweisen. Wenn du das möchtest,

dass du eine Liste abrufst und die dann bearbeiten kannst,

dann musst du SetDefault machen.

Und SetDefault heißt,

ruf einen Key ab, wenn es den schon gibt, gib mir

das, was da drin ist, ansonsten setze in dem

Dictionary den Wert, den ich dir da als Default angebe und gib ihn mir zurück.

Okay, ja das dachte ich, dass wir das was Default-Dictionary machen würde.

Okay, das heißt, dafür muss ich SetDefault machen.

Genau, dafür musst du das SetDefault machen.

Ja, aber die Funktion SetDefault, also sie ist in mehrerer Hinsicht verwirrend, sie ist

auch verwirrend benannt, wie man es auch gerade wieder sehen konnte.

Und vielleicht sollte man das echt, weil tatsächlich, wenn man so eine Default-Dict macht, ist es

sauberer.

Und ja, genau, was ich noch anmerken wollte zu den Factory-Funktionen, die man übergeben

muss.

also es kann eine Bedingung sein, die einzige

Bedingung ist, sie darf keine Argumente

nehmen. Genau.

Wenn man jetzt so mehrfach

verschachtelte Geschichten baut, das geht,

aber das wird dann auch relativ schnell

relativ unübersichtlich.

Ich habe noch

keine gute Lösung dafür, aber das ist,

das sieht dann komisch aus, aber

ja. Das ist ein bisschen blöd, dass es keine

Argumente sein können.

Also Factory-Striching-Manager gerne mal auf eine

bestimmte Art und Weise initialisieren.

Ja, das muss man ja irgendwie von einer

die Fraud-Tag schon wie alles schon erben und muss das

dann irgendwie schon hinstecken.

Ja, aber da gibt es etwas, also

zumal, wenn man jetzt bei unterschiedlichen

Keys unterschiedliche Sachen machen möchte,

das kann ja manchmal sein, du sagst so,

wenn ich diesen Key habe, okay, dann möchte ich ja gar keine

Liste dazu machen, sondern was ganz anderes oder so

und dann geht das

mit dem Default-Tag ja alles so nicht mehr so richtig,

eben deswegen, weil man kann halt nicht

Argumente angeben, was man dann, also

das geht da nicht mehr,

da gibt es aber auch etwas sehr Cooles, was ich auch erst

in der Vorbereitung. Ich habe ja einfach nochmal geguckt,

zu dieser Episode

habe ich mir nochmal so ein bisschen angeguckt, was habe ich denn an Literatur

zu Dicts? Steht da irgendwas Interessantes

drin? Da habe ich tatsächlich etwas gefunden, was ich noch nicht wusste,

wo ich auch sagen würde, oh cool, dass ich das jetzt

weiß. Und zwar gibt es

Dundamissing

als

sozusagen Spezialmethode,

die man überschreiten kann, wo man

dann den Key bekommt. Das ist quasi der Key Error.

Du kannst den Key Error überschreiben.

Ich mache dann DefaultDict,

mache ich dann eine neue Klasse, die von DefaultDict erbt und überschreibt

dann dann dann Missing und guckt dann mit einem Match-Case-Statement, was da drin ist.

Genau, oder du kannst von Default-Ticket erben, na klar, aber

das musst du dann ja im Grunde nicht mehr, weil wenn du die Methode überschreibst, dann bestimmst du ja selber, was passiert.

Und da kannst du alles machen. Das ging früher übrigens auch nicht.

Ich konnte früher nicht von Dict erben, deshalb gibt es noch eine Klasse, die UserDict heißt.

Achso, das heißt dann, ich mache tatsächlich sowas ähnliches wie UserDict und ich mache

eine neue Klasse auf die erbt einfach von Dict und da überschreibe ich dann nur die Missing-Methode und dann gucke ich halt,

statt dem Key-Error rauszugeben,

dass er dann tatsächlich irgendwas Neues anstellt.

Das würde auch tatsächlich funktionieren, aber

diese Diskussion hatten wir

in dem Python User Group

Düsseldorf Channel auch

vor kurzem, ob es denn okay ist

von Dict zu erben oder wenn man lieber von UserDict

erben soll oder so. Und ich hatte das halt noch

so im Hinterkopf, dass man von UserDict erben soll

und nicht von Dict. Und

tatsächlich habe ich jetzt auch

nochmal nachgeguckt und nee, man soll

von UserDict erben und nicht von Dict.

Also man kann das ja zwar jetzt, aber

Was ist da der Unterschied?

Der entscheidende Unterschied, warum das

unter Umständen einem Probleme machen kann,

ist, dass

bestimmte

Methoden, also Missing

ist jetzt, die funktioniert, die kann man überschreiben,

aber bestimmte andere nicht. Und wenn du dann

auch bestimmte andere Arten,

wenn du da Sachen mitmachst, dann

geht das an den Methoden, die du überschrieben hast,

vorbei. Das heißt, wenn du

von dem Bild entdeckt hast,

und dann überschreibst

halt irgendeine Methode und denkst, ja, müsste doch funktionieren,

dann funktioniert es manchmal halt vielleicht nicht,

weil zum Beispiel, also auch der Konstruktor

davon ist halt so, der schreibt das halt

irgendwie direkt, der geht nicht über die

Set-Item, Get-Item-Geschichten,

die es da halt normalerweise gibt. Das heißt,

dann verhält sich das Ding unter Umständen

unerwartet. Und ja, Laufzeitverhalten

ist auch so ein bisschen anders.

Und, das habe ich jetzt aber auch

wieder vergessen, also es war auch irgendwie, ist eine

wichtige Geschichte, warum das, wenn das

ein Data-Attribut ist und sozusagen die Zugriffe

daher nur delegiert werden.

Das macht auch irgendwie, ich glaube, es kann sogar sein, dass

das der Grund ist, weshalb man SetItem, GetItem

dann überhaupt quasi richtig überschreiben

kann, weil wenn das halt...

Weil es delegiert wird. Ja, genau, genau.

Und daher sollte

man, wenn man das selber, wenn man

erben will und will Sachen überschreiben, dann

lieber UserDict nehmen, statt einfach

von Build enternen. Also UserDict

ist quasi

eine Klasse, die das gleiche Interface hat wie

Dictionary, aber

eben ein Attribut heißt, das heißt

Data

und das ist ein Dictionary und einfach alles

durchrecht an dieses Data.

Und das bedeutet, dass wenn ich von UserDict

ableite, kann ich jede beliebige Methode

überschreiben und die wird dann auch korrekt

aufgerufen, auch Konstruktor und alles mögliche.

Ja, genau.

Ja.

Ja, okay, wusste ich auch nicht. Ich wusste nicht, dass es so Unterschiede gibt.

Ja, es ist immer wieder interessant, auch wenn ich dachte,

also ich meine, das verwendet man ja jeden Tag

und irgendwie schon lange und so und dann ist es so,

kann ja eigentlich nichts Neues mehr.

Aber manchmal so, ja.

Aber das ist was, was man doch relativ selten macht von Dictionary.

Also generell,

Bild-Ins, so Sachen,

fühlt sich immer so ein bisschen komisch an.

Ja, ist nicht so häufig.

Die sind einfach gut genug.

Beziehungsweise, wenn man

eine neue Datastruktur sich schreibt,

dann benutzt man normalerweise eben eine

und leitet nicht direkt

davon ab. So ist meine Erfahrung.

Instanziert die dann irgendwie so mit so einem

Invektor-Pattern oder sowas, dass man die halt dann benutzt?

Genau, dieses Data, dass du halt

und sagt, okay, mein Baum ist eigentlich eine Liste, aber ich habe eine Liste, die das macht.

Ich habe nicht das Interface von Liste geerbt, sondern ich habe halt eine in der Hand, die das macht.

Das ist so meine Erfahrung. Ich weiß nicht, wie ihr das seht.

Doch, doch. Ich sehe das ganz genauso.

Achso, das ist auch noch der eine Grund dafür, warum das mit dem Delegieren eine gute Idee ist,

und Jochen unterhalten sich die Programmiersprache Python Also in einem Kontext wo man sich dann fragt wie man so Dia macht auf dein Objekt und dann sieht man halt einen ganzen Haufen komisches Zeug wo man sich dann so h warum ist das denn alles da drin was man halt einfach so mitbekommt wenn man das wenn man

da direkt erbt.

Also, ja.

Okay, ich frage mich alles.

Wir müssen noch so ein paar Sachen, ich habe jetzt meine

Notizenliste ist leider gerade leer gegangen,

aber

da ist so ein Ladegerät und da ist

ein, das kann man, das kannst du am Telefon anschließen.

Oh, du hast USB-C? Wow.

als Apple-Haushalt USB-C.

Ja, ja, brauchen wir das schon.

Cool.

Es gibt eine Methode in Dictionary,

wo wir gerade über das Dictionary-Interface

sprechen, die ist in 3.9 dazugekommen.

Es gibt eine, in 3.9 hat sich

das Dictionary-Interface verändert.

Und zwar ist der

Pipe-Operator dazugekommen.

Ah, ja, richtig.

Ja, natürlich.

Und das ist sowas, was,

wenn man das braucht, dann ist das

ungeheuer wichtig und wenn man es

nicht braucht, dann ist es so.

Okay, nie gedacht, dass jemand sowas brauchen könnte.

Das ist Dictionary-Vereinigung.

Ja, Unions zwischen von Dicts.

Genau, da gibt es jetzt den Operator dafür.

Früher musste man immer,

jede von uns hat so eine Sammlung von Tricks,

wie man Dictionaries vereinigt.

Ja, das ist ganz einfach mit Stern, Stern

und unter Dictionary und

ja,

und das gibt es jetzt als Operator und auch mit

Pipe gleich, also man kann auch gleich rein

vereinigen, wobei das einfach ein Update

ist meiner Meinung nach, oder?

Oh, das würde ich jetzt ausprobieren, das weiß ich auch nicht, aber es stimmt, ich wusste, dass das passiert ist, ich habe es aber nie verwendet,

seitdem, daher ist es mir jetzt gar nicht mehr bewusst.

Moment, ein Update ist ja Union, ist das exklusiv, ist die Frage, ne?

Es ist immer exklusiv, weil du ja keine Keys verdoppelst.

Ja, aber dann geht das nicht mit dem Update, weil bei Update werden ja nur die Keys geupdatet, die in dem Update enthalten sind.

Nee, ein Punkt Update, ein dictionary.update übernimmt alle Keys und Values aus dem...

dem Eingegebenen. Das überschreibt

alles, was da drin ist. Genau, aber wenn welche

vorher schon drin waren und die dann überschrieben werden,

aber wenn die vorher schon drin wären, die nicht,

nein, aber wenn die vorher schon drin waren

und nicht in dem neuen drin sind, dann sind

die, wie sie vorher waren. Aber wenn du den

Union Operator gleich machst, dann sind sie eben

nicht mehr drin,

weil sie halt nicht in dem Update sind.

Das verstehe ich jetzt nicht.

Okay, du hast zwei einigermaßen

Distributiven. Du hast D1 und D2.

Genau, du hast zwei einigermaßen Distributiven.

Und das sind irgendwie zwei Keys gleich.

Wenn du jetzt mit dem Update machst,

werden die zwei gleichen Keys

in dem ersten Dictionary überschrieben.

Wenn du das, ne, erstes Update,

wenn du aber die

Union machst,

nein, dann sind nur noch die zwei Keys drin.

Nee, das kann ich.

Nee, das wäre ja der

Schnitt nicht zu beantworten.

Achso, stimmt.

Das gibt es nicht. Das gibt es nur bei Set.

Gibt es nicht auf den Schnitt? Das gibt es nur bei Set.

Bei Set gibt es das.

Das ist aber...

Gibt es nicht auch die Intersect?

Z.Intersect. Ne, für Dictionaries gibt es kein Intersect.

Okay, schade eigentlich.

Weil das wäre doch eigentlich sehr logisch, dass das mit dem...

Siehst du, jetzt habe ich den Piper-Properator nicht richtig verstanden.

Es wäre logisch, dass es diese ganzen mathematischen

Operationen alle für Z und Dictionaries haben.

Genau, dass du halt quasi dann nicht nur sagst, du machst halt

einfach irgendwie ein und und oder wie auch immer man das machen will

von dem anderen Dikt und dann hast du die Unions direkt.

Das wäre doch schön syntaxisch.

Ich probiere das mal in der Rappel aus.

Ja, mach mal. Union ist oder

und das ist

einfach die Vereinigung.

so die Keys aus dem einen Dictionary und die Keys aus dem anderen Dictionary.

Ja, okay.

Mit den Werten aus dem jeweils letzten.

Mach mal und und.

Nee, das geht in der, nee, und und geht schon mal gar nicht.

Und und gibt es in Python sowieso nicht?

Gibt es nicht.

Aber und und geht nicht.

Und dann sagt er unsupported operand.

Bit twice geht auch nicht.

Ja, okay.

Also tatsächlich, es geht nur die Vereinigung, ja.

Ja, okay.

Dann ist das gleich wie ein Update.

Wohingegen bei set, wenn man das jetzt so macht.

Bei set gibt es intersect.

Es gibt set.intersect.

Es gibt z.union und es gibt z.

und es gibt z.

Es gibt noch eine dritte, difference.

Symmetric difference oder sowas.

Ja, genau.

Symmetric difference ist ja das eine

plus das andere minus das eine.

Schade, dass ihr Interfekt nicht habt.

Warum hat der das denn nicht? Also bei selben, das bei set geht,

aber bei dix nicht. Das müsste ja irgendwann mal reinkommen.

Die Frage ist, wie sollen denn dann die Values

aussehen?

Bei der Intersection der Keys.

Welche nimmst du denn dann?

Hm.

Jetzt hast du mich.

Eine Liste von beiden wahrscheinlich.

Ja, aber das wäre dann schon sehr unerwartet, oder?

Ich meine, man könnte auch auf die Idee kommen,

es müsste anders sein und dann wundert man sich halt,

was passiert ist.

Also eigentlich müsstest du

den Schnitt über die Keys machen

und dann entscheiden, aus welcher

Quelle du die Value nimmst.

Das ist halt quasi wie beim Update

mit Exclude oder sowas.

Kann man das machen mit Exclude?

Nee.

Auch doof.

Ja, also was mir jetzt wieder anfällt,

es ist irgendwie relativ ähnlich zu dem, was man irgendwie

bei den neuen Sachen hat, wie mit Data Classes oder

PyDentic oder sowas oder

was gibt es denn noch, alles Ethos oder sowas?

Also was diese, ja,

oh, das gibt es auch noch, ja,

Named Tuple. Ja, genau, Named Tuple.

Genau, das ist auch spannend. Warum denn

Named Tuple?

Ja, das ist ein total komischer

Name dafür. Ich weiß auch nicht.

Um dot notated Zugriffe auf

irgendwelche Objekte zu haben für die einzelnen.

Okay, aber dann, also

Was ist denn der Unterschied zwischen einem Dictionary und einer Klasse?

Weil bei einer Klasse habe ich auch Namen drin, Punkt irgendwas und da ist genau ein Wert dazu drin.

Du hast einen Konstruktor und irgendwie noch...

Ja gut, aber das ist ja...

Der Konstruktor ist nur eine Konvention.

Du kannst auch deine Sachen anders konstruieren, genau.

Also ich würde sagen, es gibt keinen großen Unterschied.

Tatsächlich ist es eine sehr ähnliche Geschichte und ich glaube, es ist ja auch so...

Alles die Interpretierung ist tatsächlich auch so.

Genau, also in Python-Objekte, das sind halt Dicts, was ihre Struktur angeht.

Mit ein kleines bisschen Syntax dazu.

Genau.

Tatsächlich ist es sogar, also ich weiß nicht, ob das bekannt ist, unter uns dreien sicherlich, aber unter den Hörern vielleicht nicht.

Jede Instanz einer Klasse ist im Wesentlichen ein Dictionary.

Also das hat ein Attribut, das heißt unterstrich, unterstrich, Dict, unterstrich, unterstrich.

und da stehen die Dinge drin, die

die Values in dieser Instanz sind.

Also eine Instanz ist immer ein Dictionary

in Python.

Das ist irgendwie

komisch oder seltsam.

Gerade wenn man von anderen Programmiersprachen

kommt, weil in anderen Programmiersprachen ist es ja nicht so.

Weiß ich nicht. Also ich würde gerade

sagen, bei dem, was üblicherweise

so als Skriptsprache

qualifiziert wird,

da ist das auch, also bei JavaScript,

da heißen die Dinger sogar Object.

Vielleicht ist das das entscheidende Merkmal

in der Skriptsprache

Also bei

oder bei Perl war das auf jeden Fall auch so

da waren auch, also ich meine

das hat ja keine offizielle

Bei dynamischen Klassen und dynamischen Instanzen geht es ja

quasi nicht anders, du musst ja quasi diese Zuordnung

haben von Attributname zu

irgendeinem Wert

Bei kompilierten Sprachen ist das ja anders

Ne, da ist es anders, genau

Bei kompilierten Sprachen musst du es nur während der Kompilierungszeit machen

und dann kannst du sagen, okay, das Attribut

mit dem Namen x ist halt Feld Nummer 2.

Ja. Man kann das in Python

auch machen, quasi. Man kann das halt

festdengeln, ohne dass das halt dann

noch so dynamisch...

Ja, man kann halt die Attribute

in einem Spezialattribut

Thunder Slots angeben und dann

sind die halt da fix.

Die kann man dann aber auch nicht mehr dynamisch zuweisen.

Das ist aber auch nur

Konvention, oder? Ne, ne, das ist dann tatsächlich

schneller.

Wenn ich ein Slot-Tick mache, dann kann ich das trotzdem

zusätzlich machen.

nochmal dann sein Slot.

Achso, Moment, kann ich dann trotzdem

dynamisch zuweisen? Ich weiß es nicht, meine, das geht dann nicht mehr.

Das muss ich ausprobieren.

Jochen macht seinen Editor an.

Einer von uns beide ist gleich falsch.

Oder eben NameTupel. NameTupel ist

genauso, nur halt

schneller.

Weil der eben diesen Aufruf nicht über ein Dictionary macht,

sondern über eine lineare Liste, weil die Annahme ist,

dass du nicht so viele

davon hast. Oder vielleicht

ist das so eine Hybrid-Sache.

So ein bisschen ist das Dictionary ja der Kern von Python.

Es gibt ja so eine Liste...

Moment, ich habe es gerade ausprobiert.

Nein, wenn man halt Slots definiert hat

und dann was anderes dynamisch zuweisen möchte,

kriegt man Exception, Attribute, Error.

Also wenn man Slots macht, dann ist es kein

richtiges Dictionary, sondern nur...

Also es ist halt auch so ein Trick, damit kann man halt, wenn man viele

Objekte hat oder so, damit kann man die Objekte selber

schneller machen und sie brauchen viel weniger Speicher.

Jetzt muss man noch erklären.

Aber Nailtubel macht das genauso, oder Jochen?

jetzt ist auch schneller als

eine allgemeine Klasse.

Ja, ja, klar. Name-Tupel macht das genauso

und darüber funktioniert, ich glaube,

dann intern kann es sogar sein, dass die interne Datenstruktur

Tupel ist und sich dann sozusagen

nur eine Zuordnung gemerkt wird von

Index auf irgendeinen Namen.

Aber das würde ja schon nichts bringen,

sondern das würde ja dann Hashtag den gleichen

aufrufen, sondern das muss eine andere Struktur

sein, das ist keine Hashmap.

Ja, ja, ja, nee, das ist irgendwas anderes, keine Ahnung.

Was auch immer.

Man darf nicht vergessen, wenn ich eine kleine

Menge an

Keys hat, dann ist

so eine Art Listenzuweisung, also ich

merke mir einfach, die Keys

in einer Liste und gehe die Liste linear durch,

das kann schneller sein als

so ein Hashmap-Zugriff.

Für kleine Werte von n.

Für kleine Werte von n ist o von n

kleiner als o von 1. Kann sein.

Kann gut sein, ja. Und

das ist, glaube ich, der Trick von Slots und der Trick von Name-Tupel,

dass die halt sagen, okay, wir

machen keine allgemeine Zuweisung, sondern wir

sagen, aha, wir haben ja nur drei

benannte Attribute, dann ist es besser, die in einer Liste zu haben.

Okay,

Slots bitte noch einmal explizit erklären,

weil das kommt gerade zum ersten Mal vor.

Slots und Name-Tupel.

Wie gesagt,

darüber weiß ich jetzt gar nicht.

Ich dachte, wir machen was.

Erklär es mal als Name-Tupel.

Was ist denn ein Name-Tupel?

Ich wollte gerade nach Slots fragen.

Ja, das kommt gleich.

Naja, da definierst du sozusagen

ein Objekt dadurch, dass du am Anfang

Du gehst also, glaube ich, wie ist der Aufruf?

Name-Truppel, dann sagt man irgendwie

einen Namen dafür und dann sagt man die

Attribute, die das haben kann

und dann

Und das verhält sich dann aber wie eine Klasse. Ja, genau.

Und dann kann man mit Punkt drauf zugreifen.

Aber nur mit diesen, die ich da angegeben habe.

Also wenn ich ein Name-Truppel habe, das heißt

Fuba

Keine Ahnung, das heißt Fuba und das hat die Attribute

A, B und C

Dann kann ich ein Fuba.a

machen und Fuba.b und Fuba.c

und kriege die entsprechenden, das verhält sich

dann wie ein Dictionary für diese drei

Keys. Aber Dict kann ich ja nicht mit

Dot machen, muss ja mit den Key-Ketten. Genau.

Also das ist wie eine Klasse.

Also das ist so

ein Ding, das mache ich häufig, dass ich

einfach eine Klasse mache, die heißt DataHolder

und die hat keine Attribute,

weil dann kann ich nämlich mit Punkt irgendwas.

Wenn wir jetzt gerade schon bei NamedTouples noch sind, da gibt es übrigens

auch eine kleine Neuerung, weil früher gab es ja immer vom Collections

NamedTouple, man musste NamedTouple off machen und

jetzt gibt es aber auch das Typing NamedTouple und Typing

NamedTouple ist nur ein bisschen eleganter, weil dann kannst du einfach

das wie eine Klasse schreiben.

und darunter die Attribute.

Ich würde NameTupel gar nicht so

prominent, weil auch das

ist, glaube ich, nicht mehr so wirklich

empfohlen und nicht mehr so richtig aktuell.

Das gibt es halt noch.

Aber eigentlich, was man

darunter stellt...

Wenn man NameTupel verstanden hat,

dann ist Slots leicht zu erklären, weil Slots ist

nämlich eine andere Syntax für die

gleiche Funktionalität.

Du sagst, welche

Attribute eine Klasse haben darf und

dann hat es nur genau diese Attribute.

Das heißt, okay, also in Slots ist eine Dann-Dann-Methode,

die in einer Klasse drinstehen kann.

Nicht eine Methode, nein, nein, das ist ein Attribut.

Das ist ein Attribut, ah, okay, das ist ein Attribut.

Und das ist eine Liste von Namen rein.

Und das ist eine Liste und in der Liste stehen quasi

die Strings drin von den

Namen, die als Attribut

einer Klasse, die als Methode oder Attribut

erlaubt sind.

In unserem Beispiel von eben wäre dann die Klasse, die Klasse hieße Fuba

und die hätte ein Attribut, das hieße Dann-Dann-Slots

und da steht drin A, B und C

als Strings. Stehen da auch

Methodennamen drin oder nur

Attributnamen.

Nur die Attributnamen.

Und wenn ich da Methodennamen reinschreibe, dann kann ich da eine Methode für definieren,

die trotzdem funktioniert?

Kannst du machen, klar, wenn du willst.

Da müsste man ja ausprobieren, was da passieren kann.

Das kannst du generell machen.

Du kannst generell an jede Klasseninstanz

eine Methode dran machen, die muss halt

den Parameter self haben.

Als erstes. Und dann funktioniert das wie die Methode.

Weil Methoden an Klassen sind nichts anderes

als

Funktionen, die den Parameter self haben.

Aber was ist denn, wenn das nicht in den Stops drinsteht?

Ja, wenn es nicht in den Slots drinsteht, kannst du nicht darauf zugreifen.

Genau, das heißt, die Methode kann ich nicht aufrufen, weil es nicht in den Slots drinsteht.

Das heißt, auch die Slots sind für Methoden dann exklusiv.

Du kannst die Methode in die Klassendefinition reinschreiben und die kommt dann zusätzlich zu den Slots dazu.

Du kannst sie halt nicht dynamisch hinzufügen.

Du kannst sie nicht dynamisch hinzufügen.

A-Slots wird zusammengebaut aus dem, was in dem Attributslot drinsteht und in den Namen, die als die Methode dienen.

Da wäre ich mir nicht so sicher.

Probier es mal auszuhochen.

Ja, ist meiner Meinung nach so.

Jetzt müssen wir gerade ein bisschen tippen.

und wir gucken, ob wir die solche haben.

Okay.

Also foo.astl.

Das funktioniert schon mal.

Also genau so.

Und jetzt sagen wir foo.slots.

Ich glaube nicht, dass das zusammengebaut wird.

Ich glaube, dass slots bleibt so, wie es ist.

Aber das funktioniert. Methoden gehen, ohne dass

ein Slots drin steht und es ist nicht ein Slots drin.

Du kannst aber Methoden hinzufügen.

Weil die Methoden

an dem Typ dranhängen und nicht

in der Instanz.

Das heißt, an einer

Instanz, die ein Slots-Attribut hat,

kannst du nichts verändern. Du hast nur genau

diese Keys, die da drin sind.

In dem darüberliegenden

Typ hast du Methoden drin und da kannst du

auch, kannst du alles mögliche drin haben. Das ist deine

normale Klasse. Okay, es geht leider nur für die Instanz,

die Slots. Genau.

Die Slots sind für Instanzen von dieser Klasse

und wenn diese Klasse aber selbst

noch Methoden hat oder Attribute, ja, du kannst

auch in diese Klasse ein Attribut reinschreiben. Du kannst da x gleich

10 reinschreiben und das kannst du auch auslesen

und du kannst es auch an der Klasse

verändern. Ja, okay.

aber nicht in den Instanzen.

Weil in den Instanzen darfst du nur auf Slots zugreifen.

Ja.

Und das bedeutet, dass

eine Klasse mit Slots im Wesentlichen

wie ein Name-Tupel ist, nur besser.

Mit besserer Syntax und

mehr Methoden. Und das ist auch

der Grund, warum Name-Tupel nicht mehr so richtig...

Jawohl, aber ich finde, dass das neue Name-Tupel von

Typing ist doch gar nicht so schlecht.

Nee, also es hat auch noch andere Nachteile.

Es gibt ja jetzt auch

etwas, was man vielleicht eher

nehmen... Also vielleicht meinst du es so,

Es gibt ja Dataclasses, die sind ja auch jetzt in der Sprache drin.

Ja, genau.

Und die sind auch in eigentlichen, also es gab es auch, ich weiß nicht, Artikel dazu.

Ich meine, ich habe es jetzt nur mal so gelesen, ich habe es nicht wirklich selber überprüft,

aber so, wo Leute sagen, also bitte nehmt doch alle Dataclasses und nicht mehr nehmt Tuppel,

weil Dataclasses ist schneller, ist besser, ist in jeder Hinsicht besser.

Es gibt keinen Grund mehr dafür.

Das alte Zeug ist nur noch drin.

Man kann es lesen.

Ja.

Okay, ja.

Es kann mehr und es ist schneller.

Also ich meine, es gibt keine großen Nachteile.

und es gibt das natürlich, also

das Vorbild für

Dataclass ist halt dieses

Atris-Modul, das sehr beliebt ist.

Das kann halt dann noch viel mehr.

Und ist auch relativ schnell, wenn ich das richtig verstehe.

Ist auch sehr nett, ja.

Und also das ist

was vielleicht damit angefangen hat, dann Dataclass

ist eingebaut und jetzt gibt es halt auch noch sowas wie

Pydentic, das ist ja auch so ähnlich.

Das ist noch schneller.

Der Münster bei Dataclass ist nicht schneller als Atris.

Ich weiß nicht, ne, Pydentic meine ich auch

eine eigene Geschichte. Ja, bei Denny ist es eigen, aber es ist nicht da.

Doch, doch.

Nee, ist es nicht? Nee.

Es ist ein Einstehen sogar langsamer als Etos zum Beispiel.

Okay. Jochen dachte, es wäre schneller.

Ich dachte, es wäre Data-Klari-Grunden drin.

Ich habe irgendwo so ein Video, das muss ich eigentlich mal in den

Schirm losverdenken, wo jemand das ganz gut auseinander nimmt,

wo der so im Timing-Stop... Also, das muss

sich mal irgendjemand ganz genau angucken und

Bescheid sagen, wie das denn wirklich ist.

Und dann in der Episode hier in den

Podcast kommen und uns das allen erklären, wie es ist.

Genau, das wäre gut.

Ja, absolut.

Genau, aber es ist auf jeden Fall ein Ding,

was halt, und

diese ganzen Dinge, wenn man

die sich alle anguckt, also NameTouple

ist halt das, was man am wenigsten nehmen sollte von den ganzen

Sachen.

Ich finde ja die moderne Sondergeschichte, das sieht eigentlich ganz hübsch aus.

Das ist halt so schnell.

Wenn du es halt aufschreiben willst,

vom Typing-Import NameTouple, dann machst du einfach

auf, keine Ahnung, NameTouple

define NameTouple und irgendwas und dann

schreibst du halt die Attribute untereinander wie in der Klasse,

definierst. Dir ist klar, welchen Datentyp haben die denn

und so. Das sieht schon so aus als...

Okay, vielleicht muss ich mir das auch nochmal angucken, weil

das ich das vom Typing importiere, kenne ich jetzt noch

gar nicht. Ja, aber das ist auf jeden Fall, glaube ich,

ich weiß auch gar nicht, ob sich eine Implementierung da was geändert hat,

aber ich glaube, wir werden es eigentlich haben, oder?

Also das musst du erstmal kurz aufmachen,

um dir das mal anzuschauen.

Okay, dann muss ich da mal eingehen.

Ich würde tatsächlich eher Dataclasses verwenden für diesen

Newscase, aber

ich habe ja immer seltsame Ansichten.

Ja, das ist eine neue Sache.

Abgefunden, dass ich nicht im Standard bin.

Ach, so sieht das...

Nee, okay.

Ach doch, so sieht das aus, ja, okay.

Ja, typing.namet-tuppel

und dann sagt man hier irgendwie...

Ja, aber das ist sogar noch...

Moment, jetzt muss ich mal...

Ja, da unten, also das nächste Beispiel...

Wir wissen, dass die Zuhörer den Monitor nicht sehen können.

Genau, das ist das Problem bei Podcasts.

Und das Problem ist auch, ich kann das jetzt nicht vorlesen,

kann ich schon, hilft nur nicht.

Ja, genau, aber ich finde so die Gesundheit,

das sieht doch gar nicht so schlecht aus.

Ja, okay, also gut.

und muss ich das mal jemandem anklicken

und dann muss ich es halt sagen.

Also es ist auch eine Möglichkeit, die man machen kann.

Ja, ja, ja.

Ja.

Ja, ja.

Okay, aber das ist ja nur syntaktischer Zucker, oder?

Ja, syntaktisch Zucker.

Sehr gut.

Also dann ist es quasi Name-Double.

Okay, schön. Das ist auch okay.

Es gibt noch zwei Dinge, die ich

vorhin gelernt habe. Das erste ist Counter.

Wir haben es schon kurz angesprochen.

Counter ist auch eine Dictionary-Subklasse.

und die macht im Wesentlichen das, was sie sagt.

Ich gebe eine Sequenz rein und die zählt, wie oft jedes Element drin vorkommt.

Das heißt, wenn ich einen String reingebe, dann habe ich hinterher ein Dictionary

und in dem Dictionary steht drin, wie oft jeder Buchstabe in diesem String vorkommt.

Und das ist großartig, weil das baut man sich so oft selbst

und das baut man sich so oft von Hand und macht ein Default-Dict oder macht ein Get

und inkrementiert die Zahl dann und so weiter.

einfach einen Counter und die Sequenz

reintun und fertig. Und man kriegt einen Dickschneider

raus mit der Anzahl.

Super, ist großartig. Und das hat auch diese ganzen

Funktionen, die man dazu braucht. Also wenn man das dann

updaten möchte oder wenn man das

wenn man

einen Generator hat oder wenn man

irgendwas anderes in der Hand hat und das nicht genau

vorher weiß oder wenn man zwischendurch noch was machen möchte,

ist großartig. Ein Counter

zusammen mit einer Comprehension, super.

Ja, ja.

Es deckt so viele von diesen Fällen ab, für die man

sonst Default-Dict verwendet.

Ich habe noch was anderes schönes gefunden

und zwar heißt es Chainmap

Das ist auch ein Corrections-Modul drin

Was ist denn eine Chainmap?

Eine Chainmap

das ist so ein

Ich hatte so ein bisschen an JavaScript Objects erinnert

Wenn du

nach einem Key suchst

dann suchst du quasi durch die ganze

Reihe durch. Das heißt Chainmap nimmt eine

Menge von Dictionaries

und wenn du nach einem Key fragst

dann guckt er im ersten

Dictionary, ist der da drin? Wenn er da drin ist, kriegst du den Wert. Wenn er nicht drin ist,

guckt er im zweiten nach. Wenn er da drin ist, kriegst du den Wert. Wenn er nicht drin ist, guckt er im dritten

nach und so weiter, bis er alle seine darunterliegenden Dictionaries

durchgeschaut hat. Wenn er es nirgendwo findet, kriegst du immer noch einen Key Error.

Wenn du aber einen Wert reinschreibst,

in diese Chain Map, dann schreibt er das immer in das oberste

Dictionary rein. Das heißt, du veränderst nur das erste Dictionary aus deiner Kette,

hast aber lesenden Zugriff

auf die darunterliegenden.

Und das ist so ein bisschen

so wie Objekte in JavaScript

funktionieren, wie Object in JavaScript funktioniert.

Wenn du liest, liest du immer

aus dem Ersten, was verfügbar ist,

aber wenn du schreibst, schreibst du immer ins Oberste rein.

Ja, ja, ja.

Ja, ich überlege gerade auch, also ich meine,

das ist auch sowas, ja, ich weiß es nicht genau,

aber ich mache jetzt auch so ein bisschen

JavaScript gerade und

und was dann doch ein bisschen einfacher hinzuschreiben ist als in Python,

ist halt diese 3-Punkt-Spratch-Operator-Syntax,

wo man sich neue Sachen generiert, indem man ein altes Ding nimmt

und dann sagt man Punkt, Punkt, Punkt, altes Ding

und dann schreibt man noch ein neues Ding dazu oder so.

Und mit Chainmap hat man ja da quasi was ganz Ähnliches.

Das ist eben, wie gesagt, diese Prototypsache.

JavaScript ist halt der Kern von JavaScript.

jedes

Object oder jedes Dictionary in JavaScript

hat einen Prototypen, auf den

du zurückfallen kannst und das kannst

du hier mit Chainmap nachbauen.

Ja, nett.

Fand ich sehr schön, dass es gibt.

Habe ich noch nie gebraucht.

Wüsste jetzt auch nicht, an welcher Stelle ich das

einsetzen würde, aber

gibt es auf jeden Fall.

Ich glaube, wenn man das braucht, ist das eine sehr

sehr nützliche Sache.

und

weil man so Hierarchien damit bauen kann.

Ja.

Vielleicht noch einmal ganz kurz, weil ich gerade nachgeguckt

hatte zu diesem, which Python

Data Classes best, habe ich ein Artikel,

also ein Video gefunden von einem Kanal

M-Coding heißt und

da vergleicht jemand tatsächlich