WEBVTT

00:00:00.000 --> 00:00:03.840
Ja, hallo, liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode 36.

00:00:05.040 --> 00:00:09.540
Heute wollen wir mit euch ein bisschen über die technischen Implementierungsdetails von Dictionaries reden.

00:00:11.060 --> 00:00:12.720
Jochen ist natürlich wieder da. Hi, Jochen.

00:00:12.780 --> 00:00:13.560
Hallihallo, Dominik.

00:00:13.980 --> 00:00:16.840
Dominik, genau. Und heute ist auch wieder Johannes dabei. Hi, Johannes.

00:00:17.240 --> 00:00:17.840
Hallo zusammen.

00:00:17.980 --> 00:00:18.400
Ja, moin.

00:00:19.040 --> 00:00:24.880
Ja, wir fangen wie immer ein bisschen News aus der Szene an und was uns sonst noch so einfällt.

00:00:24.940 --> 00:00:26.260
Und dann gehen wir so ein bisschen in das Thema rein.

00:00:27.740 --> 00:00:28.100
Ja.

00:00:28.820 --> 00:00:31.040
Also du wolltest unbedingt noch über den Copilot reden,

00:00:31.080 --> 00:00:31.400
habe ich gehört.

00:00:31.900 --> 00:00:32.640
Ich wollte das.

00:00:33.660 --> 00:00:34.400
Ja, ich auch.

00:00:34.500 --> 00:00:36.440
Der Jochen ist derjenige, der immer darüber sprechen möchte.

00:00:36.700 --> 00:00:38.020
Ja, wir haben schon zweimal darüber gesprochen.

00:00:38.760 --> 00:00:40.100
Aber jetzt hat auch Jochen ihn ausprobiert.

00:00:40.500 --> 00:00:43.220
Jetzt hat auch PyCharm jetzt auch Copilot.

00:00:43.440 --> 00:00:44.040
Deswegen, genau.

00:00:45.540 --> 00:00:47.700
Genau, ich habe irgendwann die erlösende Mail von GitHub

00:00:47.700 --> 00:00:49.980
bekommen, sodass ich jetzt im Beta-Programm auch mit drin bin.

00:00:50.340 --> 00:00:52.140
Und genau, da muss ich das natürlich direkt mal ausprobieren.

00:00:52.500 --> 00:00:54.100
Und ich hätte da eigentlich gar keine so hohen Erwartungen,

00:00:54.220 --> 00:00:56.180
obwohl du immer schon davon so vorgeschwärmt hast.

00:00:56.300 --> 00:00:57.320
Ja, du hast immer gesagt, ach, was für ein Quatsch,

00:00:57.360 --> 00:00:57.920
das ist ja völlig egal.

00:00:58.020 --> 00:00:59.880
Das kann ja nicht, also wenn man jetzt irgendwie so

00:00:59.880 --> 00:01:01.940
durchschnittlichen Code davon irgendwie in den Leuten

00:01:01.940 --> 00:01:04.000
kriegt, das kann ja nichts

00:01:04.000 --> 00:01:05.940
taugen. Aber

00:01:05.940 --> 00:01:07.600
ich muss sagen, ich bin doch

00:01:07.600 --> 00:01:10.080
sehr überrascht, dass das manchmal wirklich, wirklich

00:01:10.080 --> 00:01:10.920
hilfreich ist.

00:01:10.940 --> 00:01:12.200
Sogar Jochen findet das hilfreich.

00:01:13.780 --> 00:01:15.860
Ja, ich finde es auch sehr cool. Also ich finde vor allem

00:01:15.860 --> 00:01:17.720
dieses Autocompletion cool. Er lernt irgendwie aus seiner eigenen

00:01:17.720 --> 00:01:19.860
Codepace und weiß so ein bisschen, was du als nächstes vorhaben

00:01:19.860 --> 00:01:21.500
könntest oder macht manchmal so einen guten Vorschlag.

00:01:22.000 --> 00:01:23.840
Ist natürlich nicht immer, ist auch nicht immer

00:01:23.840 --> 00:01:25.120
richtig, aber manchmal ist erstaunlich richtig.

00:01:25.560 --> 00:01:27.820
Ja, und manchmal findet man halt

00:01:27.820 --> 00:01:29.740
Dinge dadurch erst,

00:01:29.960 --> 00:01:31.780
die man, also ich habe, ich mache

00:01:31.780 --> 00:01:32.720
jetzt manchmal auch so ein bisschen

00:01:32.720 --> 00:01:35.140
JavaScript beziehungsweise TypeScript

00:01:35.140 --> 00:01:36.360
und

00:01:36.360 --> 00:01:39.380
manchmal weiß ich einfach nicht, wie Sachen gehen.

00:01:39.820 --> 00:01:41.760
Also ich habe keine Ahnung, wie das geht und dann fange

00:01:41.760 --> 00:01:43.240
ich irgendwie mit einem variablen Namen an

00:01:43.240 --> 00:01:45.760
und dann kriege ich so einen ganzen Codeblock

00:01:45.760 --> 00:01:47.780
und der tut genau das, was ich eigentlich machen wollte.

00:01:48.080 --> 00:01:49.180
Ja genau, das ist halt richtig.

00:01:49.740 --> 00:01:51.560
Also du musst halt wirklich aufpassen, was für Namen du

00:01:51.560 --> 00:01:53.720
in den Dingen gibst. Wenn du dir gute Namen gibst, ist es ja viel besser,

00:01:53.800 --> 00:01:54.600
als wenn du schlechte Namen gibst.

00:01:54.980 --> 00:01:57.680
Muss man sowieso aufpassen und immer gute Namen

00:01:57.680 --> 00:02:04.120
Genau, aber wenn man das dann halt macht und dann auch einen guten Docstring schreibt oder einen Kommentar dazu, dann lernt er sogar noch aus diesen Docstrings, aus den Kommentaren was dazu.

00:02:04.520 --> 00:02:14.480
Oder halt, also was halt bei mir voll gut funktioniert, ich mache halt den Methodennamen beispielsweise oder den Klassnamen oder die Funktion und die Argumente und typen und dann weiß er ziemlich oft, was zu tun ist, wenn ich den Docstring noch mache.

00:02:14.800 --> 00:02:18.460
Dann schreibe ich im Docstring rein, was er tun soll und dann, der Vorschlag, der ist schon echt gut.

00:02:18.840 --> 00:02:22.560
Also auch, da gibt einer halt auch Implementierungsvorschläge, an die man vielleicht nicht gedacht hat oder sowas schon.

00:02:22.880 --> 00:02:28.300
Ja, also da, das ist durchaus sehr beeindruckend.

00:02:28.300 --> 00:02:35.280
Und ich weiß, warum Jochen den gut findet, weil er sich ja immer selber am eigenen Code-Repo orientiert und er orientiert sich an Jochens eigenem Code und dann denke ich auch natürlich immer, oh, was für ein toller Vorschlag.

00:02:35.720 --> 00:02:37.060
Ja, großartiger Stil.

00:02:38.400 --> 00:02:46.200
Also Kritik würde ich sagen, es ist auch besser geworden, wenn man diese Nightly-Version nimmt.

00:02:46.200 --> 00:03:08.320
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 womit Copilot halt irgendwie unerwarteterweise, weil man denkt, das ist eigentlich eine einfache Geschichte, große Probleme hat, wo er deswegen große Probleme hat, ist Klammern.

00:03:08.320 --> 00:03:09.980
Also die Klammern richtig zu setzen.

00:03:10.400 --> 00:03:11.200
Also zum Beispiel zu machen.

00:03:11.700 --> 00:03:13.480
Das macht eigentlich fast nie die Klammern richtig zu.

00:03:14.240 --> 00:03:16.040
Oder halt irgendwie, dass das halt

00:03:16.040 --> 00:03:17.460
nur Sinn macht, wenn es runde Klammern sind.

00:03:17.540 --> 00:03:19.220
Manchmal macht er auch einfach eckige Klammern bei mir.

00:03:19.760 --> 00:03:21.540
So an Stellen, wo Funktionen aufgerufen werden.

00:03:21.720 --> 00:03:23.180
Und dann ist das natürlich, das funktioniert halt nicht.

00:03:24.280 --> 00:03:26.060
Kannst du das nicht erklären,

00:03:26.160 --> 00:03:27.800
dass das doch irgendwie diese neuronalen Netze,

00:03:27.860 --> 00:03:30.220
weil die halt nicht genügend Zustand für sowas haben, oder?

00:03:32.240 --> 00:03:33.960
Ja, man muss denen halt irgendwie

00:03:33.960 --> 00:03:36.200
die Syntax sozusagen irgendwie so einprügeln,

00:03:36.200 --> 00:03:38.220
dass sie das halt nicht, dass das nichts Unscharfes

00:03:38.220 --> 00:03:40.000
ist oder, aber das funktioniert

00:03:40.000 --> 00:03:41.240
vielleicht nicht so richtig. Also meistens funktioniert es ja auch.

00:03:41.240 --> 00:03:43.400
Test durch valide Sonntagslaufen oder sowas, das wird ja schon gehen.

00:03:43.400 --> 00:03:46.240
Ja, aber prinzipiell hat dieses Netz ja kein Verständnis von

00:03:46.240 --> 00:03:48.100
ich habe Endklammern geöffnet und muss

00:03:48.100 --> 00:03:49.920
jetzt Endklammern auch wieder schließen in der richtigen Reihenfolge.

00:03:49.940 --> 00:03:51.940
Ja gut, aber du kannst ja alle Vorschläge aussortieren, bei denen das

00:03:51.940 --> 00:03:54.100
nicht stimmt oder du kannst ja danach noch auditieren oder

00:03:54.100 --> 00:03:56.140
sowas. Ja, ja klar, also es ist jetzt auch kein großes

00:03:56.140 --> 00:03:58.040
Problem, nur das ist halt irgendwie so ein bisschen

00:03:58.040 --> 00:03:59.940
erstaunlich, wo man sich denkt so, naja, also das Schwierige,

00:04:00.080 --> 00:04:02.100
den schwierigen Teil, den kann es eigentlich überraschend

00:04:02.100 --> 00:04:04.180
gut, nämlich irgendwie rausfinden,

00:04:04.180 --> 00:04:06.280
was man da machen wollte und dann den Code schreiben,

00:04:06.360 --> 00:04:07.400
der zumindest so aussieht, als würde er das richtig tun.

00:04:07.400 --> 00:04:08.260
Und dann macht er Klammerfehler.

00:04:08.600 --> 00:04:10.300
Und dann kommen halt so Dinge, wo man sagt,

00:04:10.440 --> 00:04:13.600
eine IDE kann das ja schon, die Klammern richtig setzen.

00:04:14.200 --> 00:04:14.980
Und das geht dann nicht mehr.

00:04:15.620 --> 00:04:17.180
Aber ich meine, das sind Sachen,

00:04:17.300 --> 00:04:20.020
die wird man halt mit der Zeit in den Griff kriegen,

00:04:20.120 --> 00:04:20.500
denke ich mal.

00:04:20.600 --> 00:04:23.040
Und dann ist das schon echt beeindruckend.

00:04:23.300 --> 00:04:25.260
Was man auch mal machen muss, ist so User-Daten.

00:04:25.800 --> 00:04:27.420
Beispielsweise machst du irgendwie eine JSON auf

00:04:27.420 --> 00:04:30.300
und dann machst du einen Namen,

00:04:30.400 --> 00:04:32.100
eine E-Mail-Adresse oder sowas und ein Passwort

00:04:32.100 --> 00:04:33.260
und dann machst du Autocomplete.

00:04:34.180 --> 00:04:35.780
Da gibt es ja halt eine Liste von Usern

00:04:35.780 --> 00:04:37.820
irgendwie, die mit dem Nutzernamen

00:04:37.820 --> 00:04:38.820
Passwort und so, das war schön.

00:04:39.520 --> 00:04:41.260
Das war dann die Frage, sind die generiert?

00:04:41.780 --> 00:04:43.580
Generiert oder ja, oder sind die generiert oder echt?

00:04:43.800 --> 00:04:45.700
Man weiß es aber nicht so genau, von wo

00:04:45.700 --> 00:04:47.040
die sind. Das sind alle gelernt.

00:04:48.100 --> 00:04:49.660
Ja, es ist wohl auch, wenn man so Zahlenfolgen

00:04:49.660 --> 00:04:51.700
eingibt, dann gibt er einem interessante Instruktionen.

00:04:52.340 --> 00:04:53.720
Das ist ein Screenshot

00:04:53.720 --> 00:04:56.020
gesehen, wo dann russische Funktionsnamen

00:04:56.020 --> 00:04:56.500
dazukamen.

00:04:57.340 --> 00:04:59.500
Also, okay. Ja, ich bin ja mal gespannt,

00:04:59.660 --> 00:05:01.380
was dabei rauskommt, wenn man so was

00:05:01.380 --> 00:05:03.880
man anfängt irgendwie so 3.1,

00:05:03.980 --> 00:05:05.080
4, 1, 7.

00:05:07.700 --> 00:05:08.060
Ja.

00:05:08.840 --> 00:05:09.160
Ja.

00:05:09.160 --> 00:05:11.480
Ja, ja, vielleicht, vielleicht.

00:05:12.040 --> 00:05:14.020
Also, ja, das ist ja...

00:05:14.020 --> 00:05:16.100
Das ist noch keine AGI, das ist noch keine generelle

00:05:16.100 --> 00:05:17.280
Intelligenz, glaube ich.

00:05:17.520 --> 00:05:19.840
Da habe ich letztens, ach ja, ich komme vom Holzen aufs

00:05:19.840 --> 00:05:21.540
Stöckchen, aber vielleicht ist das ja auch nicht so uninteressant,

00:05:21.920 --> 00:05:23.500
wieder einen ganz netten

00:05:23.500 --> 00:05:25.680
Podcast-Episode gehört mit

00:05:25.680 --> 00:05:26.540
Lex Friedman,

00:05:26.780 --> 00:05:28.820
Steven Wolfram.

00:05:30.080 --> 00:05:31.800
von Wolfram Alper, interviewt hat, genau.

00:05:32.520 --> 00:05:34.260
Ja, der ist ja so ein Wunderkind und dann so ein bisschen

00:05:34.260 --> 00:05:36.000
hinter den Erwartungen. Eine sehr kontroverse Persönlichkeit.

00:05:36.260 --> 00:05:37.860
Ja, polarisierend.

00:05:38.080 --> 00:05:39.660
Warum? Jetzt musst du das genau aufklären, direkt.

00:05:40.220 --> 00:05:42.300
Ja, es gibt Leute, die lieben ihn total und der macht ja auch

00:05:42.300 --> 00:05:44.320
viele gute Sachen, aber es gibt Leute, die

00:05:44.320 --> 00:05:46.120
hassen ihn auch total, weil der halt auch

00:05:46.120 --> 00:05:48.320
seine Meinung für

00:05:48.320 --> 00:05:49.720
sehr wichtig hält. Achso, okay.

00:05:49.940 --> 00:05:52.240
Wir wollen ja die Gründe und Anekdoten auch hören.

00:05:52.460 --> 00:05:54.080
Es geht um seine Meinung, die er präsentiert.

00:05:54.540 --> 00:05:56.300
Ja, und er ist auch

00:05:56.300 --> 00:05:58.440
so ein, er hat so ein paar

00:05:58.440 --> 00:06:00.640
interessante Fixierungen. Der findet, dass die ganze Welt

00:06:00.640 --> 00:06:02.620
aus State Machines besteht und muss alles mit

00:06:02.620 --> 00:06:03.660
State Machines machen.

00:06:05.080 --> 00:06:06.600
Und Rule 34 ist das einzige,

00:06:06.820 --> 00:06:08.180
was...

00:06:08.180 --> 00:06:09.900
War das nicht die andere Nummer?

00:06:10.740 --> 00:06:11.940
War das nicht Rule...

00:06:11.940 --> 00:06:14.900
Rule 38 oder so?

00:06:15.060 --> 00:06:15.860
Das ist die...

00:06:15.860 --> 00:06:18.600
Ja, diese 30er-Regeln, also das ist so eine Klasse

00:06:18.600 --> 00:06:20.320
von...

00:06:20.320 --> 00:06:22.100
State Machines.

00:06:22.100 --> 00:06:23.940
Und die kannst du durchnummerieren und die haben

00:06:23.940 --> 00:06:26.060
eine natürliche Ordnung und dann

00:06:26.060 --> 00:06:28.020
findest du halt irgendwann eine, die eine universelle

00:06:28.020 --> 00:06:29.380
Turing-Maschine ist im Wesentlichen.

00:06:31.960 --> 00:06:33.980
Stephen Wolfram sagt halt, mehr oder weniger,

00:06:34.160 --> 00:06:36.080
der schreibt ganze Bücher darüber, was diese

00:06:36.080 --> 00:06:38.180
State Machine alles kann und dass die das Universum

00:06:38.180 --> 00:06:40.200
enkodiert. Und das ist

00:06:40.200 --> 00:06:40.620
natürlich,

00:06:42.140 --> 00:06:44.060
wenn du die gesamte Wissenschaft

00:06:44.060 --> 00:06:45.300
umstellen willst auf State Machines.

00:06:45.820 --> 00:06:47.900
Ich habe immer noch keine Ahnung, was Rule 38 ist, aber

00:06:47.900 --> 00:06:49.940
das Urban Digitry hat mir gesagt, Rule 38 ist

00:06:49.940 --> 00:06:51.940
a prison offense, in which someone is

00:06:51.940 --> 00:06:52.960
muster waiting in public.

00:06:54.380 --> 00:06:55.680
Ah, ja, okay.

00:06:55.680 --> 00:06:57.580
Also, wenn du mal viel Spaß hast mit so einem

00:06:57.580 --> 00:06:59.500
Private Mode an, hast, dann google doch mal

00:06:59.500 --> 00:07:01.780
Rule 34, das ist glaube ich

00:07:01.780 --> 00:07:03.960
die, if it exists,

00:07:04.380 --> 00:07:05.820
there's porn of it, glaube ich.

00:07:06.140 --> 00:07:07.360
Das ist auch irgendwie eine sehr wichtige

00:07:07.360 --> 00:07:09.600
Regel und tatsächlich stimmt sie halt einfach immer.

00:07:10.180 --> 00:07:11.440
Aber... Leider,

00:07:11.440 --> 00:07:12.460
leider erstaunlicherweise.

00:07:12.960 --> 00:07:14.920
There's a type of porn, there's a website for it.

00:07:15.580 --> 00:07:17.660
Ach so, okay. Das ist auch Rule 38.

00:07:18.660 --> 00:07:19.420
Rule 30

00:07:19.420 --> 00:07:21.360
sagen die. Okay, aber das sind

00:07:21.360 --> 00:07:23.040
beides nicht die Regeln, die ich jetzt gerade meinte.

00:07:25.480 --> 00:07:26.360
30 ist es.

00:07:27.580 --> 00:07:30.860
genau, nee, aber genau, um diese Dinger ging es

00:07:30.860 --> 00:07:32.660
natürlich bei der Episode auch und

00:07:32.660 --> 00:07:34.660
also ich finde das schon interessant, ja, ich meine

00:07:34.660 --> 00:07:36.700
das ist ja, also er hatte irgendwie, Leute hatten

00:07:36.700 --> 00:07:38.980
hohe Erwartungen an ihn, weil er war halt so ein Wunderkind

00:07:38.980 --> 00:07:40.560
und dann ist aber irgendwie

00:07:40.560 --> 00:07:42.600
dann doch nicht irgendwie so wirklich so

00:07:42.600 --> 00:07:43.020
Einstein

00:07:43.020 --> 00:07:46.660
einsteinmäßige Ausmaße haben seine

00:07:46.660 --> 00:07:48.600
Theorien da jetzt nicht angenommen, sondern er

00:07:48.600 --> 00:07:50.360
so ein bisschen hinter den Erwartungen zurückgeblieben

00:07:50.360 --> 00:07:52.520
und aber tatsächlich

00:07:52.520 --> 00:07:54.140
ist er ja genau eben der Meinung

00:07:54.140 --> 00:07:56.520
er hat ja ein Buch geschrieben, das hat auch schon so

00:07:56.520 --> 00:07:58.580
Titel, New Kind of Science.

00:07:59.860 --> 00:08:00.720
Das, ja,

00:08:00.880 --> 00:08:02.700
den kann man ja auch nur nehmen, wenn man denkt, da hat man jetzt mal

00:08:02.700 --> 00:08:03.300
echt was gefunden.

00:08:04.880 --> 00:08:06.440
Ja, hat ein gewisses Selbstbewusstsein.

00:08:07.140 --> 00:08:08.780
Aber er hat ja auch coole Sachen gemacht, also so ist es

00:08:08.780 --> 00:08:10.160
nicht. Also es ist nicht nur...

00:08:10.160 --> 00:08:12.160
Er ist halt auch super, ungeheuer produktiv.

00:08:12.340 --> 00:08:14.720
Er hat so ein Diagramm veröffentlicht

00:08:14.720 --> 00:08:16.680
von wann er E-Mails schreibt und der hat

00:08:16.680 --> 00:08:18.540
eigentlich immer 18-Stunden-Tage und

00:08:18.540 --> 00:08:20.000
manchmal hat er auch 24-Stunden-Tage.

00:08:21.680 --> 00:08:22.660
Er erschlägt

00:08:22.660 --> 00:08:24.380
es einfach durch Produktivität, diese

00:08:24.380 --> 00:08:26.060
ganzen Kritikpunkte.

00:08:26.520 --> 00:08:32.380
Ja, also er hat ja auch so eine Firma, die macht Mathematiker, auch eine super Software, also ja.

00:08:33.000 --> 00:08:34.020
Ja, oder eben Wolfram Alpha.

00:08:34.020 --> 00:08:55.540
Und Wolfram Alpha, genau, ja, und ja, auch die Firma so zu nennen, also naja gut, aber das ist, er macht ja wirklich cooles Zeug, also so kann man eigentlich auch nichts sagen und das fand ich so ganz interessant, weil es jetzt, weil er auch da, weil 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.

00:08:55.540 --> 00:08:57.720
und er... Du meinst Tau halbe?

00:08:58.160 --> 00:08:58.640
Ja, genau.

00:08:59.560 --> 00:09:01.520
Ja, stimmt. Tau ist dann vielleicht etwas, was man

00:09:01.520 --> 00:09:02.440
häufiger noch braucht als Pi.

00:09:04.240 --> 00:09:05.280
Und genau,

00:09:05.440 --> 00:09:07.660
wie jeder weiß, ist das Ding halt

00:09:07.660 --> 00:09:08.700
transcendent rational

00:09:08.700 --> 00:09:09.860
und

00:09:09.860 --> 00:09:13.780
hat eine Menge super interessante Eigenschaften,

00:09:14.260 --> 00:09:15.680
aber so fundamentale Sachen,

00:09:15.800 --> 00:09:17.400
die man jetzt, wo man denkt, das müsste man doch eigentlich

00:09:17.400 --> 00:09:19.620
darüber wissen, also wie zum Beispiel sowas wie

00:09:19.620 --> 00:09:22.720
kommen denn alle

00:09:22.720 --> 00:09:25.520
Ziffern in der Dezimalbruchentwicklung von

00:09:25.520 --> 00:09:27.600
Pi mit der gleichen Wahrscheinlichkeit vor? Also ist

00:09:27.600 --> 00:09:28.740
Pi normal oder nicht?

00:09:29.760 --> 00:09:31.500
Das weiß man halt nicht. Und zwar so

00:09:31.500 --> 00:09:33.480
gar nicht. Und hat auch gar keine Ahnung, wie man das irgendwie

00:09:33.480 --> 00:09:35.560
hinkriegen könnte. Dabei ist die Regel, die jetzt

00:09:35.560 --> 00:09:37.680
Pi erzeugt, eben auch ziemlich einfach

00:09:37.680 --> 00:09:39.540
eigentlich. Und dann ist es

00:09:39.540 --> 00:09:41.660
doch irgendwie überraschend, dass dabei eine Ziffernfolge

00:09:41.660 --> 00:09:43.420
rausfällt, die einmal so total zufällig aussieht,

00:09:44.100 --> 00:09:45.600
wo man nicht drüber sagen kann,

00:09:45.780 --> 00:09:47.340
jetzt okay, nicht mal die

00:09:47.340 --> 00:09:49.160
Verteilung der Ziffern da drin sagen kann.

00:09:49.560 --> 00:09:51.000
Und die so aussieht, als wäre sie,

00:09:51.320 --> 00:09:53.260
als könnte man wirklich nicht, man kann es halt

00:09:53.260 --> 00:09:54.940
auf nichts anderes reduzieren. Man kann da drin,

00:09:55.060 --> 00:09:56.240
findet daran keine Muster oder

00:09:56.240 --> 00:09:59.100
da kommt einfach alles, was es überhaupt

00:09:59.100 --> 00:10:00.960
an Mustern irgendwie gibt, kommt wohl offenbar daran

00:10:00.960 --> 00:10:02.080
vor. Das ist halt

00:10:02.080 --> 00:10:05.020
die Frage ist halt, wie kommt

00:10:05.020 --> 00:10:07.160
aus so etwas, aus so einer einfachen

00:10:07.160 --> 00:10:08.400
Regel, wie man Pi bilden kann,

00:10:08.880 --> 00:10:11.040
warum fällt da plötzlich so ein ganzes Universum raus?

00:10:11.860 --> 00:10:12.700
Ja, das ist ja

00:10:12.700 --> 00:10:15.100
im Wesentlichen das, was der Wolfram auch sagt

00:10:15.100 --> 00:10:16.900
mit seiner Regel 30. Das ist ja eine ganz simple

00:10:16.900 --> 00:10:18.880
Regel. Das ist die 30. die du ausprobierst,

00:10:18.940 --> 00:10:20.800
wenn du sie nach seiner Ordnung machst und dann kommt so

00:10:20.800 --> 00:10:23.040
mordsmäßiges Chaos raus und alles, was du dir vorstellen

00:10:23.040 --> 00:10:23.360
kannst.

00:10:25.060 --> 00:10:28.620
Das ist so eine generelle Sache in der Mathematik.

00:10:28.720 --> 00:10:31.220
Irgendwann mache ich da auch mal noch einen längeren Diskurs drüber.

00:10:33.360 --> 00:10:36.580
Dass man mathematisch gesehen aus sehr einfachen Regeln,

00:10:36.700 --> 00:10:39.860
wo man denkt, die sind einfach genug, um sie im Kopf auszuführen,

00:10:40.920 --> 00:10:44.500
Dinge produzieren kann, die völlig unabsehbar sind.

00:10:44.740 --> 00:10:46.280
Und völlig überraschend auch,

00:10:46.380 --> 00:10:48.640
weil sie eben nicht mehr sich an die Regeln halten,

00:10:48.640 --> 00:10:51.480
sondern weil sie dann irgendwelche chaotischen Sachen produzieren.

00:10:51.800 --> 00:11:02.820
Und das ist was sehr Erschreckendes und es 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.

00:11:02.820 --> 00:11:15.920
Also um das nochmal so zusammenzufassen, du hast gerade dich 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.

00:11:15.920 --> 00:11:18.380
Nicht bekannt sind, überhaupt nicht bekannt sind, alle. Also die kannst du ja nicht kennen.

00:11:21.000 --> 00:11:22.820
Aber man weiß halt nicht.

00:11:22.980 --> 00:11:25.120
Es könnte ja sein, dass irgendwann keine Neunen mehr vorkommen.

00:11:25.220 --> 00:11:26.000
Einfach gar keine mehr.

00:11:27.220 --> 00:11:28.280
Ist das normalerweise so?

00:11:29.040 --> 00:11:30.700
Nee, ist eben nicht normalerweise so.

00:11:31.080 --> 00:11:31.800
Aber es könnte sein.

00:11:31.880 --> 00:11:32.700
Wir können es nicht ausschließen.

00:11:33.840 --> 00:11:35.140
Das ist die Sache, was der Jochen sagt.

00:11:35.280 --> 00:11:35.780
Keine Ahnung.

00:11:38.020 --> 00:11:39.200
Und das ist überraschend,

00:11:39.400 --> 00:11:40.960
dass man da so gar keine Ahnung hat.

00:11:41.040 --> 00:11:43.100
Weil man denkt so, naja, das müsste man doch jetzt irgendwie,

00:11:43.160 --> 00:11:45.760
wenn man die Regel wie Pi entwickelt wird,

00:11:45.840 --> 00:11:47.300
hinschreibt und eine Funktion wie Pi ausrechnet.

00:11:47.720 --> 00:11:49.300
Das ist wirklich so ein paar Zeilen.

00:11:49.620 --> 00:11:58.620
Also 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.

00:11:59.620 --> 00:12:04.520
Oder zumindest es kommt immer mal wieder ne neun vor, das ist ja schon ne Aussage, die sehr schwer zu treffen ist.

00:12:05.200 --> 00:12:11.640
Ja, aber das ist doch im Endeffekt, reduziert sich das doch runter auf das Halting-Problem, oder? Also wenn du das lösen kannst, dann kannst du auch das Halting-Problem lösen.

00:12:11.840 --> 00:12:13.500
Was ist das Halting-Problem und was ist das Tau-Halbe?

00:12:14.840 --> 00:12:36.820
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.

00:12:37.240 --> 00:12:53.940
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 so ein Witz unter Mathematikern, wo man Leute leicht auf die Palme bringen kann.

00:12:53.980 --> 00:12:57.620
Dann aber einfach nochmal kurz die ganze Unbelegung. Was ist denn Pi?

00:12:59.340 --> 00:13:05.300
Pi ist das Verhältnis zwischen dem Radius eines Kreises und der Fläche des Kreises.

00:13:06.500 --> 00:13:13.480
Und das heißt, wenn ich einen Kreis mit einem Radius 1 habe, dann hat er die Fläche Pi.

00:13:15.160 --> 00:13:21.160
Und bei den meisten geometrischen Figuren ist es so, dass die Fläche sich relativ leicht berechnet.

00:13:21.300 --> 00:13:24.720
Also wenn ich ein Quadrat habe und das hat Seitenlänge 1, dann hat es die Fläche 1.

00:13:25.820 --> 00:13:30.800
Und wenn ich ein Dreieck habe, dann hat es die Fläche 1,5 mal 1.

00:13:31.400 --> 00:13:32.980
Dann gibt es irgendwelche ganz leichten Formeln.

00:13:33.080 --> 00:13:34.420
Beim Kreis ist es leider anders.

00:13:35.040 --> 00:13:36.780
Da kommt eben die Zahl Pi raus.

00:13:36.900 --> 00:13:39.120
Und die Zahl Pi ist eine transzendente Zahl.

00:13:40.460 --> 00:13:42.740
Das heißt, die ist eine nicht-rationale Zahl.

00:13:42.740 --> 00:13:47.260
Es gibt keinen Bruch, der Pi korrekt darstellen kann.

00:13:47.940 --> 00:13:49.900
Es ist auch eine transzendente Zahl.

00:13:50.000 --> 00:13:51.900
Das heißt, die ist nicht algebraisch.

00:13:51.980 --> 00:13:55.700
Das heißt, es gibt auch keinen Polynom, was Pi als Lösung hat.

00:13:55.820 --> 00:14:15.460
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.

00:14:17.320 --> 00:14:18.340
Das geht mit Pi nicht.

00:14:18.440 --> 00:14:21.740
Es gibt für Pi kein Polynom, was Pi als Lösung hat.

00:14:21.860 --> 00:14:23.600
Und deshalb ist es eine ganz besondere Zahl.

00:14:23.680 --> 00:14:24.300
Nee, es gibt keins.

00:14:24.340 --> 00:14:25.540
Gibt es nicht? Also es ist bewiesen, dass es nicht gibt?

00:14:26.160 --> 00:14:27.480
Ja, weil es transzendent ist.

00:14:28.140 --> 00:14:30.420
Und tatsächlich der Beweis, dass Pi transzendent ist,

00:14:30.420 --> 00:14:31.600
ist eine sehr schwierige Sache.

00:14:32.880 --> 00:14:34.820
Ist auch noch gar nicht ungeheuer lange her.

00:14:37.220 --> 00:14:38.820
Aber das Ergebnis ist eben sehr wichtig,

00:14:39.000 --> 00:14:41.060
weil das eine Klasse von Zahlen ist,

00:14:41.060 --> 00:14:45.260
von denen es wesentlich mehr gibt als von anderen Zahlen,

00:14:45.680 --> 00:14:47.180
die für uns aber aus unserem menschlichen

00:14:47.180 --> 00:14:48.720
Verständnis her sehr schwer erreichbar sind,

00:14:49.040 --> 00:14:51.000
weil wir eben Brüche gewohnt sind und

00:14:51.000 --> 00:14:53.020
Wurzeln von irgendwas, also

00:14:53.020 --> 00:14:54.580
algebraische Zahlen,

00:14:55.140 --> 00:14:57.020
das sind aber tatsächlich so auf eine

00:14:57.020 --> 00:14:58.540
gewisse Art und Weise die wenigsten

00:14:58.540 --> 00:14:59.600
reellen Zahlen.

00:15:03.180 --> 00:15:04.920
Es ist eben eins von diesen

00:15:04.920 --> 00:15:06.800
bekannten Beispielen für eine Zahl, die

00:15:06.800 --> 00:15:08.200
sich anders verhält, als man denkt.

00:15:08.820 --> 00:15:10.820
Und deshalb ist sie in der Mathematik sehr wichtig,

00:15:11.040 --> 00:15:12.520
weil sie eben eine

00:15:12.520 --> 00:15:14.100
transzendente Zahl ist.

00:15:15.100 --> 00:15:17.200
Es gibt noch ähnliche Zahlen, es gibt noch E.

00:15:18.500 --> 00:15:19.560
Die Eulersche Zahl?

00:15:19.760 --> 00:15:20.900
Die Eulersche Zahl, genau.

00:15:21.020 --> 00:15:22.840
Und die hat nicht ganz so eine einfache Erklärung.

00:15:23.000 --> 00:15:23.920
Sehr gut, Dominik.

00:15:24.960 --> 00:15:29.680
Die hat nicht ganz so einfache Eigenschaften,

00:15:29.740 --> 00:15:30.940
die ist nicht ganz so einfach zu erklären.

00:15:31.380 --> 00:15:32.680
Aber ist auch transzendent.

00:15:33.860 --> 00:15:35.480
Man weiß auch nicht, ob es normal ist.

00:15:36.940 --> 00:15:39.440
Man weiß auch da die Verteilung der Sachen alle nicht.

00:15:40.260 --> 00:15:43.100
Das heißt, diese Zahlen, die sind sehr, sehr schwer in den Griff zu kriegen,

00:15:43.220 --> 00:15:44.980
obwohl es eigentlich sehr viele davon gibt.

00:15:45.100 --> 00:15:48.440
und ja

00:15:48.440 --> 00:15:50.240
das ist halt leider so

00:15:50.240 --> 00:15:52.760
ja und genau

00:15:52.760 --> 00:15:54.760
also ja in gewisser Weise haben die jetzt auch was

00:15:54.760 --> 00:15:56.720
mit eben diesen ganzen

00:15:56.720 --> 00:15:58.700
theoretischen Informatikgeschichten zu tun

00:15:58.700 --> 00:16:00.360
weil sie sozusagen in gewisser Weise

00:16:00.360 --> 00:16:03.700
berechnungstechnisch

00:16:03.700 --> 00:16:06.620
irreduzierbar sind sozusagen also man kann halt

00:16:06.620 --> 00:16:06.980
nicht

00:16:06.980 --> 00:16:10.120
keine geschlossene Form

00:16:10.120 --> 00:16:11.720
man muss sie tatsächlich ausrechnen

00:16:11.720 --> 00:16:14.620
genau sonst kriegt man sie

00:16:14.620 --> 00:16:16.640
halt nicht in den Griff. Und das Problem ist, das ist halt

00:16:16.640 --> 00:16:18.480
teuer, die auszurechnen, da muss man halt

00:16:18.480 --> 00:16:20.820
Ja, und das ist ja auch so ein bisschen ein Sport,

00:16:20.980 --> 00:16:22.520
dass die meiste

00:16:22.520 --> 00:16:24.660
Anzahl Stellen von Pi ausgerechnet ist.

00:16:24.660 --> 00:16:26.360
Ja, gab es letztens irgendwie wieder eine Nachricht, dass da

00:16:26.360 --> 00:16:28.560
60 Millionen Stellen oder weiß ich nicht

00:16:28.560 --> 00:16:30.000
oder noch mehr, ich weiß gar nicht genau, wie viele.

00:16:30.440 --> 00:16:32.820
Genau, also da kommt man dann halt wirklich sehr schnell in solche

00:16:32.820 --> 00:16:34.640
Bereiche rein, wo es dann gar nicht mehr so sehr

00:16:34.640 --> 00:16:36.440
um Prozessorleistung geht und gar nicht so sehr um

00:16:36.440 --> 00:16:38.740
Smarthand geht, sondern da kriegst du dann so richtig die Big Data

00:16:38.740 --> 00:16:40.560
Probleme. Wie schaffst du das auf einer Zahl

00:16:40.560 --> 00:16:42.280
zu operieren, die 60 Milliarden Stellen hat?

00:16:42.280 --> 00:16:44.480
Ich habe mich mal kennengelernt, der hat sich als Hobby

00:16:44.480 --> 00:16:46.460
Aufgabe gemacht, Nachkommastellen von Pi

00:16:46.460 --> 00:16:48.240
auswendig zu lehren, hat, glaube ich, die ersten 250

00:16:48.240 --> 00:16:49.020
aufsagen können.

00:16:50.140 --> 00:16:52.460
Okay, das ist schon mal nicht so schlecht. Ja, wir haben doch alle so einen Freund,

00:16:52.560 --> 00:16:53.340
oder, der sowas kennt.

00:16:54.360 --> 00:16:54.580
Ja,

00:16:56.160 --> 00:16:58.280
es gibt auch irgendwie die Gesellschaft

00:16:58.280 --> 00:17:00.140
der Freunde von Pi, glaube ich, und da

00:17:00.140 --> 00:17:02.240
muss man irgendwie die ersten 100 Stellen auswendig können

00:17:02.240 --> 00:17:03.800
oder so, damit man aufgenommen werden kann.

00:17:05.360 --> 00:17:06.140
3,1, 4,2,

00:17:06.280 --> 00:17:06.980
wie geht das weiter?

00:17:09.920 --> 00:17:10.280
Ja,

00:17:10.280 --> 00:17:12.480
3,1, das ist schon ungefähr richtig.

00:17:14.280 --> 00:17:34.540
Wie du das sagst, gibt es auch so interessante Fälle, wo dann in irgendeinem CAD-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 irgendwie der letzten zehn Jahre alle falsch.

00:17:36.280 --> 00:17:37.560
Sehr schön, sehr schön.

00:17:38.280 --> 00:17:40.360
Kann man 3,142 sagen oder ist das auch immer falsch?

00:17:41.980 --> 00:17:46.120
3,1415 ist so die Standardweise,

00:17:46.260 --> 00:17:47.020
aber es ist eigentlich falsch,

00:17:47.120 --> 00:17:48.040
weil es geht ja mit 9 weiter.

00:17:50.820 --> 00:17:53.340
Wenn man Pi, ich glaube, auf 15 Stellen genau hat,

00:17:53.420 --> 00:17:55.280
dann reicht das schon für alle physikalischen Sachen aus,

00:17:55.340 --> 00:17:57.220
weil das dann irgendwie schon im Nanometer-Bereich ist

00:17:57.220 --> 00:17:59.040
und so genau kannst du halt nicht mehr.

00:17:59.720 --> 00:18:01.840
Und 3,142 ist zu grob noch für sowas?

00:18:03.000 --> 00:18:06.280
Ja, da hast du halt, wenn du einen Kreis machst,

00:18:06.360 --> 00:18:08.120
der 10 Meter im Durchmesser hat,

00:18:08.580 --> 00:18:10.280
hast du halt eine Abweichung von 1%.

00:18:10.280 --> 00:18:15.180
Also das ist dann schon eine ganze Menge.

00:18:19.240 --> 00:18:22.180
Jede Programmiersprache hat eine konstante eingebaut,

00:18:22.280 --> 00:18:25.880
die Pi heißt, Python übrigens auch, math.py.

00:18:26.720 --> 00:18:28.400
Und die hat mehr Stellen,

00:18:28.660 --> 00:18:30.300
als man je in seinem Leben brauchen wird.

00:18:31.920 --> 00:18:33.840
Deshalb völlig ausreichend.

00:18:33.940 --> 00:18:35.740
Du hast gerade einen Bogen zu Python gesagt,

00:18:35.780 --> 00:18:36.500
ich bin begeistert.

00:18:36.880 --> 00:18:37.580
Ja, wunderbar, oder?

00:18:37.780 --> 00:18:39.420
Ja, sollten wir vielleicht irgendwie mal zurückkommen.

00:18:39.420 --> 00:18:41.860
Das ist mir wieder so völlig unvorhergesehen,

00:18:42.040 --> 00:18:42.860
aber ich finde das eigentlich ganz interessant.

00:18:42.860 --> 00:18:44.780
Das sollte doch heute eine Basics-Episode sein, oder?

00:18:46.400 --> 00:18:46.760
Ja.

00:18:47.400 --> 00:18:48.220
Da bist du die Leute halt durch.

00:18:49.020 --> 00:18:50.900
Wenn man an die Möhre ran will,

00:18:51.020 --> 00:18:53.200
muss man auch ab und zu mal, keine Ahnung.

00:18:54.200 --> 00:18:55.800
Man muss ja erst ausgraben, die Möhre.

00:18:56.040 --> 00:18:56.520
Ja, rotten.

00:18:58.660 --> 00:18:59.700
Gibt es noch

00:18:59.700 --> 00:19:00.520
was an News?

00:19:01.080 --> 00:19:03.760
Ich weiß nicht genau, ist irgendwas Interessantes passiert?

00:19:04.920 --> 00:19:05.660
Django ist

00:19:05.660 --> 00:19:07.160
jetzt gerade die

00:19:07.160 --> 00:19:09.040
Prerelease-Kandidat.

00:19:09.060 --> 00:19:10.900
4.0 ist der Prerelease.

00:19:11.240 --> 00:19:11.900
Das hatten wir gewünscht.

00:19:13.360 --> 00:19:14.340
Letztes Mal hatten wir Alpha.

00:19:14.900 --> 00:19:16.940
Ansonsten weiß ich nicht, gibt es eigentlich nichts.

00:19:16.940 --> 00:19:19.220
Python 3.10 ist immer noch aktuell und immer noch

00:19:19.220 --> 00:19:21.460
cool. Ja, meine letzte Folge hieß Python 3.10,

00:19:21.540 --> 00:19:22.520
Johanna. Ja, gut.

00:19:23.020 --> 00:19:25.200
Dann ist es trotzdem, ich wiederhole mich,

00:19:25.280 --> 00:19:26.620
es ist immer noch aktuell und immer noch cool.

00:19:27.800 --> 00:19:27.820
Ja.

00:19:29.560 --> 00:19:30.000
Ja.

00:19:31.300 --> 00:19:33.420
Es gab ganz lette Artikel.

00:19:33.660 --> 00:19:35.120
Einmal so über Python

00:19:35.120 --> 00:19:36.680
im Bankenumfeld gab es einen, der

00:19:36.680 --> 00:19:39.140
Oh, Bank-Python, großartig.

00:19:39.280 --> 00:19:39.620
Wie, was?

00:19:41.280 --> 00:19:43.060
Es gibt wohl eine Variante von Python,

00:19:43.140 --> 00:19:45.700
die bei großen amerikanischen Banken eingesetzt wird

00:19:45.700 --> 00:19:48.460
und die hat gewisse spannende Eigenschaften,

00:19:48.520 --> 00:19:48.880
sagen wir mal so.

00:19:48.980 --> 00:19:49.540
Wie heißt die?

00:19:49.540 --> 00:19:53.300
Die wird beschrieben als ein Fork des kompletten Bank-Python.

00:19:53.560 --> 00:19:55.100
Bank-Python, jetzt habe ich es auch nicht verstanden.

00:19:55.640 --> 00:19:56.500
Bank-Python.

00:19:56.920 --> 00:19:57.260
Ja, okay.

00:19:58.440 --> 00:19:58.840
Großartig.

00:19:59.480 --> 00:20:02.940
Ich habe diesen Artikel gelesen und ich fand den super.

00:20:03.440 --> 00:20:03.960
Ja, ich auch.

00:20:04.300 --> 00:20:05.660
Und da sind auch so ein paar Ideen drin,

00:20:05.700 --> 00:20:06.820
wo ich mir denke, ja,

00:20:07.560 --> 00:20:09.840
da könnte man versuchen, sich eine Scheibe abzuschneiden.

00:20:09.940 --> 00:20:11.560
An Oral History of Bank Python.

00:20:11.860 --> 00:20:12.260
Genau.

00:20:13.880 --> 00:20:14.440
K.L. Peterson.

00:20:15.040 --> 00:20:17.720
Und es sind

00:20:17.720 --> 00:20:19.580
auch ganz viele Sachen drin, wo man sich denkt, naja, gut,

00:20:19.700 --> 00:20:21.560
okay, gut, die sind halt in dem Jahr, in dem sie

00:20:21.560 --> 00:20:23.380
den Fork gemacht haben, stehen geblieben und das war

00:20:23.380 --> 00:20:25.020
vermutlich 1994 und

00:20:25.020 --> 00:20:27.540
das ist jetzt halt so.

00:20:29.160 --> 00:20:29.740
Aber es gibt

00:20:29.740 --> 00:20:31.240
auch ein paar Sachen, die eigentlich sehr cool sind.

00:20:31.420 --> 00:20:33.800
Also dieser globale State und dieses globale

00:20:33.800 --> 00:20:35.640
Deployment und der Code ist

00:20:35.640 --> 00:20:37.580
in der Datenbank und du kannst alles anfassen

00:20:37.580 --> 00:20:39.000
und Barbara

00:20:39.000 --> 00:20:41.540
sind schon viele Dinge, die man sich

00:20:41.540 --> 00:20:42.780
mal überlegen könnte.

00:20:44.720 --> 00:20:45.620
Ja, Jochen, den hast du vermutlich

00:20:45.620 --> 00:20:47.420
in meinen Weaknotes gefunden, oder? Ja, genau.

00:20:47.740 --> 00:20:49.660
Ein bisschen Werbung machen für eine eigene Sache.

00:20:49.980 --> 00:20:51.200
Ja, richtig, genau.

00:20:52.920 --> 00:20:53.660
Ja, ich

00:20:53.660 --> 00:20:55.360
hänge mit meinen Weaknotes wieder total hinterher.

00:20:55.480 --> 00:20:57.560
Ich muss da unbedingt was machen, aber ich habe irgendwie keine Zeit.

00:20:57.640 --> 00:20:58.400
Das ist schrecklich.

00:20:59.300 --> 00:21:01.400
Das muss Teil des Prozesses werden.

00:21:01.480 --> 00:21:03.020
Das muss eine Gewohnheit werden.

00:21:03.020 --> 00:21:04.080
Hast du hier nichts zu tun, Johannes?

00:21:05.300 --> 00:21:06.680
Ich habe genügend zu tun,

00:21:06.840 --> 00:21:08.460
aber ich habe immer noch

00:21:08.460 --> 00:21:10.660
genügend Freizeit, dass ich Reddit

00:21:10.660 --> 00:21:12.600
lesen kann. Und wenn ich statt Reddit Weaknotes

00:21:12.600 --> 00:21:14.200
schreibe, dann ist das doch ein Gewinn für uns alle.

00:21:14.800 --> 00:21:15.300
Ja, das stimmt.

00:21:16.920 --> 00:21:18.600
Ja, so viel Freizeit habe ich leider nicht.

00:21:21.600 --> 00:21:22.220
Warte mal,

00:21:22.280 --> 00:21:24.560
haben wir nicht erst Montagabend

00:21:24.560 --> 00:21:26.920
von 20 bis 24 Uhr Computerspiele

00:21:26.920 --> 00:21:28.400
gespielt? Ist das Freizeit?

00:21:30.100 --> 00:21:30.700
Nein, das ist

00:21:30.700 --> 00:21:32.340
Socializing. Und das war erst um 20

00:21:32.340 --> 00:21:33.580
oder 36 haben wir angefangen.

00:21:34.140 --> 00:21:35.440
Oh, ja gut, okay, dann.

00:21:35.780 --> 00:21:37.440
Ja, und dass wir lange gespielt haben,

00:21:37.500 --> 00:21:39.600
hat mich natürlich nächsten Morgen

00:21:39.600 --> 00:21:41.060
noch was gekostet, das ist ja auch klar.

00:21:42.740 --> 00:21:43.580
Wir haben übrigens gespielt

00:21:43.580 --> 00:21:45.480
Max, Mechanized Assault

00:21:45.480 --> 00:21:46.060
and Exploration.

00:21:48.160 --> 00:21:49.540
Das ist ein Spiel, das kam das

00:21:49.540 --> 00:21:51.600
erste Mal, ich will jetzt nicht lügen, aber 1998 raus.

00:21:52.760 --> 00:21:53.460
Und so sieht's

00:21:53.460 --> 00:21:53.780
auch aus.

00:21:55.480 --> 00:21:57.440
Es ist trotzdem super, es gibt eine

00:21:57.440 --> 00:21:59.300
Max R, das ist eine

00:21:59.300 --> 00:22:00.800
Charakter-Version, wenn man die Original

00:22:00.800 --> 00:22:03.380
Anführungszeichen, Original-Videos

00:22:03.380 --> 00:22:04.520
und Sprites und sowas noch hat.

00:22:05.060 --> 00:22:06.140
Sieht gar nicht so schlecht aus, finde ich.

00:22:08.380 --> 00:22:08.600
Naja.

00:22:08.840 --> 00:22:10.860
Das Interface, also das ist oft so.

00:22:10.980 --> 00:22:12.780
Diese alten Sachen haben oft

00:22:12.780 --> 00:22:14.260
gute Ideen, aber schlechte Interfaces.

00:22:14.260 --> 00:22:16.600
Und ein passiertes RTS mit unheimlicher Komplexität.

00:22:16.680 --> 00:22:18.400
Das ist aus der 96 schon, ehrlich.

00:22:19.380 --> 00:22:21.320
So alt. Fast so alt wie ich.

00:22:21.920 --> 00:22:22.960
Ja, wir haben es geliebt.

00:22:23.060 --> 00:22:24.520
Ja, und wir spielen das auch übrigens noch weiter,

00:22:24.600 --> 00:22:25.080
die nächste Johannes.

00:22:25.940 --> 00:22:28.360
Ich dachte, wir spielen noch andere alte Spiele.

00:22:28.360 --> 00:22:30.200
Ja, das werden wir auch mal schaffen, vielleicht nächstes Jahr.

00:22:32.200 --> 00:22:32.720
Na gut.

00:22:33.380 --> 00:22:34.620
Wie war das gleich noch mit Python?

00:22:34.840 --> 00:22:36.560
Ja, genau. Dann machen wir jetzt

00:22:36.560 --> 00:22:39.020
Python-Dictionaries und so, ne?

00:22:40.000 --> 00:22:40.220
Ja.

00:22:40.920 --> 00:22:42.840
Ihr wolltet heute über Dictionaries sprechen.

00:22:43.000 --> 00:22:44.160
Ja. Richtig. Verstanden.

00:22:44.760 --> 00:22:47.200
Was ist denn ein Python-Dictionary? Ein Wörterbuch?

00:22:47.520 --> 00:22:49.100
Ein Mapping von

00:22:49.100 --> 00:22:51.100
Dingen auf andere Dinge? Dominik, wie verstehst du

00:22:51.100 --> 00:22:53.120
denn ein Python-Dictionary? Also ich meine, der Jochen und ich,

00:22:53.120 --> 00:22:54.960
wir können uns gleich noch über die Interna

00:22:54.960 --> 00:22:56.980
unterhalten und da gibt es viele spannende Dinge, die man da

00:22:56.980 --> 00:22:59.080
besprechen kann. Aber Dominik, wie siehst

00:22:59.080 --> 00:23:01.380
du denn ein Python-Dictionary? Was ist denn für dich ein Python-Dictionary?

00:23:01.480 --> 00:23:03.120
Was ist denn das, was ein Python-Dictionary ausmacht?

00:23:03.120 --> 00:23:04.980
verweifelte, geklammertes, definiertes

00:23:04.980 --> 00:23:06.700
Objekt in Python, also dass es kein Z ist, sondern

00:23:06.700 --> 00:23:08.760
dass es eine Zuordnung immer macht von einem

00:23:08.760 --> 00:23:10.880
Key auf einen Wert und wo

00:23:10.880 --> 00:23:12.560
halt der Lookup, also das, wenn man nachgucken kann,

00:23:12.660 --> 00:23:14.720
sehr, sehr schnell geht, weil man schön drauf zugreifen kann

00:23:14.720 --> 00:23:16.520
und dann gibt es direkt einen Wert zurück,

00:23:16.640 --> 00:23:18.620
den es rausschmeißt. Das ist so, dass wie im Python-Dict

00:23:18.620 --> 00:23:20.160
man ihn einfach, glaube ich, schnell benutzt.

00:23:22.080 --> 00:23:22.780
Okay, Zuordnung

00:23:22.780 --> 00:23:24.640
von einem Key zu einem Wert. Das heißt,

00:23:24.720 --> 00:23:26.180
ich könnte mir jetzt zum Beispiel zum

00:23:26.180 --> 00:23:28.880
Key Dominic deine Telefonnummer speichern.

00:23:29.260 --> 00:23:30.460
Ja, und dann könntest du das

00:23:30.460 --> 00:23:32.740
Phone Numbers nennen oder sowas und dann

00:23:32.740 --> 00:23:34.680
machst du das gleich mit Jochen noch und ja. Und könnte ich mir aber nicht

00:23:34.680 --> 00:23:35.900
auch deine Adresse dazu merken?

00:23:37.700 --> 00:23:38.660
Ja, aber zu was?

00:23:38.780 --> 00:23:40.600
Also ist ja die Frage, wie du das strukturieren

00:23:40.600 --> 00:23:42.000
möchtest. Also da kann man ja

00:23:42.000 --> 00:23:44.700
beliebige Objekte als Value hinterlegen.

00:23:44.940 --> 00:23:46.440
Nee, das stimmt nicht. Achso, als Value schon,

00:23:46.560 --> 00:23:48.720
aber Key als Key nicht. Nein, aber genau,

00:23:48.780 --> 00:23:50.620
als Value hinterlegen, das heißt, da kannst du natürlich dann... Aber immer nur

00:23:50.620 --> 00:23:51.040
einen, oder?

00:23:52.560 --> 00:23:53.820
Value, du kannst ja einen Tupel reinpacken.

00:23:54.680 --> 00:23:56.760
Okay, ich kann einen Tupel reinpacken, aber ich könnte mir jetzt nicht

00:23:56.760 --> 00:23:58.580
zweimal zu dir zwei verschiedene

00:23:58.580 --> 00:24:00.520
Sachen merken. Also das müsste ich dann selber machen.

00:24:00.520 --> 00:24:02.400
Nee, tatsächlich. Also ein Key muss

00:24:02.400 --> 00:24:04.300
das ist unique in einem Gespräch.

00:24:05.700 --> 00:24:06.420
Weil das ist ja

00:24:06.420 --> 00:24:08.260
in einem Wörterbuch nicht so. Und in einem

00:24:08.260 --> 00:24:09.500
Telefonbuch ist das auch nicht so.

00:24:11.760 --> 00:24:12.720
Das ist

00:24:12.720 --> 00:24:14.400
so eine Sache, die immer, ich mache gelegentlich

00:24:14.400 --> 00:24:16.040
Python-Schulungen, übrigens im Dezember wieder.

00:24:16.180 --> 00:24:18.480
Naja, aber wahrscheinlich ist dann so, dass dann, wenn du das Lookup machst

00:24:18.480 --> 00:24:20.140
und dann Dominik nachguckst und dann gibt es verschiedene Dominiks,

00:24:20.200 --> 00:24:22.180
dann hast du erst eine Liste von Dominiks, die du zurückkriegst

00:24:22.180 --> 00:24:23.620
und in dieser Liste stehen dann die einzelnen.

00:24:24.200 --> 00:24:25.380
Ja, aber ich kriege ja keine Liste.

00:24:25.440 --> 00:24:28.900
Wenn Dominik nachguckt, dann kriege ich nur einen Wert zurück.

00:24:28.900 --> 00:24:29.960
Der kann dann eine Liste sein.

00:24:30.100 --> 00:24:36.900
Genau, aber wenn es eine Liste ist, ja, aber dann, also der Unterschied zum Telefonbuch ist ja der Marginal, du musst halt einfach nur gucken, es ist ein oder mehrere Werte und dann jeweils dann wieder weiterpacken, aber.

00:24:37.640 --> 00:24:46.420
Ja, also ich finde, es ist für das Verständnis her schon ein sehr wichtiger Unterschied. In Dictionary kann jeder Eintrag nur einmal vorkommen, jeder Key kann nur einmal vorkommen.

00:24:46.500 --> 00:24:48.500
Okay, also ich habe tatsächlich irgendwann nochmal.

00:24:48.520 --> 00:24:52.000
In meinem Telefonbuch gibt es sehr viele verschiedene Müllers.

00:24:52.000 --> 00:24:58.460
Ja gut, aber wenn du Müller, dann die Liste von allen Müllers bekommst, dann ist ja der Zugriff auf einen einzelnen Müller genau, dann müsste es eigentlich nur eine Ebene tiefer sein, egal.

00:24:59.220 --> 00:25:01.520
was ich da so tiefer drin verstanden habe, ist, dass du irgendwie halt

00:25:01.520 --> 00:25:03.240
in den Speicher gemeldet wirst und das deswegen so schnell ist,

00:25:03.640 --> 00:25:04.960
weil er dann einfach dann die Speicheradresse

00:25:04.960 --> 00:25:07.580
nachschauen kann. Ja, das ist ja

00:25:07.580 --> 00:25:08.560
die Magie des Hashtables.

00:25:09.360 --> 00:25:11.840
Das Hashtable, das müssen wir auch gleich nochmal erklären, was ein Hashtable ist.

00:25:12.000 --> 00:25:12.060
Ja.

00:25:13.680 --> 00:25:15.640
Was können denn Keys sein? Weißt du das, Dominik?

00:25:15.680 --> 00:25:17.160
Weißt du das auswendig? Das ist total spannend.

00:25:18.160 --> 00:25:19.400
Wenn ich den Jochen frage,

00:25:19.680 --> 00:25:20.800
da weiß ich, dass der das weiß.

00:25:21.040 --> 00:25:23.200
Ja, also ich weiß, dass Strings es sein können,

00:25:23.300 --> 00:25:25.560
ich weiß, dass es Duples sein können, ich weiß, dass es

00:25:25.560 --> 00:25:26.640
Integers sein können.

00:25:27.920 --> 00:25:28.420
Noch was?

00:25:28.700 --> 00:25:29.240
Strings auch?

00:25:29.460 --> 00:25:30.360
Ja, genau, Strings, habe ich ja gesagt.

00:25:31.200 --> 00:25:32.380
Kann es auch ein Dictionary sein?

00:25:33.020 --> 00:25:33.200
Nee.

00:25:34.640 --> 00:25:36.080
Doch, sind die hashable?

00:25:36.600 --> 00:25:37.020
Und eine Liste?

00:25:37.700 --> 00:25:38.660
Sind die hashable?

00:25:38.820 --> 00:25:40.280
Das war schon eine sehr, sehr gute Frage.

00:25:40.660 --> 00:25:41.260
Oh, die hashable.

00:25:42.140 --> 00:25:44.540
Das frage ich dich, Dominik.

00:25:44.940 --> 00:25:45.560
Das weiß ich nicht.

00:25:45.560 --> 00:25:49.260
Die Regel ist tatsächlich ganz interessant.

00:25:49.760 --> 00:25:51.720
Ein Key von einem Dictionary muss etwas sein,

00:25:51.780 --> 00:25:52.840
was sich nicht verändern kann.

00:25:54.500 --> 00:25:55.620
Hashable sind diese Typen alle,

00:25:56.740 --> 00:25:57.880
aber der Hash kann sich verändern,

00:25:57.920 --> 00:25:59.900
wenn sich das Objekt verändert.

00:26:01.300 --> 00:26:04.760
Und deshalb gibt es für Liste gibt es Tupel.

00:26:04.980 --> 00:26:06.820
Ich kann eine Liste nicht als Key verwenden,

00:26:06.880 --> 00:26:07.700
weil die sich verändern kann.

00:26:07.820 --> 00:26:09.080
Ich kann aber ein Tupel verwenden.

00:26:09.840 --> 00:26:11.520
Und ein Tupel ist ja im Wesentlichen nichts anderes

00:26:11.520 --> 00:26:13.880
als eine Liste, die sich nicht verändern kann.

00:26:14.810 --> 00:26:16.610
Für Dictionaries und für Sets

00:26:16.610 --> 00:26:18.630
gibt es einen äquivalenten Datentyp,

00:26:19.790 --> 00:26:20.410
der heißt

00:26:20.410 --> 00:26:22.030
FrozenDict und FrozenSet

00:26:22.030 --> 00:26:24.730
und das sind im Wesentlichen

00:26:24.730 --> 00:26:26.510
Dictionaries und Sets, die sich nicht

00:26:26.510 --> 00:26:28.450
verändern können. Das heißt,

00:26:28.570 --> 00:26:29.830
wenn ich ein Set als

00:26:29.830 --> 00:26:32.810
Key in einem Dictionary haben möchte, muss ich ein FrozenSet

00:26:32.810 --> 00:26:34.050
draus machen.

00:26:35.390 --> 00:26:36.650
Und das ist auch so ein bisschen

00:26:36.650 --> 00:26:38.490
der einzige Sinn für diese beiden Datentypen,

00:26:38.590 --> 00:26:40.470
dass du eben ein unveränderliches Dictionary

00:26:40.470 --> 00:26:42.190
oder ein unveränderliches Set haben kannst,

00:26:42.490 --> 00:26:44.730
um sie als Key in einem Dictionary zu verwenden.

00:26:44.950 --> 00:26:46.610
Und warum das machen wir, ist, weil man Lookup haben will

00:26:46.610 --> 00:26:48.330
nach dem Motto, wenn das da drin ist, dann gib mir dies.

00:26:50.530 --> 00:26:53.310
Ja, oder halt auch, wenn man sie wieder in ein Set packen möchte,

00:26:53.410 --> 00:26:55.990
weil man möchte, dass da Schnittmengen von Sachen bilden können

00:26:55.990 --> 00:26:59.010
oder feststellen können, ob man das schon mal gesehen hat oder so.

00:26:59.270 --> 00:27:01.490
Ja, oder die Reihenfolge spielt keine Rolle.

00:27:02.290 --> 00:27:04.270
Das ist ja, das ist so ein bisschen, als Mathematiker,

00:27:04.690 --> 00:27:06.890
das Set ist wie eine Liste ohne Reihenfolge.

00:27:08.190 --> 00:27:09.970
Oh, die interessante Reihenfolge müssen wir uns auch merken,

00:27:10.090 --> 00:27:11.810
weil Order tickt und sowas, weil das ja früher nicht so ging.

00:27:11.890 --> 00:27:14.010
das, glaube ich, default ist. Ja, muss man inzwischen nicht mehr.

00:27:14.110 --> 00:27:15.870
Früher musste man sich OrderDict immer merken,

00:27:15.970 --> 00:27:17.890
aber inzwischen sind alle Dicts OrderDicts, deshalb

00:27:17.890 --> 00:27:19.990
den Typ OrderDict gibt's noch,

00:27:20.090 --> 00:27:22.190
aber der macht irgendwie gar nichts mehr. Ja, doch, doch, doch.

00:27:22.210 --> 00:27:23.150
Der hat noch einen Reversed, aber das ist alles.

00:27:23.150 --> 00:27:25.570
Ja, doch, der hat die Verhalten sich unterschiedlich.

00:27:26.810 --> 00:27:28.070
Also, tatsächlich

00:27:28.070 --> 00:27:29.870
macht das durchaus Sinn. Also, man muss einfach mal,

00:27:30.010 --> 00:27:31.990
das ist vielleicht so ein bisschen, vielleicht sollte man das nicht müssen, aber

00:27:31.990 --> 00:27:33.590
je nachdem, wie man

00:27:33.590 --> 00:27:35.630
Dict verhält, äh, wie man,

00:27:35.630 --> 00:27:37.370
wie sich das Dict verhalten soll,

00:27:37.410 --> 00:27:39.310
dass man verwendet, also wenn man zum Beispiel viele

00:27:39.310 --> 00:27:41.130
Insatz hat von Keys,

00:27:41.770 --> 00:27:43.470
dann ist es besser, Order dick zu nehmen

00:27:43.470 --> 00:27:46.150
statt dem Default-Ding.

00:27:46.550 --> 00:27:47.750
Also es gibt da tatsächlich subtile

00:27:47.750 --> 00:27:49.930
Unterschiede. Warum, Jochen? Wie wächst das denn? Wie wächst denn ein Dictionary?

00:27:50.110 --> 00:27:51.330
Ja, genau.

00:27:51.590 --> 00:27:52.770
Ich habe es vorhin nachgeguckt.

00:27:54.390 --> 00:27:55.430
Soll ich es euch verraten?

00:27:55.430 --> 00:27:56.130
Ja, verrat mal.

00:27:57.290 --> 00:28:01.670
Ein Dictionary fängt an mit null Buckets.

00:28:01.830 --> 00:28:03.690
Wenn du ein leeres Dictionary hast, das ist tatsächlich

00:28:03.690 --> 00:28:05.410
speziell. Das hat null Buckets, verbraucht

00:28:05.410 --> 00:28:06.330
64 Byte.

00:28:07.270 --> 00:28:09.550
Das ist übrigens unterschiedlich zwischen 32 und 64

00:28:09.550 --> 00:28:11.330
Bit. Maschinen, aber

00:28:11.330 --> 00:28:13.530
Ich glaube, wir sind alle inzwischen auf 64-Bit angelangt.

00:28:14.610 --> 00:28:17.690
Sobald ich eins einfüge, hat es acht Buckets.

00:28:18.890 --> 00:28:21.230
Buckets sind Speicherplätze, erklären wir gleich noch,

00:28:21.310 --> 00:28:22.690
weil es eben zu dieser Hashmap gehört.

00:28:23.690 --> 00:28:26.870
Und dann verdoppelt es sich jedes Mal, wenn es zwei Drittel voll ist.

00:28:29.210 --> 00:28:32.290
Der Speicherbereich wird vorreserviert für alles, was wir reinhaben.

00:28:32.750 --> 00:28:35.730
Genau, diese Datenstruktur, die heißt Hashmap

00:28:35.730 --> 00:28:38.910
und die braucht leeren Platz, die kann nicht 100% voll sein.

00:28:40.590 --> 00:28:42.650
Und deshalb machen die halt immer

00:28:42.650 --> 00:28:44.570
eine Verdopplung. Verdopplung ist so eine

00:28:44.570 --> 00:28:46.330
Wachstumsstrategie, die gut funktioniert. Auch bei

00:28:46.330 --> 00:28:48.370
Resizable-Listen,

00:28:48.570 --> 00:28:50.650
die verdoppeln sich

00:28:50.650 --> 00:28:52.230
auch. Das ist einfach so eine Wachstumsstrategie,

00:28:52.810 --> 00:28:54.710
die so eine gute Balance ist.

00:28:54.970 --> 00:28:56.330
Am besten wäre es, glaube ich, wenn man

00:28:56.330 --> 00:28:58.370
Wurzel 3 hätte als Wachstumsfaktor. Das ist

00:28:58.370 --> 00:29:00.530
2,3 oder irgendwas. Aber dann

00:29:00.530 --> 00:29:02.510
hast du die ganze Zeit krumme Zahlen und das ist auch nicht gut.

00:29:03.730 --> 00:29:04.470
Ja, stimmt. Das ist bei

00:29:04.470 --> 00:29:06.570
dem Array-Modul

00:29:06.570 --> 00:29:07.810
bei dem eingebauten.

00:29:07.950 --> 00:29:10.030
das habe ich mir mal näher angeguckt

00:29:10.030 --> 00:29:11.390
aus Gründen und

00:29:11.390 --> 00:29:13.970
da ist das auch so, weil das

00:29:13.970 --> 00:29:15.230
ist ja auch interessant, das ist ja

00:29:15.230 --> 00:29:18.090
quasi sozusagen wie eine Liste, bloß halt

00:29:18.090 --> 00:29:19.670
statisch getübt.

00:29:20.610 --> 00:29:22.070
Und man verbraucht tatsächlich

00:29:22.070 --> 00:29:24.110
nur den Platz, also für den Integer braucht man halt nur

00:29:24.110 --> 00:29:25.890
je nachdem, 32 oder 64 Bit.

00:29:26.630 --> 00:29:28.010
Und da ist es auch so,

00:29:28.350 --> 00:29:29.750
da kann man Append sagen hinten

00:29:29.750 --> 00:29:32.010
und wenn man da was hinzufügt und

00:29:32.010 --> 00:29:33.950
der Bereich der Memory View innen

00:29:33.950 --> 00:29:36.030
drin ist erschöpft,

00:29:36.190 --> 00:29:37.590
dann verdoppelt sich das halt auch immer.

00:29:37.950 --> 00:30:03.650
Ja, ist eine klassische Strategie. Okay, das bedeutet aber halt auch, man darf sich nicht darüber im Unklaren sein, so ein Dickjournal verbraucht relativ viel Speicherplatz. Wenn ich einen Eintrag in ein Dickjournal reintue, dann hat es direkt 240 Byte Hauptspeicher verbraucht. Das ist nicht ganz ohne. Wenn ich sechs Einträge reintue, hat es direkt 480 Byte verbraucht. Also es verbraucht relativ viel Speicherplatz.

00:30:03.650 --> 00:30:20.050
Es geht hier nicht um Effizienz, sondern es geht um Schnelligkeit. Und diese Schnelligkeit, die hat der Dominik schon angesprochen, das ist sehr schnell. Das heißt, es ist O von 1. Jeder Zugriff dauert immer gleich lang, amortisiert über die Verdopplungen.

00:30:21.870 --> 00:30:39.190
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 offeneins jeder Zugriff. Das heißt, jeder Zugriff dauert im Schnitt gleich schnell.

00:30:39.190 --> 00:30:42.190
Also amortisiert bedeutet für Dictionary ist der gleichen Länge.

00:30:42.770 --> 00:30:43.690
Nee, das bedeutet im Schnitt.

00:30:44.210 --> 00:30:45.190
Im Schnitt amortisiert.

00:30:45.250 --> 00:30:50.490
Im Durchschnitt bedeutet das, jeder Zugriff braucht ungefähr gleich lang und das ist eine konstante Zahl.

00:30:51.190 --> 00:30:53.330
Es gibt einzelne, die dauern ein bisschen länger.

00:30:53.350 --> 00:30:55.610
Ich habe diesen Worttransfer von amortisiert auf dem Schnitt hinbekommen.

00:30:57.030 --> 00:31:00.470
Wenn du eine große Anzahl Zugriffe machst,

00:31:01.070 --> 00:31:07.330
dann ist die Dauer so, als ob du eine Instante gewählt hättest.

00:31:07.390 --> 00:31:10.750
Genau, weil das Umbauen quasi Grenzwert Null hat.

00:31:11.350 --> 00:31:13.390
Das Umbauen passiert selten genug.

00:31:13.850 --> 00:31:15.050
Genau, dass es Grenzwert Null hat.

00:31:16.570 --> 00:31:17.750
Deswegen wird amortisiert.

00:31:19.310 --> 00:31:22.850
Okay, also O von 1. Also O von 1 bedeutet, es ist kein Problem.

00:31:23.250 --> 00:31:34.090
Genau, O von 1. Wir schreiben O von 1. 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.

00:31:34.090 --> 00:31:44.090
Also das heißt tatsächlich, um nochmal allen Hörern das so ein bisschen näher zu bringen, dieser Zeitnotation Big O noch nicht so viel anfangen kann. O von 1 bedeutet, es dauert quasi keine Zeit, das zu tun.

00:31:44.610 --> 00:31:45.690
Doch, es dauert immer gleich lang.

00:31:46.770 --> 00:32:12.410
Es ändert sich nicht mit der Menge, 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 Hash-Map hast, dann ist es halt immer noch O von, ist immer noch konstant, aber bei was anderem, bei einer Liste ist es halt O von N, wenn du darauf zugreifen willst, weil du musst ja alle Dinger angucken, ob es das jetzt ist, was du haben wolltest oder nicht.

00:32:12.410 --> 00:32:29.410
Aber OVN1 bedeutet halt, ich kann halt nichts machen. Also das 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 Schritt ist 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.

00:32:29.410 --> 00:32:30.470
Ja, genau.

00:32:31.730 --> 00:32:33.510
Und das ist was ganz Witziges.

00:32:34.610 --> 00:32:37.230
Ich hatte mal in der Python-Schulung einen Teilnehmer,

00:32:37.350 --> 00:32:38.710
der da auch gut mitgemacht hat.

00:32:39.390 --> 00:32:41.130
Und der war empört darüber.

00:32:41.190 --> 00:32:42.610
Das ist unmöglich, das kann gar nicht gehen.

00:32:43.130 --> 00:32:44.150
Das kann gar nicht sein.

00:32:45.170 --> 00:32:47.490
Und dann haben wir tatsächlich einen kleinen Benchmark geschrieben

00:32:47.490 --> 00:32:48.770
und haben das einfach mal ausprobiert.

00:32:49.390 --> 00:32:50.910
Und das ist eine sehr schöne Übung.

00:32:50.910 --> 00:32:53.770
Das ist eine sehr schöne Sache, einfach mal auszuprobieren,

00:32:54.490 --> 00:32:55.970
wie sich diese Laufzeiten verhalten.

00:32:56.490 --> 00:32:58.970
Wie lange es dauert, 1.000 Einträge einzufügen

00:32:58.970 --> 00:33:01.010
und 10.000 Einträge einzufügen und 100.000

00:33:01.010 --> 00:33:03.190
Einträge einzufügen und die dann auch wieder rauszulesen

00:33:03.190 --> 00:33:05.050
im Vergleich zu

00:33:05.050 --> 00:33:05.470
einer Liste.

00:33:06.990 --> 00:33:09.010
Also du hast einfach quasi die Keys

00:33:09.010 --> 00:33:10.950
mit Brackets

00:33:10.950 --> 00:33:12.870
dann gesetzt in einer Schleife oder was?

00:33:13.650 --> 00:33:14.930
Genau, und habe einfach die

00:33:14.930 --> 00:33:16.990
Zahlen von 1.000 bis 10.000 als Key

00:33:16.990 --> 00:33:18.950
und als Value, das spielt ja keine Rolle, wenn wir nur die

00:33:18.950 --> 00:33:20.830
Größe wissen wollen, das ist dann ein sehr

00:33:20.830 --> 00:33:22.990
unnützes Dictionary, weil das halt einfach

00:33:22.990 --> 00:33:25.030
immer sagt, zum Key 1 gehört der Wert

00:33:25.030 --> 00:33:26.490
1 und

00:33:26.490 --> 00:33:28.670
zum Key 10 gehört der Wert 10

00:33:29.650 --> 00:33:30.930
Aber wenn es nur ums Benchmarken geht,

00:33:31.030 --> 00:33:32.570
dann ist das eine einfache Sache.

00:33:32.710 --> 00:33:33.510
Und bei einer Liste genauso.

00:33:33.670 --> 00:33:37.670
Einfach mal eine Liste aus zwei Tupeln zusammengebaut.

00:33:38.610 --> 00:33:41.470
Und dann in dieser Liste einen bestimmten Eintrag suchen.

00:33:42.550 --> 00:33:43.330
Ist halt O von N,

00:33:43.570 --> 00:33:46.730
weil durch diese Liste von vorne bis hinten durchgegangen werden muss.

00:33:46.930 --> 00:33:48.550
Und wenn ich jetzt den Eintrag 100 suche,

00:33:48.610 --> 00:33:50.390
dann muss ich halt das erste Element angucken und fragen,

00:33:50.470 --> 00:33:51.970
ist das 1? Nein.

00:33:52.710 --> 00:33:54.710
Und das zweite Element, ist das 1? Nein.

00:33:55.450 --> 00:33:57.050
Und das muss ich dann 99 Mal machen.

00:33:57.130 --> 00:33:58.870
beim 100. sage ich, ist das Element 100?

00:33:59.830 --> 00:34:01.350
Und dann sage ich ja und dann bin ich fertig.

00:34:01.510 --> 00:34:02.310
Bei einem Dictionary,

00:34:03.150 --> 00:34:05.110
Hashmap, wir sprechen gleich, wie das funktioniert.

00:34:05.850 --> 00:34:06.710
Im Moment Magie.

00:34:08.130 --> 00:34:09.390
Dann passieren

00:34:09.390 --> 00:34:10.990
halt 10 Rechenschritte und dann

00:34:10.990 --> 00:34:13.030
steht da, okay, du hast jetzt so 100,

00:34:13.130 --> 00:34:15.190
hast du dir 100 gemerkt. Und das

00:34:15.190 --> 00:34:17.170
spielt keine Rolle, ob das Dictionary einen

00:34:17.170 --> 00:34:19.130
Eintrag hat, nämlich nur diese 100, oder

00:34:19.130 --> 00:34:21.110
ob es eine Million Einträge hat, das ist immer

00:34:21.110 --> 00:34:23.250
gleich schnell. Genau, aber was jetzt da

00:34:23.250 --> 00:34:24.710
interessant ist, das hat zwei Dinge. Also erstens,

00:34:25.010 --> 00:34:26.990
wie man dann, das ist eigentlich falter Datentyp,

00:34:27.070 --> 00:34:29.010
bei wem man dann in der Liste das vielleicht schneller

00:34:29.010 --> 00:34:30.950
suchen könnte, weil also theoretisch könntest du ja

00:34:30.950 --> 00:34:33.070
in der Liste quasi auch daraus eine Hashtable

00:34:33.070 --> 00:34:34.910
bauen, irgendwie aus allen Einträgen dieser Liste und einfach

00:34:34.910 --> 00:34:36.910
dann nachgucken, wenn die Hashtable sind,

00:34:37.030 --> 00:34:38.510
diese Datentypen oder sowas, ja, genau.

00:34:38.850 --> 00:34:40.870
Und dann halt überlegen sich irgendwie den Algorithmus, wie man

00:34:40.870 --> 00:34:42.430
relativ schnell die Dinge in dieser Liste findet,

00:34:43.030 --> 00:34:44.870
ohne dass man halt über die ganze Liste

00:34:44.870 --> 00:34:46.710
iterieren muss. Ja, aber da brauchst du eine andere

00:34:46.710 --> 00:34:48.610
Datenstruktur, wenn du nur die Liste hast, dann musst du halt...

00:34:48.610 --> 00:34:50.910
Genau, aber ja, genau. Die Liste an sich garantiert dir das

00:34:50.910 --> 00:34:52.890
nicht, die garantiert dir nur, das sind Elemente in einer

00:34:52.890 --> 00:34:54.530
Abfolge. Die nächste Frage wäre jetzt, wie halt

00:34:54.530 --> 00:34:56.290
in der Stickt, was ja auch im Prinzip

00:34:56.290 --> 00:34:58.430
eine Liste von Keys ist, jetzt erstmal so

00:34:58.430 --> 00:35:00.710
in der Syntag, wie das dann in den Speicher

00:35:00.710 --> 00:35:02.650
so reinkommt, dass man diesen Lookup machen

00:35:02.650 --> 00:35:03.530
kann, dass man halt quasi

00:35:03.530 --> 00:35:06.490
aus dem Wert des Keys

00:35:06.490 --> 00:35:08.330
eine Speicheradresse bekommt, quasi.

00:35:09.150 --> 00:35:09.910
Indem man da halt reinschreitet.

00:35:09.910 --> 00:35:12.670
Ich möchte noch dazu sagen, du hast jetzt gesagt,

00:35:12.890 --> 00:35:13.970
das ist eine Liste von Keys,

00:35:14.910 --> 00:35:16.550
das ist so, dem stimme ich so nicht

00:35:16.550 --> 00:35:18.610
ganz zu. Es gibt nämlich da drei

00:35:18.610 --> 00:35:20.030
Ansichten drauf. Es gibt die Keys,

00:35:21.490 --> 00:35:22.230
das ist ein Set,

00:35:22.650 --> 00:35:24.610
das ist eine Menge, die hat auch keine

00:35:24.610 --> 00:35:25.270
Reihenfolge.

00:35:26.290 --> 00:35:30.030
Ja, schon, aber früher nicht.

00:35:30.950 --> 00:35:32.270
Also hat eine Reihenfolge?

00:35:32.910 --> 00:35:40.490
Ja, aber es ist ein Set, weil im Sinne von die Reihenfolge ist nicht …

00:35:40.490 --> 00:35:41.890
Die Reihenfolge, die reingeschrieben worden sind?

00:35:42.370 --> 00:35:47.290
Ja, das ist die Reihenfolge, die jetzt halt irgendwann dazukommen sind.

00:35:47.390 --> 00:35:50.890
Aber wenn wir ein Dict von Python 3.4 nehmen, dann hat das keine Reihenfolge.

00:35:52.130 --> 00:35:53.930
Also in Python 3.5 kam ein Order Dict.

00:35:53.930 --> 00:36:06.650
Nee, also ein Audit-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.

00:36:07.330 --> 00:36:11.070
Also in 3.6 war es ein Implementierungsdetail und in 3.7 gehört es zur Spezifikation.

00:36:12.910 --> 00:36:16.530
Aber wenn man sich so ein ursprüngliches Dikt mal anschaut,

00:36:16.690 --> 00:36:18.190
dann sind die Keys eigentlich ein Set.

00:36:18.450 --> 00:36:20.930
Die haben keine Reihenfolge in dem Sinne

00:36:20.930 --> 00:36:24.290
und die können auch keine Duplikate enthalten.

00:36:24.450 --> 00:36:26.350
Und das ist genau das, was eine Menge ausmacht, ja, ein Set.

00:36:26.470 --> 00:36:27.790
Also quasi ein Set of Sorted Set.

00:36:29.870 --> 00:36:36.470
Ja, wobei die Sortierung die Reihenfolge des Einfügens ist.

00:36:37.230 --> 00:36:38.730
Dann gibt es die Values.

00:36:38.730 --> 00:36:40.730
Das ist auch ein View auf diese Daten,

00:36:41.610 --> 00:36:42.470
die in dem Diktionary drin sind.

00:36:42.550 --> 00:36:43.890
Das sind halt die Werte, die da gespeichert sind.

00:36:43.970 --> 00:36:45.090
Das ist im Wesentlichen eine Liste.

00:36:46.210 --> 00:36:47.150
Die Liste der Werte.

00:36:47.610 --> 00:36:48.910
Und dann gibt es noch die Items.

00:36:50.210 --> 00:36:51.990
Das ist eine Menge aus Tupeln,

00:36:52.170 --> 00:36:53.530
die jeweils Key und Value enthalten.

00:36:54.490 --> 00:36:56.730
Und für mich sind die Items so ein bisschen das,

00:36:56.830 --> 00:36:57.790
was das Dictionary ausmacht.

00:36:57.950 --> 00:36:59.130
Das ist das, was da drin ist.

00:36:59.130 --> 00:37:01.770
Also damit kann man ja quasi auch

00:37:01.770 --> 00:37:03.730
über so ein Dictionary iterieren oder sowas.

00:37:03.810 --> 00:37:05.790
Man kann das als Methode dot notated aufrufen

00:37:05.790 --> 00:37:07.130
und dann kannst du quasi

00:37:07.130 --> 00:37:09.830
for key value in dot items, bla.

00:37:11.030 --> 00:37:12.810
Genau, for key value in dict items.

00:37:12.910 --> 00:37:14.350
Das ist so ein Muster, das sieht man ganz häufig,

00:37:14.470 --> 00:37:17.070
weil man da einfach durch das gesamte Dictionary durchgeht.

00:37:17.890 --> 00:37:20.690
Man könnte auch sagen for key in Dictionary

00:37:20.690 --> 00:37:24.390
und dann sich jeweils den Value holen,

00:37:24.390 --> 00:37:25.570
weil es ist ja O von 1.

00:37:27.130 --> 00:37:29.590
Das kostet ja so gesehen algorithmisch nichts.

00:37:30.310 --> 00:37:34.770
Naja, sag mal so, wenn du eine Vorschleife machst über alle,

00:37:34.910 --> 00:37:37.250
dann ist das halt schon O von N sozusagen.

00:37:38.750 --> 00:37:39.110
Ja, genau.

00:37:39.470 --> 00:37:40.510
Nur im Einzelfall halt nicht.

00:37:40.710 --> 00:37:42.370
Aber die Value noch mal rauszuholen, wenn du die schon hast.

00:37:43.050 --> 00:37:48.070
Genau, also die O-Notation von for key value in dict items

00:37:48.070 --> 00:37:53.070
irgendwas tun und for key in dictionary

00:37:53.070 --> 00:37:56.850
und dann den Value als dict von key holen, ist identisch.

00:37:57.850 --> 00:37:59.850
Aber die Laufzeiteigenschaften sind natürlich

00:37:59.850 --> 00:38:01.070
für den zweiten Fall schlechter,

00:38:01.150 --> 00:38:03.430
weil ich dann jedes Mal noch mal in das Dictionary rein muss.

00:38:03.770 --> 00:38:05.970
Natürlich nur für einen konstanten Faktor.

00:38:05.970 --> 00:38:08.190
Ja, aber der summiert sich halt auch auf.

00:38:08.410 --> 00:38:10.810
aber konstante Faktoren, ja, konstante Faktoren

00:38:10.810 --> 00:38:12.490
sind halt, also wenn

00:38:12.490 --> 00:38:14.290
etwas nur zehnmal langsamer ist,

00:38:14.390 --> 00:38:15.790
das ist auch ein konstanter Faktor, das

00:38:15.790 --> 00:38:18.370
macht schon

00:38:18.370 --> 00:38:20.670
einen Unterschied. Ist schon ein Unterschied, ja.

00:38:20.670 --> 00:38:20.850
Ja.

00:38:23.370 --> 00:38:23.770
Genau.

00:38:24.310 --> 00:38:25.670
Wie kann man denn Dicks bauen, wisst ihr das?

00:38:26.110 --> 00:38:28.210
Ich habe vorhin einen ganz coolen Trick gelernt.

00:38:28.210 --> 00:38:30.150
Es gibt ja mehrere Wege,

00:38:30.250 --> 00:38:30.890
Dictionaries zu bauen.

00:38:32.650 --> 00:38:33.630
Ja, was meinte du?

00:38:34.230 --> 00:38:36.130
Syntaxmäßig, jetzt geschreibt in der Kamera, oder

00:38:36.130 --> 00:38:37.750
wie ich ein Dictionary erzeuge?

00:38:37.810 --> 00:38:40.170
Also du kannst es natürlich einmal machen als Dictionary Comprehension,

00:38:40.270 --> 00:38:41.890
indem du sagst, geschweige ich in der Klammer,

00:38:42.610 --> 00:38:44.050
Key, Value,

00:38:44.710 --> 00:38:46.130
oder du machst halt einfach

00:38:46.130 --> 00:38:48.070
die Definition einfach in den eckigen Klammern,

00:38:48.170 --> 00:38:50.150
schreibst dann den Key und die Value hinterher, oder du

00:38:50.150 --> 00:38:51.510
schreibst eine Liste von

00:38:51.510 --> 00:38:54.090
Keys und Values mit Gleichzeichen

00:38:54.090 --> 00:38:55.150
dahinter und machst dann ein Dict raus,

00:38:56.370 --> 00:38:58.110
also Dict of. Ja genau, das ist

00:38:58.110 --> 00:38:59.770
der normale, also das ist der

00:38:59.770 --> 00:39:01.810
Konstruktoransatz. Ja.

00:39:02.330 --> 00:39:03.930
Du kannst die Keys auch in der Schleife

00:39:03.930 --> 00:39:04.630
einfach hinzufügen.

00:39:05.990 --> 00:39:07.550
Du kannst auch irgendwie, keine Ahnung,

00:39:07.630 --> 00:39:09.950
Tupel-Unpacking oder sowas, die ganzen

00:39:09.950 --> 00:39:11.950
direkt da rein geben, mit so

00:39:11.950 --> 00:39:13.510
Sternchen, Sternchen halt, Quarks und Tacks.

00:39:15.130 --> 00:39:16.190
Beziehungsweise, wenn du eine Sequenz

00:39:16.190 --> 00:39:17.950
von Tupeln reingibst, von zwei Tupeln, dann nimmt der

00:39:17.950 --> 00:39:20.070
die automatisch. Eine Methode, die ich gerne verwende,

00:39:20.230 --> 00:39:21.990
ist dict.fromKeys.

00:39:23.490 --> 00:39:23.870
Das ist auch

00:39:23.870 --> 00:39:26.030
sehr nett. Was macht das?

00:39:26.710 --> 00:39:27.650
Naja, du gibst

00:39:27.650 --> 00:39:29.990
halt eine Liste von

00:39:29.990 --> 00:39:31.950
Keys und dann halt

00:39:31.950 --> 00:39:33.510
vielleicht einen Default-Wert oder so und dann

00:39:33.950 --> 00:39:35.630
erzeugt er das Ding dann raus mit diesem

00:39:35.630 --> 00:39:38.170
Factory-Methoden-Aufruf

00:39:38.170 --> 00:39:39.290
von dem Dict.

00:39:40.970 --> 00:39:42.250
Default-Dict gibt es noch irgendwie?

00:39:42.610 --> 00:39:43.650
Das ist eine andere Sache.

00:39:44.310 --> 00:39:46.190
Müssen wir nachher noch drüber sprechen.

00:39:46.290 --> 00:39:47.290
Das ist nämlich auch eine spannende Sache.

00:39:47.770 --> 00:39:50.150
Ich möchte noch einmal kurz zu der Comprehension zurückkehren,

00:39:50.210 --> 00:39:51.790
weil die ist nämlich was sehr, sehr, sehr Cooles.

00:39:52.650 --> 00:39:53.930
Und die ist was, was auch für Leute,

00:39:54.050 --> 00:39:55.590
die das nicht kennen, super schwer zu verstehen

00:39:55.590 --> 00:39:57.670
ist.

00:39:59.870 --> 00:40:00.230
Diese

00:40:00.230 --> 00:40:02.370
Dictionary-Comprehension ist eine der

00:40:02.370 --> 00:40:04.110
coolsten Wege, die es gibt, so ein

00:40:04.110 --> 00:40:06.330
Dictionary zu bauen, weil es halt im Wesentlichen

00:40:06.330 --> 00:40:08.090
diese Schleife, die man dazu

00:40:08.090 --> 00:40:09.770
braucht, in das Dictionary reintut.

00:40:11.010 --> 00:40:12.250
Also in die Konstruktion.

00:40:13.510 --> 00:40:14.090
Und das

00:40:14.090 --> 00:40:15.810
ist was sehr, sehr Mächtiges.

00:40:16.250 --> 00:40:18.030
Die Syntax davon jetzt hier im Podcast zu besprechen,

00:40:18.130 --> 00:40:18.430
ist vielleicht schwierig.

00:40:18.430 --> 00:40:21.110
Muss man sich ansehen.

00:40:21.570 --> 00:40:23.130
Aber das ist auf jeden Fall was, was man ansehen kann.

00:40:23.710 --> 00:40:26.110
Ich habe vorhin noch einen sehr coolen Trick gelernt und das ist

00:40:26.110 --> 00:40:28.090
DictSip. Also wenn ich

00:40:28.090 --> 00:40:30.130
eine Liste von Keys habe und eine Liste von

00:40:30.130 --> 00:40:30.650
Values,

00:40:31.850 --> 00:40:33.930
dann kann ich die sippen und dann

00:40:33.930 --> 00:40:34.650
einen Dick Schnee draus machen.

00:40:36.090 --> 00:40:37.650
Das geht auch nur für gleich lange Listen, ne?

00:40:39.430 --> 00:40:40.190
SIP nimmt auch

00:40:40.190 --> 00:40:42.070
unterschiedlich lange Listen und schneidet dann halt den Rest ab.

00:40:42.450 --> 00:40:43.930
Aber das ist, glaube ich, nicht der Sinn der Sache.

00:40:44.030 --> 00:40:45.930
Der Sinn der Sache ist, du hast schon die Keys und du hast schon

00:40:45.930 --> 00:40:47.930
die Values, aber in zwei Händen und mit SIP

00:40:47.930 --> 00:40:49.370
kannst du sie in

00:40:49.370 --> 00:40:51.650
eine schöne Reihenfolge bringen, die das Dick Schnee...

00:40:51.650 --> 00:40:52.710
Einmal Reißverschluss, bitte.

00:40:53.270 --> 00:40:57.710
So, wie kann man denn

00:40:57.710 --> 00:40:59.450
da Sachen wieder rauskriegen? Dominik, weißt du,

00:40:59.650 --> 00:41:01.570
ich frage dich jetzt ab, ich finde das total gut.

00:41:03.310 --> 00:41:06.470
Wie komme ich an die Werte wieder dran?

00:41:07.750 --> 00:41:08.490
Ja, du kannst einfach

00:41:08.490 --> 00:41:10.410
Wenn ich jetzt ein Telefonbuch habe,

00:41:10.470 --> 00:41:11.610
wie kriege ich deine Telefonnummer raus?

00:41:11.950 --> 00:41:13.810
Du machst halt zum Beispiel entweder ein Get oder halt mit der

00:41:13.810 --> 00:41:15.310
Brackets-Syntax ziehst du die Key direkt raus.

00:41:15.310 --> 00:41:15.910
Was ist da der Unterschied?

00:41:16.670 --> 00:41:19.670
Bei Get kriegst du einen Default-Wert zurück und du kriegst

00:41:19.670 --> 00:41:21.730
einen Error, wenn du

00:41:21.730 --> 00:41:24.050
daraus einen versuchst, eine Key zu lesen, die es nicht gibt.

00:41:24.490 --> 00:41:25.630
Genau, wenn du es mit eckigen Klammern machst,

00:41:25.630 --> 00:41:27.290
kriegst du im besten Fall einen Key-Error.

00:41:28.490 --> 00:41:29.830
Der heißt tatsächlich Key-Error.

00:41:30.030 --> 00:41:30.970
Also wenn man das abfangen möchte,

00:41:31.330 --> 00:41:33.150
gibt es das heißt. Genau, also beim Get kannst du halt

00:41:33.150 --> 00:41:35.150
dann den Default dann dranhängen. Es gibt noch

00:41:35.150 --> 00:41:37.030
zwei andere coole. Ich wollte die Frage beantworten.

00:41:37.290 --> 00:41:39.130
Es gibt noch zwei andere coole Attribute, die heißen

00:41:39.130 --> 00:41:40.730
Pop und Pop Item.

00:41:41.590 --> 00:41:41.730
Ja.

00:41:43.230 --> 00:41:45.170
Und die sind quasi

00:41:45.170 --> 00:41:46.930
destruktiv, sie sind destruktiver Zugriff.

00:41:47.590 --> 00:41:49.030
Wenn ich sage, wie aus einer Liste

00:41:49.030 --> 00:41:51.050
wird der Key entfernt. Dominik?

00:41:51.430 --> 00:41:53.270
Ja. Dann heißt es

00:41:53.270 --> 00:41:55.150
entferne den Eintrag für Dominik,

00:41:55.290 --> 00:41:56.550
aber gib mir den Wert auch noch zurück.

00:41:57.210 --> 00:41:59.290
Wie bei einer Liste. Wie bei einer Liste,

00:41:59.290 --> 00:42:01.290
genau. Also, ja gut, halt mit diesem Key

00:42:01.290 --> 00:42:03.330
Zugriff. Bei POP muss ich immer den

00:42:03.330 --> 00:42:05.210
Key sagen, bei einer Liste müsste ich den Index

00:42:05.210 --> 00:42:07.170
sagen. Genau, also

00:42:07.170 --> 00:42:09.150
er gibt dir den ersten Wert, was natürlich beim

00:42:09.150 --> 00:42:11.150
DIC nicht geht, weil das nur einer ist. Genau, das heißt

00:42:11.150 --> 00:42:13.350
DIC.POP muss immer einen Key haben.

00:42:13.750 --> 00:42:15.330
Es gibt da keinen ersten

00:42:15.330 --> 00:42:16.450
oder letzten oder wie auch immer.

00:42:17.770 --> 00:42:19.030
Aber es gibt POP-Item.

00:42:20.590 --> 00:42:21.350
Und POP-Item

00:42:21.350 --> 00:42:23.490
das

00:42:23.490 --> 00:42:24.450
macht LIFO,

00:42:25.070 --> 00:42:27.270
Last In, First Out. Das heißt, es gibt dir

00:42:27.270 --> 00:42:29.530
tatsächlich den letzten Eintrag,

00:42:30.190 --> 00:42:31.210
der hinzugefügt wurde,

00:42:31.210 --> 00:42:32.650
zurück als Item mit Key und Value.

00:42:32.670 --> 00:42:34.870
Dann braucht man den Key nicht mehr. Das ist natürlich interessant.

00:42:35.270 --> 00:42:37.150
Als Key und Value. Das ist schon

00:42:37.150 --> 00:42:39.210
sehr cool. Das heißt,

00:42:39.290 --> 00:42:41.030
du kannst so eine While-Schleife machen

00:42:41.030 --> 00:42:43.110
und kannst dieses Dictionary sozusagen

00:42:43.110 --> 00:42:43.770
abarbeiten.

00:42:44.670 --> 00:42:46.890
Und hast dann so eine Art Dictionary-Key. Und das ist

00:42:46.890 --> 00:42:48.910
eine praktische Sache,

00:42:49.110 --> 00:42:50.690
die ich erst heute gelesen habe.

00:42:50.970 --> 00:42:53.130
Ja, sehr schön. Ne, habe ich auch so noch

00:42:53.130 --> 00:42:55.010
nicht verwendet, aber da fallen mir auch direkt viele

00:42:55.010 --> 00:42:57.170
Sachen zu ein, die man damit cool machen kann.

00:42:57.590 --> 00:42:57.750
Ja.

00:42:58.750 --> 00:43:00.270
Wo man so ein Dictionary zerlegen kann.

00:43:01.210 --> 00:43:09.750
Und ja, es gibt auch noch SetDefault. Ich weiß nicht, ob man das Leuten überhaupt erzählen sollte, dass es die Methode noch gibt.

00:43:10.190 --> 00:43:10.910
Nein, das darf man nicht sagen.

00:43:10.930 --> 00:43:12.450
Das darf man nicht sagen. Die ist eigentlich nicht gut.

00:43:12.730 --> 00:43:23.710
Also die liefert halt auch quasi das zurück, aber mit einem Default, den man dann noch angeben kann, wenn das nicht existiert.

00:43:24.530 --> 00:43:28.070
Ja, stimmt. Wo ich anfange, das zu erklären, fällt mir schon ein, dass es vielleicht keine gute Idee ist.

00:43:28.070 --> 00:43:30.430
Es ist, glaube ich, besser, da direkt ein Default-Tick zu verwenden.

00:43:31.030 --> 00:43:32.630
Genau, das ist auch die Empfehlung. Sollte man halt

00:43:32.630 --> 00:43:34.230
heutzutage eher Default-Dict nehmen. Oder Get.

00:43:34.630 --> 00:43:35.850
Ein Get und dann den Wert setzen.

00:43:37.490 --> 00:43:39.010
Wo ist da ein Unterschied zwischen Get und Wertsetzen

00:43:39.010 --> 00:43:39.610
und Default-Dict?

00:43:40.950 --> 00:43:42.590
Dafür müssen wir erst wissen, was ein Default-Dict ist.

00:43:42.730 --> 00:43:44.170
Dann erzähl mir, was ein Default-Dict ist.

00:43:44.930 --> 00:43:46.950
Ein Default-Dict ist ein Dictionary.

00:43:47.230 --> 00:43:48.850
Eine Unterklasse von Dictionary.

00:43:48.890 --> 00:43:50.950
Das keine Keys hat, aber wenn du einen Key abrufen

00:43:50.950 --> 00:43:52.670
willst, den es noch nicht gibt, dann gib dir den Default-Wert zurück.

00:43:53.150 --> 00:43:54.750
Genau. Du sagst eben,

00:43:54.870 --> 00:43:56.690
welchen Standardwert es haben soll und wenn du

00:43:56.690 --> 00:43:58.930
einen Key abrufst, den es noch nicht gibt, kriegst du den Standardwert.

00:43:59.650 --> 00:44:00.470
Und da gibt es

00:44:00.470 --> 00:44:02.250
drei große Varianten

00:44:02.250 --> 00:44:04.110
davon. Die erste ist die Lambda-Variante,

00:44:04.490 --> 00:44:06.110
wo du halt eine Funktion

00:44:06.110 --> 00:44:08.130
reingibst, die dann diesen Standardwert

00:44:08.130 --> 00:44:08.650
erzeugt.

00:44:10.270 --> 00:44:12.010
Und das ist sozusagen die allgemeine. Das ist

00:44:12.010 --> 00:44:14.110
Default-Dict. Du musst dem Default-Dict irgendeine

00:44:14.110 --> 00:44:15.950
sogenannte Factory geben, damit er diesen Wert

00:44:15.950 --> 00:44:18.090
erzeugen kann. Und da kannst du jede

00:44:18.090 --> 00:44:20.050
beliebige Funktion reintun. Meistens ist das halt irgendeine

00:44:20.050 --> 00:44:22.110
kleine Lernversion. Aber es gibt schon

00:44:22.110 --> 00:44:24.030
zwei Funktionen, die du da verwenden kannst, nämlich List

00:44:24.030 --> 00:44:24.470
und Int,

00:44:25.770 --> 00:44:27.830
die nützlich sind. Also wenn du

00:44:27.830 --> 00:44:29.870
Default-Dict, Klammer auf, List,

00:44:29.970 --> 00:44:31.770
Klammer zu machst, dann heißt

00:44:31.770 --> 00:44:33.590
es, das ist ein Dictionary und wenn du da einen Key

00:44:33.590 --> 00:44:35.610
abrufst, dann

00:44:35.610 --> 00:44:37.670
gibt er dir, wenn du noch nichts eingefügt hast

00:44:37.670 --> 00:44:39.150
für diesen Key, eine leere Liste zurück.

00:44:39.750 --> 00:44:40.730
Eine neue leere Liste.

00:44:42.910 --> 00:44:43.690
Und genauso

00:44:43.690 --> 00:44:45.270
für Int. Wenn du

00:44:45.270 --> 00:44:47.690
ein Default-Dict

00:44:47.690 --> 00:44:49.430
Int hast, dann kannst du

00:44:49.430 --> 00:44:51.430
jeden beliebigen Key abrufen und kriegst 0

00:44:51.430 --> 00:44:51.710
zurück.

00:44:53.610 --> 00:44:53.730
Ja.

00:44:55.050 --> 00:44:57.050
Du kannst einen Counter machen, dass der immer geht auf das.

00:44:57.550 --> 00:44:58.990
Ja, aber Counter gibt es auch.

00:44:59.330 --> 00:45:00.490
Da gibt es schon eine Klasse für, ja.

00:45:01.110 --> 00:45:02.810
Und die ist richtig cool, diese Counter-Klasse.

00:45:02.910 --> 00:45:04.450
Die müssen wir uns auch gleich noch besprechen.

00:45:04.770 --> 00:45:06.250
Okay, wofür würde ich Default-Dict verwenden?

00:45:07.770 --> 00:45:10.110
Das klassische Beispiel ist, wenn man sich so einen Counter baut.

00:45:10.430 --> 00:45:12.570
Aber nochmal, wenn du das gleiche nochmal aufrufst,

00:45:12.650 --> 00:45:14.210
dann gibt man natürlich den neuen Wert zurück, ne?

00:45:14.450 --> 00:45:18.250
Genau, also wenn du einen Wert in dieses Default-Dict reinspeicherst,

00:45:18.950 --> 00:45:20.330
dann ist es wie ein normales Dictionary, ja?

00:45:20.410 --> 00:45:22.110
Also wenn es diesen Key schon gibt,

00:45:22.290 --> 00:45:23.670
dann kriegst du das, was da gespeichert wurde.

00:45:23.770 --> 00:45:26.270
Das kann auch was anderes sein als ein Int oder eine Liste, ja?

00:45:26.750 --> 00:45:28.090
Das heißt, es ist nicht eine Typisierung,

00:45:28.270 --> 00:45:29.750
sondern das ist nur so dieser Fallback.

00:45:30.410 --> 00:45:31.390
Da ist nochmal noch eine

00:45:31.390 --> 00:45:33.670
Zwischenfrage, ein kleiner Express. Wenn ich jetzt da

00:45:33.670 --> 00:45:35.990
ein Get mache auf so eine Liste, ja, auf so ein Default-Dict

00:45:35.990 --> 00:45:38.010
von der Liste und ich habe dann

00:45:38.010 --> 00:45:39.970
eine leere Liste in der Hand und ich schreibe in die was

00:45:39.970 --> 00:45:41.690
rein, beim nächsten Mal auf

00:45:41.690 --> 00:45:43.950
denselben Key gibt der mir dann diese Liste,

00:45:44.050 --> 00:45:44.610
in der was drin ist?

00:45:45.390 --> 00:45:45.590
Nee.

00:45:47.850 --> 00:45:49.790
Warum nicht? Das wäre das, was Jochen

00:45:49.790 --> 00:45:51.210
vorher gesagt hat, das wäre SetDefault.

00:45:52.670 --> 00:45:54.050
Weil du beim Abrufen

00:45:54.050 --> 00:45:55.990
entweder den Wert kriegst,

00:45:56.090 --> 00:45:57.870
der in dem Dictionary drin ist,

00:45:58.270 --> 00:46:01.930
oder den, den die Factory erzeugt.

00:46:02.090 --> 00:46:05.070
Aber der wird nicht automatisch in dieses Dictionary abgelegt.

00:46:05.450 --> 00:46:07.290
Aber das ist doch bei Listen, haben wir doch das Problem,

00:46:07.370 --> 00:46:09.250
dass dann das Objekt der Liste dann es doch schon gibt

00:46:09.250 --> 00:46:11.230
und dass das Objekt dieser Liste, auf das dann ja ...

00:46:11.230 --> 00:46:12.870
Genau, aber die wird nicht in das Dictionary abgelegt.

00:46:14.470 --> 00:46:16.970
Du kriegst dann eine neue Liste, die du nur in der Hand hast.

00:46:17.150 --> 00:46:18.270
Und du musst die dann tatsächlich zugreifen.

00:46:19.130 --> 00:46:21.230
Wenn du das möchtest, dass du eine Liste abrufst

00:46:21.230 --> 00:46:23.290
und die dann bearbeiten kannst, dann musst du SetDefault machen.

00:46:24.370 --> 00:46:27.750
Und SetDefault heißt, ruf einen Key ab, wenn es den schon gibt,

00:46:27.850 --> 00:46:29.790
gib mir das, was da drin ist, ansonsten setze

00:46:29.790 --> 00:46:31.770
in dem Dictionary den Wert, den ich dir

00:46:31.770 --> 00:46:33.650
da als Default angebe und

00:46:33.650 --> 00:46:35.790
gib ihn mir zurück. Okay, ja, das

00:46:35.790 --> 00:46:37.690
dachte ich, dass wäre das, was Default-Dictionary machen würde, okay,

00:46:37.770 --> 00:46:39.330
das heißt, dafür muss ich Set-Default machen.

00:46:39.770 --> 00:46:41.130
Genau, dafür musst du das Set-Default machen.

00:46:42.490 --> 00:46:43.950
Ja, aber es ist, die Funktion

00:46:43.950 --> 00:46:45.570
ist Set-Default, also sie ist in mehrerer

00:46:45.570 --> 00:46:47.750
Hinsicht verwirrend, sie ist auch verwirrend benannt,

00:46:47.890 --> 00:46:49.470
wie man es auch gerade wieder sehen konnte

00:46:49.470 --> 00:46:51.690
und vielleicht sollte man das echt mehr, weil

00:46:51.690 --> 00:46:53.730
tatsächlich, wenn man so eine Default-Dict macht, ist es sauberer

00:46:53.730 --> 00:46:55.650
und ja, genau,

00:46:55.750 --> 00:46:57.170
was ich noch anmerken wollte zu den

00:46:57.170 --> 00:46:59.270
Factory-Funktionen, die man übergeben muss. Also es kann

00:46:59.270 --> 00:47:01.370
eine beliebige Funktion sein. Die einzige Bedingung ist,

00:47:01.690 --> 00:47:03.010
sie darf keine Argumente

00:47:03.010 --> 00:47:03.610
nehmen.

00:47:05.150 --> 00:47:07.330
Wenn man jetzt so mehrfach verschachtelte

00:47:07.330 --> 00:47:08.550
Geschichten baut, das geht.

00:47:09.370 --> 00:47:11.230
Aber das wird dann auch relativ schnell relativ

00:47:11.230 --> 00:47:11.950
unübersichtlich.

00:47:14.130 --> 00:47:15.350
Ich habe noch keine gute Lösung

00:47:15.350 --> 00:47:17.270
dafür, aber das ist, dann muss man halt

00:47:17.270 --> 00:47:19.190
da, das sieht dann komisch aus, aber ja.

00:47:19.830 --> 00:47:21.350
Das ist ein bisschen blöd, wenn es keine Argumente sein können.

00:47:22.910 --> 00:47:23.710
Also Factory-Story

00:47:23.710 --> 00:47:25.230
würde man ja gerne mal auf eine bestimmte Art und Weise

00:47:25.230 --> 00:47:27.230
initialisieren. Ja, das muss man ja

00:47:27.230 --> 00:47:29.210
irgendwie von einer, die Falltrack irgendwie alles

00:47:29.210 --> 00:47:30.850
schon erben und muss das dann irgendwie schon hinstecken.

00:47:31.570 --> 00:47:32.790
Ja, aber da gibt es etwas,

00:47:33.410 --> 00:47:35.030
also zumal, wenn man jetzt

00:47:35.030 --> 00:47:36.970
bei unterschiedlichen Keys unterschiedliche Sachen

00:47:36.970 --> 00:47:39.090
machen möchte, es kann ja manchmal sein,

00:47:39.530 --> 00:47:41.010
du sagst so, wenn ich diesen Key habe, okay,

00:47:41.110 --> 00:47:43.070
dann möchte ich ja gar keine Liste dazu machen, sondern was

00:47:43.070 --> 00:47:43.910
ganz anderes oder so.

00:47:44.810 --> 00:47:46.950
Und dann geht das mit dem Default-Tick ja alles

00:47:46.950 --> 00:47:48.990
so nicht mehr so richtig, eben deswegen, weil man kann

00:47:48.990 --> 00:47:50.910
halt nicht ein Argument angeben,

00:47:50.990 --> 00:47:52.750
was man dann, also das ist,

00:47:53.210 --> 00:47:54.830
das geht dann nicht mehr. Da gibt es aber auch etwas

00:47:54.830 --> 00:47:56.730
sehr cool ist, was ich auch erst in der Vorbereitung, ich habe ja

00:47:56.730 --> 00:47:58.770
einfach nochmal geguckt, was zu

00:47:58.770 --> 00:48:00.670
dieser Episode, habe ich mir nochmal so ein bisschen

00:48:00.670 --> 00:48:02.710
angeguckt, was habe ich denn an Literatur zu Dicts

00:48:02.710 --> 00:48:04.710
steht da irgendwas Interessantes drin und habe ich tatsächlich

00:48:04.710 --> 00:48:06.730
etwas gefunden, was ich noch nicht wusste, wo ich auch sagen

00:48:06.730 --> 00:48:08.730
würde, oh cool, dass ich das jetzt weiß und zwar

00:48:08.730 --> 00:48:10.750
gibt es Dunder Missing

00:48:10.750 --> 00:48:14.670
als sozusagen Spezial

00:48:14.670 --> 00:48:16.950
Methode, die man überschreiten kann,

00:48:17.530 --> 00:48:18.590
wo man dann den Key bekommt.

00:48:18.690 --> 00:48:20.710
Das ist quasi der Key Error. Du kannst den Key Error

00:48:20.710 --> 00:48:21.610
überschreiben. Ja.

00:48:22.390 --> 00:48:24.530
Mach dann Default Dict, mache ich dann eine neue Klasse, die von

00:48:24.530 --> 00:48:26.750
DefaultDictErben, du beschreibst dann dann Missing und guck

00:48:26.750 --> 00:48:28.770
dann mit einem MatchCaseStatement, was

00:48:28.770 --> 00:48:30.430
da drin ist. Genau, oder

00:48:30.430 --> 00:48:32.850
du kannst von DefaultDictErben,

00:48:32.950 --> 00:48:34.810
na klar, aber das musst du dann ja

00:48:34.810 --> 00:48:36.750
im Grunde nicht mehr, weil wenn du die Methode überschreibst,

00:48:36.810 --> 00:48:37.910
dann bestimmst du ja selber, was passiert.

00:48:39.250 --> 00:48:40.570
Und da kannst du alles. Das ging

00:48:40.570 --> 00:48:41.750
früher übrigens auch nicht.

00:48:42.450 --> 00:48:44.670
Konnte früher nicht von DictErben, deshalb gibt es noch eine Klasse, die

00:48:44.670 --> 00:48:45.370
UserDict heißt.

00:48:46.490 --> 00:48:48.690
Das heißt tatsächlich, ich mache tatsächlich so was

00:48:48.690 --> 00:48:50.670
ähnliches wie UserDict und ich mache eine neue Klasse auf die

00:48:50.670 --> 00:48:52.650
Erb einfach von Dict und da überschreibe ich dann nur die

00:48:52.650 --> 00:48:54.650
Misting-Methode und dann gucke ich halt, was das ist, statt dem

00:48:54.650 --> 00:48:56.850
Key-Error jetzt rauszugeben, dass er dann tatsächlich

00:48:56.850 --> 00:48:57.510
irgendwas Neues anstellt.

00:48:57.890 --> 00:49:00.550
Das würde auch tatsächlich funktionieren, aber

00:49:00.550 --> 00:49:02.530
es wird,

00:49:02.870 --> 00:49:04.550
diese Diskussion hatten wir in dem

00:49:04.550 --> 00:49:06.830
Python User Group Düsseldorf

00:49:06.830 --> 00:49:08.750
Channel auch vor kurzem,

00:49:08.850 --> 00:49:10.950
ob es denn okay ist, von Dict zu erben

00:49:10.950 --> 00:49:12.870
oder wenn man lieber von UserDict erben soll oder so

00:49:12.870 --> 00:49:14.810
und ich hatte das halt noch so im Hinterkopf,

00:49:15.070 --> 00:49:16.690
dass man von UserDict erben soll und nicht von Dict

00:49:16.690 --> 00:49:19.010
und tatsächlich

00:49:19.010 --> 00:49:20.810
habe ich jetzt auch nochmal nachgeguckt

00:49:20.810 --> 00:49:22.870
und nee, man soll von UserDict erben

00:49:22.870 --> 00:49:24.670
und nicht von Dict. Also man kann das ja

00:49:24.670 --> 00:49:26.650
zwar jetzt, aber... Was ist da der

00:49:26.650 --> 00:49:28.470
Unterschied? Also der entscheidende

00:49:28.470 --> 00:49:30.590
Unterschied, warum das unter Umständen

00:49:30.590 --> 00:49:32.330
einem Probleme machen kann, ist,

00:49:33.130 --> 00:49:33.910
dass

00:49:33.910 --> 00:49:36.810
bestimmte Methoden

00:49:36.810 --> 00:49:38.470
halt, also Missing ist jetzt, die

00:49:38.470 --> 00:49:40.550
funktioniert, die kann man überschreiben, aber bestimmte andere

00:49:40.550 --> 00:49:42.490
nicht. Und wenn du dann Dict auf bestimmte

00:49:42.490 --> 00:49:44.610
andere Arten, wenn du da Sachen mit

00:49:44.610 --> 00:49:46.650
machst, dann geht das

00:49:46.650 --> 00:49:48.150
an den Methoden, die du überschrieben hast, vorbei.

00:49:48.650 --> 00:49:49.910
Das heißt, wenn du von Dict

00:49:49.910 --> 00:49:51.650
von dem Build-in diktierst

00:49:51.650 --> 00:49:53.990
und dann überschreibst du halt

00:49:53.990 --> 00:49:55.970
irgendeine Methode und denkst, ja, müsste doch funktionieren,

00:49:56.050 --> 00:49:58.070
dann funktioniert es manchmal halt vielleicht nicht, weil

00:49:58.070 --> 00:49:59.910
zum Beispiel, also auch der Konstruktor

00:49:59.910 --> 00:50:01.830
davon ist halt so, der schreibt das halt

00:50:01.830 --> 00:50:03.990
irgendwie direkt, der geht nicht über die

00:50:03.990 --> 00:50:05.830
Set-Item, Get-Item-Geschichten,

00:50:05.930 --> 00:50:07.890
die es da halt normalerweise geht. Das heißt,

00:50:07.990 --> 00:50:09.670
dann verhält sich das Ding unter Umständen

00:50:09.670 --> 00:50:12.050
unerwartet und ja, Laufzeitverhalten

00:50:12.050 --> 00:50:13.550
ist auch so ein bisschen anders, also

00:50:13.550 --> 00:50:15.830
und, ja, das habe ich jetzt aber auch

00:50:15.830 --> 00:50:17.590
wieder vergessen, also es war auch irgendwie, ist eine

00:50:17.590 --> 00:50:19.630
wichtige Geschichte, warum das, wenn das

00:50:19.630 --> 00:50:21.390
im Data-Attribut ist und sozusagen die

00:50:21.390 --> 00:50:22.910
Zugriffe dahin nur delegiert werden,

00:50:23.530 --> 00:50:25.430
das macht auch irgendwie, ich glaube, es kann sogar sein, dass

00:50:25.430 --> 00:50:27.390
das der Grund ist, weshalb man Set-Item, Get-Item

00:50:27.390 --> 00:50:29.510
dann überhaupt quasi richtig überschreiben

00:50:29.510 --> 00:50:31.230
kann, weil wenn das halt

00:50:31.230 --> 00:50:33.250
delegiert wird. Ja, genau, genau.

00:50:33.250 --> 00:50:34.650
Ja, und daher

00:50:34.650 --> 00:50:36.430
sollte man, wenn man das selber,

00:50:36.670 --> 00:50:39.150
wenn man erben will und will Sachen überschreiben,

00:50:39.250 --> 00:50:40.870
dann lieber UserDict nehmen, statt

00:50:40.870 --> 00:50:42.750
einfach vom Build-In erben. Also

00:50:42.750 --> 00:50:44.030
UserDict ist quasi

00:50:44.030 --> 00:50:47.250
eine Klasse, die das gleiche Interface hat

00:50:47.250 --> 00:50:48.610
wie Dictionary. Ja.

00:50:49.030 --> 00:50:50.910
aber eben ein Attribut

00:50:50.910 --> 00:50:52.010
heißt, das heißt Data

00:50:52.010 --> 00:50:54.770
und das ist ein Dictionary und

00:50:54.770 --> 00:50:56.890
einfach alles durchreicht an dieses Data.

00:50:57.250 --> 00:50:58.830
Genau. Und das bedeutet, dass wenn

00:50:58.830 --> 00:51:00.710
ich von UserDict ableite, kann ich jede beliebige

00:51:00.710 --> 00:51:02.830
Methode überschreiben und die wird dann auch

00:51:02.830 --> 00:51:05.170
korrekt aufgerufen, auch Konstruktor und alles mögliche.

00:51:05.330 --> 00:51:05.570
Ja, genau.

00:51:07.970 --> 00:51:08.330
Ja.

00:51:09.090 --> 00:51:10.750
Ja, okay, wusste ich auch nicht. Ich wusste nicht,

00:51:10.830 --> 00:51:12.830
dass es da Unterschiede gibt. Ja, es ist immer wieder interessant, auch wenn

00:51:12.830 --> 00:51:14.890
ich dachte, also ich meine, das verwendet man ja jeden Tag

00:51:14.890 --> 00:51:16.550
und irgendwie schon ganz lange und so und

00:51:16.550 --> 00:51:18.770
dann ist es so, kann ja eigentlich nichts Neues mehr.

00:51:19.030 --> 00:51:20.570
Aber manchmal so, ja.

00:51:20.890 --> 00:51:23.490
Aber das ist was, was man doch relativ selten macht von Dictionary.

00:51:24.650 --> 00:51:25.310
Also generell von

00:51:25.310 --> 00:51:26.530
Build-ins, so Sachen,

00:51:26.710 --> 00:51:28.090
fühlt sich immer so ein bisschen komisch an.

00:51:28.090 --> 00:51:29.490
Ja, ist nicht so häufig.

00:51:30.790 --> 00:51:32.470
Die sind einfach gut genug.

00:51:34.090 --> 00:51:34.890
Beziehungsweise, wenn man

00:51:34.890 --> 00:51:36.890
eine neue Datastruktur sich schreibt,

00:51:37.010 --> 00:51:38.850
dann benutzt man normalerweise eben eine

00:51:38.850 --> 00:51:41.210
und leidet nicht direkt

00:51:41.210 --> 00:51:43.070
davon ab. So ist meine Erfahrung.

00:51:43.150 --> 00:51:45.030
Instanziert die dann irgendwie so mit so einem

00:51:45.030 --> 00:51:47.010
Injektor-Pattern oder sowas, dass man die halt dann benutzt.

00:51:47.010 --> 00:51:48.830
Genau, dieses Data, dass da halt

00:51:48.830 --> 00:51:50.850
sagst, okay, mein Baum ist

00:51:50.850 --> 00:51:52.870
eigentlich eine Liste, aber

00:51:52.870 --> 00:51:54.950
ich habe

00:51:54.950 --> 00:51:56.990
eine Liste, die das macht. Ich habe nicht das Interface

00:51:56.990 --> 00:51:58.950
von Liste geerbt, sondern ich habe halt eine

00:51:58.950 --> 00:51:59.670
in der Hand, die das macht.

00:52:01.250 --> 00:52:03.170
Das ist so meine Erfahrung. Ich weiß nicht, wie ihr das seht.

00:52:03.550 --> 00:52:05.410
Doch, doch. Nee, ich sehe das

00:52:05.410 --> 00:52:06.890
ganz genauso.

00:52:07.010 --> 00:52:08.830
Achso, genau, das ist auch noch der eine

00:52:08.830 --> 00:52:10.630
Grund dafür, warum

00:52:10.630 --> 00:52:12.950
das mit dem Delegieren eine gute Idee

00:52:12.950 --> 00:52:14.910
ist, weil halt ansonsten, wenn du direkt erbst,

00:52:15.530 --> 00:52:16.950
dann hat

00:52:16.950 --> 00:52:19.530
dein Objekt eine ganze Menge Methoden,

00:52:19.530 --> 00:52:21.450
die halt unsinnig

00:52:21.450 --> 00:52:23.250
sind unter Umständen. Also

00:52:23.250 --> 00:52:25.170
in einem Kontext, wo man sich dann fragt, wenn man so

00:52:25.170 --> 00:52:27.750
Dia macht auf dein Objekt.

00:52:27.750 --> 00:52:29.680
Und dann sieht man halt einen ganzen Haufen komisches

00:52:29.680 --> 00:52:31.740
Zeug, wo man sich dann so, hä, warum ist das denn alles da drin?

00:52:32.100 --> 00:52:33.360
Was man halt einfach so mitbekommt,

00:52:33.600 --> 00:52:35.220
wenn man das, wenn man da direkt erbt.

00:52:36.800 --> 00:52:37.760
Also, ja.

00:52:38.540 --> 00:52:39.660
Okay, ich frage mich alles.

00:52:39.660 --> 00:52:40.320
Das ist dieses Interesse.

00:52:40.660 --> 00:52:43.260
Wir müssen noch so ein paar Sachen, ich habe jetzt meine Notizenliste,

00:52:43.260 --> 00:52:45.120
die ist leider gerade leer gegangen, aber

00:52:45.120 --> 00:52:47.560
da ist so ein

00:52:47.560 --> 00:52:48.720
Ladegerät und da ist so ein,

00:52:48.720 --> 00:52:50.400
das kannst du dein Telefon anschließen.

00:52:50.420 --> 00:52:52.100
Oh, du hast USB-C? Wow.

00:52:52.480 --> 00:52:54.400
Als Apple-Haushalt USB-C.

00:52:54.500 --> 00:52:55.860
Ja, ja, brauchen wir das schon?

00:52:56.780 --> 00:52:58.720
Cool. Es gibt eine Methode

00:52:58.720 --> 00:53:00.840
in Dictionary, wo wir gerade über das

00:53:00.840 --> 00:53:02.380
Dictionary-Interface sprechen,

00:53:02.780 --> 00:53:04.020
die ist in 3.9 dazugekommen.

00:53:04.900 --> 00:53:06.960
In 3.9 hat sich das Dictionary-Interface

00:53:06.960 --> 00:53:08.100
verändert. Okay.

00:53:08.960 --> 00:53:11.160
Und zwar ist der Pipe-Operator

00:53:11.160 --> 00:53:12.780
dazugekommen. Ah, ja, richtig.

00:53:13.120 --> 00:53:13.760
Ja, klar, natürlich.

00:53:14.820 --> 00:53:16.640
Und das ist sowas, was,

00:53:16.920 --> 00:53:18.440
wenn man das braucht, dann ist das

00:53:18.440 --> 00:53:20.840
ungeheuer wichtig und wenn man es nicht

00:53:20.840 --> 00:53:22.560
braucht, dann ist es so, okay.

00:53:22.960 --> 00:53:24.980
Nie gedacht, dass jemand sowas brauchen könnte.

00:53:25.720 --> 00:53:27.340
Das ist Dictionary-Vereinigung.

00:53:27.800 --> 00:53:29.240
Ja, Unions zwischen von Dicts.

00:53:29.660 --> 00:53:31.380
Genau, da gibt es jetzt den Operator dafür.

00:53:31.480 --> 00:53:32.220
Früher musste man immer,

00:53:33.240 --> 00:53:34.960
jede von uns hat so eine Sammlung von Tricks,

00:53:35.080 --> 00:53:36.760
wie man Dictionaries vereinigt.

00:53:37.440 --> 00:53:39.260
Ja, das ist ganz einfach mit Stern, Stern

00:53:39.260 --> 00:53:40.800
und unter Dictionary und

00:53:40.800 --> 00:53:43.300
ja, und das

00:53:43.300 --> 00:53:44.900
gibt es jetzt als Operator und auch mit

00:53:44.900 --> 00:53:47.240
Pipe gleich, also man kann auch gleich rein

00:53:47.240 --> 00:53:49.380
vereinigen, wobei das einfach ein Update

00:53:49.380 --> 00:53:50.360
ist, meiner Meinung nach, oder?

00:53:51.660 --> 00:53:53.120
Oh, das würde ich jetzt ausprobieren,

00:53:53.180 --> 00:53:54.700
das weiß ich auch nicht, aber es stimmt, ich

00:53:54.700 --> 00:53:57.660
ich wusste, dass das passiert ist, ich habe es aber nie

00:53:57.660 --> 00:53:59.580
verwendet seitdem, daher ist es

00:53:59.580 --> 00:54:01.680
mir jetzt gar nicht mehr bewusst, dass es diese Erinnerung gab.

00:54:01.940 --> 00:54:02.880
Ein Update ist ja Union,

00:54:03.800 --> 00:54:05.080
ist es exklusiv, ist die Frage.

00:54:06.400 --> 00:54:07.600
Es ist immer exklusiv,

00:54:07.700 --> 00:54:08.960
weil du ja keine Keys verdoppelt hast.

00:54:08.960 --> 00:54:11.500
Ja, aber dann geht das nicht mehr im Update, weil bei Update werden ja nur die Keys

00:54:11.500 --> 00:54:13.300
geupdatet, die in dem Update enthalten sind.

00:54:13.880 --> 00:54:15.260
Nee, die .update,

00:54:15.480 --> 00:54:17.200
dictionary.update übernimmt

00:54:17.200 --> 00:54:19.660
alle Keys und Values aus dem

00:54:19.660 --> 00:54:21.680
Herangebiet. Genau, aber die, die es noch nicht drin waren.

00:54:21.680 --> 00:54:24.000
Genau, aber wenn welche vorher schon drin waren

00:54:24.000 --> 00:54:24.940
und die dann überschrieben werden.

00:54:24.960 --> 00:54:25.280
Dann werden die überschrieben.

00:54:25.480 --> 00:54:26.880
Genau, aber wenn die vorher schon drin wären,

00:54:26.940 --> 00:54:27.180
die nicht.

00:54:27.200 --> 00:54:27.920
Das ist bei Vereinigung aber genauso.

00:54:28.100 --> 00:54:29.600
Nein, aber wenn die vorher schon drin waren

00:54:29.600 --> 00:54:31.120
und nicht in dem neuen drin sind,

00:54:31.160 --> 00:54:32.340
dann sind die, wie sie vorher waren.

00:54:32.600 --> 00:54:34.500
Aber wenn du den Union Operator gleich machst,

00:54:34.620 --> 00:54:36.220
dann sind sie eben nicht mehr drin,

00:54:37.560 --> 00:54:39.180
weil sie halt nicht in dem Update sind.

00:54:40.660 --> 00:54:41.540
Das verstehe ich jetzt nicht.

00:54:41.840 --> 00:54:43.660
Okay, du hast zwei einigermaßen disziplinierte Names.

00:54:43.660 --> 00:54:45.280
Du hast zwei Mengen, du hast D1 und D2.

00:54:45.360 --> 00:54:46.740
Genau, du hast zwei einigermaßen disziplinierte Names.

00:54:47.040 --> 00:54:48.500
Und da sind irgendwie zwei Keys gleich.

00:54:48.740 --> 00:54:50.760
Wenn du jetzt mit dem Update machst,

00:54:51.240 --> 00:54:52.460
werden die zwei gleichen Keys

00:54:52.460 --> 00:54:53.960
in dem ersten Dictionary überschrieben.

00:54:54.000 --> 00:54:56.380
erstes Addict-Update

00:54:56.380 --> 00:54:59.040
wenn du aber die Union machst

00:54:59.040 --> 00:55:00.480
erstes Addict-Union, zweites

00:55:00.480 --> 00:55:02.460
nein, dann sind nur noch die zwei Keys drin

00:55:02.460 --> 00:55:04.000
nee, das kann ich

00:55:04.000 --> 00:55:06.860
nee, das wäre ja der Schnitt

00:55:06.860 --> 00:55:07.780
nicht die Vereinigung

00:55:07.780 --> 00:55:09.480
achso, stimmt

00:55:09.480 --> 00:55:11.800
das gibt es nur bei Set

00:55:11.800 --> 00:55:14.160
das gibt es nur bei Set

00:55:14.160 --> 00:55:15.440
bei Set gibt es das

00:55:15.440 --> 00:55:18.240
gibt es nicht auch

00:55:18.240 --> 00:55:18.980
die Intersect

00:55:18.980 --> 00:55:21.200
nee, für Addict-Union gibt es keine Intersect

00:55:21.200 --> 00:55:26.660
Okay, schade eigentlich, weil das wäre doch eigentlich sehr logisch, dass das mit dem, jetzt habe ich den Pipe Operator nicht richtig verstanden.

00:55:26.680 --> 00:55:30.800
Es wäre logisch, dass es diese ganzen mathematischen Operationen alle für Set und Dictionary haben.

00:55:30.800 --> 00:55:39.060
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 Syntax, oder?

00:55:39.260 --> 00:55:41.360
Ich probiere das gerade mal in der Rappel aus, ja.

00:55:41.540 --> 00:55:41.880
Ja, mach mal.

00:55:41.880 --> 00:55:43.940
Union ist oder und das

00:55:43.940 --> 00:55:46.200
ist einfach

00:55:46.200 --> 00:55:47.940
die Vereinigung. Also die Keys

00:55:47.940 --> 00:55:50.180
aus dem einen Dictionary und die Keys aus dem anderen Dictionary.

00:55:50.180 --> 00:55:51.960
Ja, okay. Mit den Werten aus den jeweils

00:55:51.960 --> 00:55:53.940
letzten. Mach mal und und, Peter.

00:55:53.980 --> 00:55:55.580
Nee, das geht, nee, und und geht schon mal gar nicht.

00:55:55.700 --> 00:55:57.240
Und und gibt es in Python sowieso nicht? Gibt es nicht.

00:55:58.240 --> 00:55:59.640
Und und geht nicht. Und da sagt er

00:55:59.640 --> 00:56:01.920
unsupported operant type.

00:56:01.980 --> 00:56:03.140
Bitwise geht auch nicht. Ja, okay.

00:56:03.880 --> 00:56:05.560
Also tatsächlich, es geht nur die Vereinigung, ja.

00:56:06.400 --> 00:56:07.880
Ja, okay, dann ist das gleich wie ein Update.

00:56:08.100 --> 00:56:10.020
Wohingegen bei set, wenn man das jetzt so macht,

00:56:10.040 --> 00:56:11.780
Bei Set gibt's Intersect. Es gibt

00:56:11.780 --> 00:56:13.580
Set.Intersect, es gibt

00:56:13.580 --> 00:56:14.900
Set.Union und es gibt Set.

00:56:16.900 --> 00:56:17.760
Es gibt noch eine dritte.

00:56:17.840 --> 00:56:19.640
Difference. Symmetric

00:56:19.640 --> 00:56:21.220
Difference oder sowas. Ja, genau.

00:56:21.800 --> 00:56:23.400
Ja, Symmetric Difference ist ja

00:56:23.400 --> 00:56:25.740
das eine minus das andere plus das andere minus das

00:56:25.740 --> 00:56:25.880
eine.

00:56:27.220 --> 00:56:29.180
Schade, dass der Intersect nicht hat. Warum hat der das denn nicht?

00:56:29.280 --> 00:56:30.860
Also bei Set geht, aber bei Dix nicht.

00:56:31.320 --> 00:56:32.400
Das müsste ja irgendwann mal reinkommen.

00:56:32.520 --> 00:56:35.200
Die Frage ist, wie sollen denn dann die Values aussehen?

00:56:36.580 --> 00:56:37.660
Bei der Intersection

00:56:37.660 --> 00:56:39.300
der Keys. Welche nimmst du denn dann?

00:56:40.040 --> 00:56:42.920
Hm, jetzt hast du mich.

00:56:44.700 --> 00:56:47.060
Eine Liste von beiden wahrscheinlich oder sowas.

00:56:47.080 --> 00:56:48.780
Ja, aber das wäre dann schon sehr unerwartet, oder?

00:56:48.940 --> 00:56:50.560
Ich meine, man könnte auch auf die Idee kommen,

00:56:50.600 --> 00:56:52.440
es müsste anders sein und dann wundert man sich halt,

00:56:52.540 --> 00:56:54.320
was passiert, was, also, ja.

00:56:54.320 --> 00:56:58.320
Ja, also eigentlich müsstest du den Schnitt über die Keys machen

00:56:58.320 --> 00:57:01.920
und dann entscheiden, aus welcher Quelle du die Value nimmst.

00:57:02.880 --> 00:57:06.420
Das ist halt quasi wie beim Update mit Exclude oder sowas.

00:57:06.580 --> 00:57:07.540
Kann man das machen mit Exclude?

00:57:08.640 --> 00:57:08.860
Nee.

00:57:10.040 --> 00:57:11.140
Ja, auch doof.

00:57:12.140 --> 00:57:13.660
Ja, also, was mir jetzt

00:57:13.660 --> 00:57:15.600
wieder anfällt, es ist irgendwie relativ ähnlich zu dem, was man

00:57:15.600 --> 00:57:17.580
irgendwie bei den neuen Sachen hat, wie mit Data Classes

00:57:17.580 --> 00:57:19.380
oder PyIdentic oder sowas, oder

00:57:19.380 --> 00:57:21.440
was gibt's denn noch, alles AdWords oder sowas?

00:57:22.360 --> 00:57:23.560
Also, was diese, ja,

00:57:23.740 --> 00:57:25.520
oh, es gibt auch noch, ja,

00:57:25.940 --> 00:57:27.760
Named Tuples zum Beispiel.

00:57:27.760 --> 00:57:29.040
Genau, das ist auch spannend.

00:57:29.480 --> 00:57:31.160
Warum denn Named Tuple?

00:57:32.380 --> 00:57:33.840
Ja, das ist ein total komischer

00:57:33.840 --> 00:57:35.840
Name dafür, ist auch, ich weiß

00:57:35.840 --> 00:57:37.680
auch nicht. Um dotnotated Zugriffe

00:57:37.680 --> 00:57:39.500
auf irgendwelche Objekte zu haben für die einzelnen.

00:57:40.040 --> 00:57:52.760
Okay, aber dann, also was ist denn der Unterschied zwischen dem Dictionary und einer Klasse? Weil bei einer Klasse habe ich auch Namen drin, Punkt irgendwas und da ist genau ein Wert dazu drin.

00:57:52.760 --> 00:57:55.000
Du hast einen Konstruktor und irgendwie noch.

00:57:55.200 --> 00:57:56.640
Ja gut, aber das ist ja, da musst du ja eigentlich.

00:57:56.640 --> 00:57:57.720
Der Konstruktor ist nur eine Konvention.

00:57:57.980 --> 00:58:08.060
Ja, 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, ich meine, es ist ja auch so, dass.

00:58:08.160 --> 00:58:08.640
Alles Diktat.

00:58:08.860 --> 00:58:14.380
Genau, also in Python-Objekte, das sind halt Dicts sozusagen, was ihre Struktur angeht.

00:58:15.120 --> 00:58:16.820
Mit ein kleines bisschen Syntax dazu.

00:58:19.080 --> 00:58:19.560
Genau.

00:58:20.180 --> 00:58:23.740
Tatsächlich ist es sogar, also ich weiß nicht, ob das bekannt ist.

00:58:24.340 --> 00:58:27.040
Unter uns dreien sicherlich, aber unter den Hörern vielleicht nicht.

00:58:27.820 --> 00:58:32.140
Jede Instanz einer Klasse ist im Wesentlichen ein Dictionary.

00:58:32.320 --> 00:58:36.660
Also das hat ein Attribut, das heißt unterstrich, unterstrich, Dict, unterstrich, unterstrich.

00:58:37.080 --> 00:58:38.800
Und da stehen die Dinge drin, die

00:58:38.800 --> 00:58:41.240
die Values in dieser Instanz

00:58:41.240 --> 00:58:42.900
sind. Also eine Instanz ist immer

00:58:42.900 --> 00:58:43.920
ein Dictionary in Python.

00:58:44.540 --> 00:58:45.980
Das ist irgendwie

00:58:45.980 --> 00:58:49.340
komisch oder seltsam.

00:58:49.620 --> 00:58:51.260
Gerade wenn man von anderen Programmiersprachen

00:58:51.260 --> 00:58:53.140
kommt, weil in anderen Programmiersprachen ist es ja nicht so.

00:58:54.180 --> 00:58:55.200
Weiß ich nicht. Also ich würde

00:58:55.200 --> 00:58:57.000
gerade sagen, bei dem, was üblicherweise

00:58:57.000 --> 00:58:58.240
so als Skriptsprache

00:58:58.240 --> 00:59:00.860
qualifiziert wird.

00:59:01.960 --> 00:59:02.940
Da ist das auch, also bei

00:59:02.940 --> 00:59:04.760
JavaScript, da heißen die Dinger sogar Object.

00:59:05.340 --> 00:59:07.220
Vielleicht ist das das entscheidende Merkmal

00:59:07.220 --> 00:59:08.940
einer Skriptsprache.

00:59:10.240 --> 00:59:10.660
Also bei

00:59:10.660 --> 00:59:13.120
Perl war das auf jeden Fall auch so.

00:59:13.780 --> 00:59:15.260
Da waren auch, also ich meine, das hat ja

00:59:15.260 --> 00:59:17.280
keine offizielle... Bei dynamischen

00:59:17.280 --> 00:59:19.320
Klassen und dynamischen Instanzen geht es ja quasi

00:59:19.320 --> 00:59:21.300
nicht anders. Du musst ja quasi diese Zuordnung haben

00:59:21.300 --> 00:59:23.300
von Attributname zu irgendeinem

00:59:23.300 --> 00:59:23.780
Wert. Ja.

00:59:25.360 --> 00:59:27.280
Genau. Aber bei kompilierten Sprachen ist das ja anders.

00:59:27.440 --> 00:59:29.280
Ne, da ist es anders, genau. Bei kompilierten Sprachen

00:59:29.280 --> 00:59:31.260
musst du es nur während der Kompilierungszeit machen

00:59:31.260 --> 00:59:33.320
und dann kannst du sagen, okay, das Attribut

00:59:33.320 --> 00:59:35.040
mit dem Namen x ist halt Feld Nummer 2.

00:59:35.340 --> 00:59:37.040
Ja. Man kann das

00:59:37.040 --> 00:59:39.020
in Python auch machen, quasi. Man kann das

00:59:39.020 --> 00:59:41.000
halt festdengeln, ohne dass das halt dann

00:59:41.000 --> 00:59:43.180
noch so dynamisch...

00:59:43.180 --> 00:59:44.740
Ja, man kann halt die Attribute

00:59:44.740 --> 00:59:47.080
in einem Spezialattribut

00:59:47.080 --> 00:59:48.920
dann da Slots angeben und dann

00:59:48.920 --> 00:59:50.320
sind die halt da fix.

00:59:50.600 --> 00:59:52.700
Die kann man dann aber auch nicht mehr dynamisch zuweisen.

00:59:53.640 --> 00:59:54.340
Ist dann aber...

00:59:54.340 --> 00:59:55.620
Das ist aber auch nur Konvention, oder?

00:59:55.780 --> 00:59:57.240
Nee, nee, das ist dann tatsächlich schneller.

00:59:58.280 --> 01:00:00.560
Wenn ich so ein Slot-Ding mache, dann kann ich doch

01:00:00.560 --> 01:00:01.520
trotzdem zusätzlich...

01:00:01.520 --> 01:00:03.340
Achso, Moment.

01:00:04.360 --> 01:00:06.180
Kann ich dann trotzdem dynamisch zuweisen?

01:00:06.300 --> 01:00:07.700
Ich weiß es nicht, meine, das geht dann nicht mehr.

01:00:08.120 --> 01:00:09.000
Da muss ich ausprobieren.

01:00:09.180 --> 01:00:10.320
Doch, er macht seinen Editor an.

01:00:11.700 --> 01:00:13.300
Einer von uns beiden ist gleich falsch.

01:00:15.300 --> 01:00:16.360
Oder eben Name-Tupel.

01:00:16.420 --> 01:00:18.540
Name-Tupel ist genauso,

01:00:18.680 --> 01:00:20.460
nur halt schneller.

01:00:21.340 --> 01:00:22.400
Weil der eben diesen Aufruf

01:00:22.400 --> 01:00:24.380
nicht über ein Dictionary macht, sondern über eine lineare

01:00:24.380 --> 01:00:25.960
Liste, weil die Annahme ist, dass du

01:00:25.960 --> 01:00:28.140
nicht so viele davon hast.

01:00:28.640 --> 01:00:30.400
Oder vielleicht ist das so eine Hybrid-Sache.

01:00:33.380 --> 01:00:35.740
So ein bisschen ist das Dictionary ja der Kern

01:00:35.740 --> 01:00:37.540
von Python. Es gibt ja so eine

01:00:37.540 --> 01:00:39.980
Liste. Moment, ich habe es gerade ausprobiert.

01:00:40.300 --> 01:00:41.760
Nein, wenn man halt Slots

01:00:41.760 --> 01:00:43.720
definiert hat und dann was anderes dynamisch

01:00:43.720 --> 01:00:45.800
zuweisen möchte, kriegt man eine Exception Attribute Error.

01:00:46.980 --> 01:00:47.700
Also wenn man Slots macht,

01:00:47.820 --> 01:00:49.480
dann ist es kein richtiges Dictionary, sondern nur.

01:00:50.160 --> 01:00:51.680
Also es ist halt auch so ein Trick, damit kann man

01:00:51.680 --> 01:00:53.560
halt, wenn man viele Objekte hat oder so, damit kann man

01:00:53.560 --> 01:00:55.660
die Objekte selber schneller machen und sie brauchen viel weniger

01:00:55.660 --> 01:00:57.700
Speicher. Jetzt muss man noch

01:00:57.700 --> 01:00:59.580
erklären. Aber Nentupel macht das doch genauso,

01:00:59.680 --> 01:01:01.700
oder Jochen? Jetzt ist es auch schneller als

01:01:01.700 --> 01:01:03.240
eine allgemeine Klasse.

01:01:03.380 --> 01:01:15.820
Ja, ja, klar. Named Tuple macht das genauso und darüber funktioniert es. Ich glaube, dann intern kann es sogar sein, dass die interne Datenstruktur Tuple ist und sich dann sozusagen nur eine Zuordnung gemerkt wird von Index auf irgendeinen Namen.

01:01:15.820 --> 01:01:22.700
Aber das würde ja schon nichts bringen, dann hättest du ja den gleichen Aufruf wieder, sondern das muss eine andere Struktur sein, das ist keine Hashmap.

01:01:23.080 --> 01:01:26.200
Ja, ja, ja, nee, das ist irgendwas anderes, keine Ahnung, ja, was auch immer.

01:01:27.640 --> 01:01:29.800
man darf nicht vergessen, wenn ich eine kleine Menge

01:01:29.800 --> 01:01:31.800
an Keys

01:01:31.800 --> 01:01:33.380
habe, dann ist

01:01:33.380 --> 01:01:35.660
so eine Art Listenzuweisung, also ich merke mir

01:01:35.660 --> 01:01:37.680
einfach, die Keys in

01:01:37.680 --> 01:01:39.440
einer Liste und gehe die Liste linear durch,

01:01:40.400 --> 01:01:41.580
das kann schneller sein als so ein

01:01:41.580 --> 01:01:43.700
Hashmap-Zugriff. Ja. Für kleine

01:01:43.700 --> 01:01:44.260
Werte von n.

01:01:45.380 --> 01:01:47.660
Für kleine Werte von n ist o von n kleiner

01:01:47.660 --> 01:01:49.500
als o von 1. Kann sein. Ja, kann

01:01:49.500 --> 01:01:51.720
gut sein, ja. Und das ist, glaube ich,

01:01:51.720 --> 01:01:53.500
der Trick von Slots und der Trick von Name-Tupel,

01:01:53.580 --> 01:01:55.680
dass die halt sagen, okay, wir machen

01:01:55.680 --> 01:01:57.520
keine allgemeine Zuweisung, sondern wir sagen,

01:01:57.640 --> 01:01:59.060
aha, wir haben ja nur drei

01:01:59.060 --> 01:02:01.660
benannte Attribute, dann ist es besser, die in einer Liste

01:02:01.660 --> 01:02:02.380
zu haben.

01:02:03.740 --> 01:02:05.520
Okay, das Slots bitte noch einmal

01:02:05.520 --> 01:02:07.620
explizit erklären, weil das kommt gerade zum ersten Mal vor.

01:02:07.700 --> 01:02:08.600
Slots und Name-Tupel.

01:02:10.120 --> 01:02:11.280
Also Slots, wie gesagt,

01:02:12.200 --> 01:02:13.880
darüber weiß ich jetzt gar nicht,

01:02:13.880 --> 01:02:15.220
was du diktst, frage ich.

01:02:15.580 --> 01:02:17.460
Erklär es mal als Name-Tupel.

01:02:17.640 --> 01:02:18.600
Was ist denn ein Name-Tupel?

01:02:19.960 --> 01:02:21.380
Ich wollte gerade nach Slots fragen.

01:02:21.680 --> 01:02:23.220
Ja, das kommt gleich.

01:02:24.200 --> 01:02:25.700
Naja, da definierst du

01:02:25.700 --> 01:02:27.940
sozusagen ein Objekt, dadurch, dass du am Anfang

01:02:27.940 --> 01:02:29.600
du gibst halt so, glaube ich, wie das Aufruf

01:02:29.600 --> 01:02:31.100
Name-Truppel, dann sagt man irgendwie

01:02:31.100 --> 01:02:33.360
einen Namen dafür und dann sagt man die

01:02:33.360 --> 01:02:35.960
Attribute, die das haben kann

01:02:35.960 --> 01:02:37.680
irgendwie und dann. Und das

01:02:37.680 --> 01:02:39.640
verhält sich dann aber wie eine Klasse. Ja, genau.

01:02:39.800 --> 01:02:41.120
Und dann kann man mit Punkt drauf zugreifen.

01:02:41.420 --> 01:02:43.480
Aber nur mit diesen, die ich da angegeben habe.

01:02:43.620 --> 01:02:45.380
Also wenn ich ein Name-Truppel habe, das heißt

01:02:45.380 --> 01:02:47.080
FUBA.

01:02:47.760 --> 01:02:49.820
Keine Ahnung, das heißt FUBA und das hat die Attribute

01:02:49.820 --> 01:02:50.540
A, B und C.

01:02:52.100 --> 01:02:54.060
Dann kann ich ein FUBA.A

01:02:54.060 --> 01:02:56.160
machen und fuba.b und fuba.c und kriegt

01:02:56.160 --> 01:02:57.980
die entsprechenden, das verhält sich dann wie

01:02:57.980 --> 01:03:00.100
ein Dictionary, ja, für diese drei Keys.

01:03:00.440 --> 01:03:01.980
Aber Dict kann ich ja nicht mit Dot machen,

01:03:02.060 --> 01:03:04.060
muss ja mit den Key-Ketten. Genau, genau, also das ist

01:03:04.060 --> 01:03:05.940
wie eine Klasse, wie eine Instanz von einer Klasse.

01:03:06.080 --> 01:03:07.900
Also das ist so ein

01:03:07.900 --> 01:03:10.040
Ding, das mache ich häufig, ja, dass ich einfach eine Klasse

01:03:10.040 --> 01:03:11.300
mache, die heißt Data-Holder

01:03:11.300 --> 01:03:14.060
und die hat keine Attribute, weil dann kann ich

01:03:14.060 --> 01:03:15.920
nämlich mit Punkt irgendwas. Wenn wir jetzt gerade schon bei

01:03:15.920 --> 01:03:18.120
Named Tuples noch sind, da gibt es übrigens auch noch eine kleine Neuerung,

01:03:18.180 --> 01:03:19.760
weil früher gab es ja immer vom Collections Named Tuple,

01:03:19.840 --> 01:03:22.000
man musste Named Tuple off machen und jetzt gibt es aber auch

01:03:22.000 --> 01:03:23.960
Typing Named Tuple und Typing Named Tuple ist

01:03:23.960 --> 01:03:25.820
ein bisschen eleganter, weil dann kannst du einfach das wie eine Klasse

01:03:25.820 --> 01:03:27.860
schreiben und dann darunter

01:03:27.860 --> 01:03:29.860
die Attribute. Ich würde Name-Tupel gar nicht

01:03:29.860 --> 01:03:31.840
so prominent, weil

01:03:31.840 --> 01:03:33.760
auch das ist, glaube ich, nicht mehr

01:03:33.760 --> 01:03:35.320
so wirklich empfohlen und nicht mehr

01:03:35.320 --> 01:03:37.980
so richtig aktuell. Das gibt es halt noch.

01:03:39.120 --> 01:03:40.020
Aber eigentlich,

01:03:40.320 --> 01:03:41.480
was man... Dann erklär doch mal Slots.

01:03:42.280 --> 01:03:43.820
Wie auch immer. Wenn man Name-Tupel

01:03:43.820 --> 01:03:45.800
verstanden hat, dann ist Slots leicht zu erklären, weil

01:03:45.800 --> 01:03:47.780
Slots ist nämlich eine andere Syntax

01:03:47.780 --> 01:03:48.940
für die gleiche Funktionalität.

01:03:49.840 --> 01:03:51.680
Ja, du sagst,

01:03:51.880 --> 01:03:53.380
welche Attribute eine Klasse

01:03:53.380 --> 01:03:55.360
haben darf und dann hat es nur genau diese

01:03:55.360 --> 01:03:57.200
Attribute. Das heißt, okay, also in Slots ist eine

01:03:57.200 --> 01:03:59.220
Dann-Dann-Methode, die in einer Klasse drinstehen kann.

01:03:59.440 --> 01:04:01.180
Nicht eine Methode, nein, nein, das ist ein Attribut.

01:04:01.260 --> 01:04:02.760
Das ist ein Attribut, ah, okay, das ist ein Attribut.

01:04:02.840 --> 01:04:05.200
Dann gibt es eine Liste von Namen rein. Und das ist eine Liste

01:04:05.200 --> 01:04:07.180
ist und in der Liste stehen quasi

01:04:07.180 --> 01:04:09.300
die Strings drin von den

01:04:09.300 --> 01:04:11.520
Namen, die als Attribut

01:04:11.520 --> 01:04:13.420
einer Klasse, die als Methode oder Attribut

01:04:13.420 --> 01:04:15.160
erlaubt sind. In unserem Beispiel von eben wäre dann die

01:04:15.160 --> 01:04:16.820
Klasse, die Klasse hieße Fuba

01:04:16.820 --> 01:04:19.360
und die hätte ein Attribut, das hieße Dann-Dann-Slots

01:04:19.360 --> 01:04:20.860
und da steht drin A, B und C

01:04:20.860 --> 01:04:22.900
als Strings. Stehen da auch

01:04:22.900 --> 01:04:24.840
Methodennamen drin oder nur

01:04:24.840 --> 01:04:27.100
Attributnamen? Ne, nur die Attributnamen.

01:04:27.980 --> 01:04:29.100
Und wenn ich da Methodennamen reinschreibe,

01:04:29.160 --> 01:04:31.140
dann kann ich da eine Methode für definieren, die trotzdem funktioniert?

01:04:31.660 --> 01:04:32.540
Kannst du machen, klar.

01:04:32.920 --> 01:04:35.280
Wenn du willst. Da müsste man ja ausprobieren, was da passiert kann.

01:04:35.520 --> 01:04:36.500
Das kann komische Sachen passieren.

01:04:36.540 --> 01:04:38.260
Ne, das kannst du generell machen. Du kannst generell

01:04:38.260 --> 01:04:41.060
an jede Klasseninstanz eine Methode

01:04:41.060 --> 01:04:42.740
dran machen, die muss halt den Parameter

01:04:42.740 --> 01:04:44.860
self haben als erstes

01:04:44.860 --> 01:04:46.800
und dann funktioniert das wie eine Methode, weil

01:04:46.800 --> 01:04:48.900
Methoden an Klassen sind nichts anderes als

01:04:48.900 --> 01:04:52.140
Funktionen, die den Parameter

01:04:52.140 --> 01:04:53.800
selbst haben. Aber was ist denn, wenn das nicht in den Slots

01:04:53.800 --> 01:04:55.980
drinsteht? Ja, wenn es nicht in den

01:04:55.980 --> 01:04:57.760
Slots drinsteht, kannst du nicht drauf zugreifen. Genau,

01:04:57.880 --> 01:05:00.000
das heißt, die Methode kann ich nicht aufrufen, weil es nicht in den Slots

01:05:00.000 --> 01:05:01.640
drinsteht. Das heißt, auch die Slots sind für Methoden

01:05:01.640 --> 01:05:03.920
dann exklusiv. Du kannst die Methode in die

01:05:03.920 --> 01:05:05.880
Klassendefinition reinschreiben und

01:05:05.880 --> 01:05:07.840
die kommt dann zusätzlich zu den Slots dazu.

01:05:07.900 --> 01:05:09.800
Du kannst sie halt nicht dynamisch

01:05:09.800 --> 01:05:11.560
hinzufügen. Du kannst sie nicht dynamisch hinzufügen.

01:05:11.840 --> 01:05:13.800
Slots wird zusammengebaut aus dem, was in dem

01:05:13.800 --> 01:05:15.760
Attribut Slots drinsteht und in den Namen, die

01:05:15.760 --> 01:05:17.480
die Methode entdeckt. Da wäre ich mir nicht so sicher.

01:05:18.020 --> 01:05:18.920
Probier es mal aus, Jochen.

01:05:19.080 --> 01:05:20.360
Das ist meiner Meinung nach so.

01:05:22.740 --> 01:05:23.800
Jetzt müssen wir gerade ein bisschen tippen.

01:05:24.300 --> 01:05:26.800
Okay, ich habe es jetzt gerade gleich.

01:05:27.460 --> 01:05:27.820
Okay.

01:05:28.220 --> 01:05:28.640
Ich habe es gleich.

01:05:28.640 --> 01:05:30.340
Also foo.astf.

01:05:30.340 --> 01:05:31.300
Das funktioniert schon mal.

01:05:31.660 --> 01:05:32.460
Also genau so.

01:05:33.140 --> 01:05:35.140
Und jetzt sagen wir foo.slots.

01:05:35.520 --> 01:05:37.100
Ich glaube nicht, dass das zusammengebaut wird.

01:05:37.220 --> 01:05:38.680
Ich glaube, dass Slots bleibt so, wie es ist.

01:05:38.900 --> 01:05:39.960
Aber das funktioniert.

01:05:40.060 --> 01:05:41.520
Methoden gehen, ohne dass es in Slots drin steht.

01:05:41.640 --> 01:05:42.560
Und es ist nicht in Slots drin.

01:05:42.600 --> 01:05:44.360
Du kannst über Methoden hinzuschauen.

01:05:44.560 --> 01:05:44.720
Genau.

01:05:45.040 --> 01:05:48.720
Weil die Methoden an dem Typ dranhängen

01:05:48.720 --> 01:05:49.800
und nicht in der Instanz.

01:05:50.820 --> 01:05:51.220
Okay.

01:05:52.020 --> 01:05:54.940
Das heißt, an einer Instanz, die ein Slots-Attribut hat,

01:05:55.020 --> 01:05:55.960
kannst du nichts verändern.

01:05:56.060 --> 01:05:58.320
Du hast nur genau diese Keys, die da drin sind.

01:05:58.920 --> 01:06:02.380
In dem darüber liegenden Typ hast du Methoden drin.

01:06:02.500 --> 01:06:04.280
Und da kannst du auch, kannst du alles Mögliche drin haben.

01:06:04.340 --> 01:06:05.380
Das ist deine normale Klasse.

01:06:05.780 --> 01:06:07.680
Okay, es geht also nur für die Instanz, die Slots.

01:06:08.160 --> 01:06:08.400
Genau.

01:06:08.800 --> 01:06:10.920
Die Slots sind für Instanzen von dieser Klasse.

01:06:10.920 --> 01:06:14.420
Und wenn diese Klasse aber selbst noch Methoden hat oder Attribute,

01:06:14.540 --> 01:06:16.120
Du kannst auch in diese Klasse ein Antiboot reinschreiben.

01:06:16.260 --> 01:06:17.680
Du kannst da x gleich 10 reinschreiben.

01:06:18.180 --> 01:06:19.260
Und das kannst du auch auslesen.

01:06:19.900 --> 01:06:21.480
Und du kannst es auch an der Klasse verändern.

01:06:22.940 --> 01:06:24.140
Aber nicht in den Instanzen.

01:06:24.680 --> 01:06:26.840
Weil in den Instanzen darfst du nur auf Slots zugreifen.

01:06:28.580 --> 01:06:30.000
Und das bedeutet,

01:06:30.500 --> 01:06:32.040
dass eine Klasse mit Slots

01:06:32.040 --> 01:06:33.920
im Wesentlichen wie ein Name-Tupel ist.

01:06:34.360 --> 01:06:36.120
Nur besser. Mit besserer Syntax.

01:06:36.540 --> 01:06:37.860
Und mehr Methoden.

01:06:38.440 --> 01:06:40.980
Und das ist auch der Grund, warum Name-Tupel nicht mehr so richtig...

01:06:40.980 --> 01:06:42.500
Jawohl, aber ich finde, dass das neue Name-Tupel

01:06:42.500 --> 01:06:43.920
von Apple Typing ist doch gar nicht so schlecht.

01:06:44.540 --> 01:06:46.280
Ne, also es hat auch noch andere Nachteile.

01:06:46.520 --> 01:06:47.900
Also es gibt ja jetzt

01:06:47.900 --> 01:06:50.200
auch denn etwas, was man vielleicht

01:06:50.200 --> 01:06:52.040
eher nehmen, also vielleicht meinst du das auch,

01:06:52.220 --> 01:06:53.940
es gibt ja Dataclasses, die sind ja auch jetzt in der

01:06:53.940 --> 01:06:55.360
Sprache drin, direkt.

01:06:56.580 --> 01:06:58.160
Und die sind auch in eigentlichen, also es gab es auch

01:06:58.160 --> 01:06:59.380
ich weiß nicht, Artikel zu,

01:07:00.080 --> 01:07:02.120
ich meine, ich habe es jetzt nur mal so gelesen, ich habe es nicht wirklich

01:07:02.120 --> 01:07:04.300
selber überprüft, aber so wo Leute sagen, also bitte

01:07:04.300 --> 01:07:06.220
nehmt doch alle Dataclasses und nicht mehr nehmt Tuppel,

01:07:06.300 --> 01:07:08.200
weil Dataclasses, es ist schneller, es ist besser,

01:07:08.360 --> 01:07:10.220
es ist in jeder Hinsicht besser, es gibt keinen Grund mehr

01:07:10.220 --> 01:07:11.740
das zu nehmen, das alte Zeug ist nur noch drin.

01:07:11.740 --> 01:07:12.380
Man kann es lesen.

01:07:14.120 --> 01:07:14.820
Okay, ja.

01:07:16.360 --> 01:07:17.500
Es kann mehr und

01:07:17.500 --> 01:07:19.460
es ist schneller. Also ich meine, es gibt

01:07:19.460 --> 01:07:20.440
keine großen Nachteile.

01:07:22.800 --> 01:07:23.000
Und

01:07:23.000 --> 01:07:24.860
es gibt das natürlich, also

01:07:24.860 --> 01:07:27.440
das Vorbild für Dataclass

01:07:27.440 --> 01:07:29.800
ist halt dieses Adress-

01:07:29.800 --> 01:07:31.480
Modul, das sehr beliebt ist. Das kann halt dann noch

01:07:31.480 --> 01:07:33.540
viel mehr. Und es ist auch

01:07:33.540 --> 01:07:35.600
relativ schnell, wenn ich das so richtig verstehe. Das ist auch sehr nett,

01:07:35.740 --> 01:07:37.620
ja. Und

01:07:37.620 --> 01:07:39.500
also das ist das, was vielleicht

01:07:39.500 --> 01:07:41.340
damit angefangen hat. Dann Dataclass ist eingebaut

01:07:41.340 --> 01:07:43.260
und jetzt gibt es halt auch noch sowas wie Pydentic,

01:07:43.620 --> 01:07:45.640
Das ist ja auch so ähnlich. Das ist noch schneller.

01:07:46.060 --> 01:07:46.980
Der Münster bei Dataclass.

01:07:46.980 --> 01:07:48.140
Das ist nicht schneller als Etos.

01:07:48.800 --> 01:07:51.580
Ich weiß nicht. Ne, Pidentic, meine ich auch, ist eine eigene Geschichte.

01:07:51.800 --> 01:07:53.280
Ja, Pidentic ist eigen, aber es ist nicht schneller.

01:07:53.960 --> 01:07:55.420
Doch, doch. Ne, es ist nicht.

01:07:55.600 --> 01:07:57.440
Ne. Es ist ein Einstehen sogar langsamer

01:07:57.440 --> 01:07:59.060
als Etos zum Beispiel. Okay.

01:07:59.480 --> 01:08:01.600
Jochen dachte, es wäre schneller. Ich dachte, es wäre Dataclass.

01:08:01.600 --> 01:08:01.940
Ja, gut.

01:08:04.360 --> 01:08:05.660
Ich habe irgendwo so ein Video,

01:08:05.720 --> 01:08:06.800
das muss ich eigentlich mal in den Show-Notes verlinken,

01:08:07.160 --> 01:08:09.000
wo jemand das ganz gut auseinandernimmt, wo der so

01:08:09.000 --> 01:08:11.140
Timings dafür macht. Also, das muss sich mal irgendjemand

01:08:11.140 --> 01:08:13.020
mal ganz genau angucken und dann Bescheid sagen,

01:08:13.080 --> 01:08:13.980
wie das denn wirklich ist.

01:08:14.580 --> 01:08:16.900
Ja, also in dieser Episode hier in den Podcast

01:08:16.900 --> 01:08:18.620
kommen und uns das allen erklären, wie es ist.

01:08:18.620 --> 01:08:19.240
Genau, das wäre gut.

01:08:20.580 --> 01:08:21.460
Ja, absolut.

01:08:23.560 --> 01:08:24.920
Genau, aber es ist auf jeden Fall ein Ding,

01:08:25.100 --> 01:08:26.560
was halt, und

01:08:26.560 --> 01:08:28.840
diese ganzen Dinge, wenn man

01:08:28.840 --> 01:08:30.780
die sich alle anguckt, also Name-Tupel

01:08:30.780 --> 01:08:32.800
ist halt das, was man am wenigsten nehmen sollte von den ganzen

01:08:32.800 --> 01:08:33.160
Sachen.

01:08:34.140 --> 01:08:36.660
Ich finde ja die moderne Sonntag, das sieht eigentlich ganz hübsch aus.

01:08:36.900 --> 01:08:37.680
Es ist halt so schnell.

01:08:39.340 --> 01:08:40.400
Wenn du es halt aufschreiben willst,

01:08:40.460 --> 01:08:42.600
vom Typing-Import Name-Tupel, dann machst du einfach

01:08:42.600 --> 01:08:44.940
auf, keine Ahnung, Named Tuple,

01:08:45.580 --> 01:08:47.160
Define Named Tuple von irgendwas und dann schreibst du halt

01:08:47.160 --> 01:08:48.640
die Attribute untereinander wie in der Klasse,

01:08:49.120 --> 01:08:51.040
definierst die und ist klar, welchen Datentyp haben die denn und so,

01:08:51.060 --> 01:08:53.240
das sieht schon so aus als... Okay, vielleicht muss ich mir

01:08:53.240 --> 01:08:54.960
das auch nochmal angucken, weil dass ich das

01:08:54.960 --> 01:08:57.060
vom Typing importiere, kenne ich jetzt noch gar nicht.

01:08:57.340 --> 01:08:59.200
Ja, aber das ist auf jeden Fall, glaube ich, ich weiß auch gar nicht,

01:08:59.240 --> 01:09:01.040
ob sich eine Implementierung da was geändert hat, aber

01:09:01.040 --> 01:09:02.800
ich glaube, so werden wir das eigentlich haben, oder?

01:09:03.300 --> 01:09:05.080
Also das musst du jetzt mal kurz aufmachen, um dir das mal

01:09:05.080 --> 01:09:07.280
anzuschauen. Okay, dann muss ich

01:09:07.280 --> 01:09:09.160
da mal eingehen. Also ich würde tatsächlich

01:09:09.160 --> 01:09:11.100
eher Dataclasses verwenden für diesen Newscase,

01:09:11.240 --> 01:09:14.360
Aber ich habe ja immer seltsame Ansichten.

01:09:15.020 --> 01:09:16.080
Ja, das nächste Neues war anders.

01:09:16.080 --> 01:09:17.760
Ich habe mich dann abgefunden, dass ich nicht im Standard bin.

01:09:19.700 --> 01:09:21.540
Ach, so sieht das, nee, okay.

01:09:23.140 --> 01:09:24.580
Ach doch, so sieht das aus, ja, okay.

01:09:24.880 --> 01:09:28.820
Ja, Typing, Punkt, Named, Tuppel und dann sagt man hier irgendwie quasi.

01:09:28.820 --> 01:09:31.080
Ja, aber das ist sogar noch, Moment, das muss ich mal so sehen.

01:09:32.420 --> 01:09:34.380
Ja, da unten, also das nächste Beispiel ist sogar noch hübscher.

01:09:34.380 --> 01:09:35.860
Ihr wisst, dass die Zuhörer den Monitor nicht sehen können.

01:09:36.080 --> 01:09:37.420
Genau, das ist das Problem bei Podcasts.

01:09:38.200 --> 01:09:40.100
Und das Problem ist auch, ich kann das jetzt nicht vorlesen,

01:09:40.160 --> 01:09:41.540
Das kann ich schon, hilft nur nicht.

01:09:42.100 --> 01:09:43.860
Ja, genau, aber ich finde so die Sündheit,

01:09:43.900 --> 01:09:44.880
das sieht doch gar nicht so schlecht aus.

01:09:45.220 --> 01:09:46.280
Ja, okay, also gut.

01:09:47.480 --> 01:09:48.200
Das ist halt klasse.

01:09:48.220 --> 01:09:50.160
Muss ich das mal jemandem angucken und dann zu Bescheid sagen.

01:09:51.320 --> 01:09:53.260
Also es ist auch eine Möglichkeit, die man machen kann.

01:09:53.580 --> 01:09:54.140
Ja, ja, ja.

01:09:56.180 --> 01:09:58.440
Ja, ja, sehr nett.

01:09:58.460 --> 01:10:00.300
Okay, aber das ist ja nur syntaktischer Zucker, oder?

01:10:00.400 --> 01:10:01.080
Wenn ich das jetzt richtig verstehe.

01:10:01.080 --> 01:10:02.040
Ja, syntaktisch Zucker.

01:10:02.500 --> 01:10:02.640
Ja.

01:10:03.640 --> 01:10:04.000
Sehr gut.

01:10:04.340 --> 01:10:05.720
Also dann ist es quasi ein Name-Tool.

01:10:05.840 --> 01:10:06.800
Okay, schön, das ist auch okay.

01:10:08.240 --> 01:10:10.840
Es gibt noch zwei Dinge, die ich

01:10:10.840 --> 01:10:12.320
vorhin gelernt habe. Das erste ist Counter.

01:10:12.400 --> 01:10:13.400
Wir haben es schon kurz angesprochen.

01:10:14.440 --> 01:10:16.000
Counter ist auch eine Dictionary-Subklasse

01:10:16.000 --> 01:10:18.560
und die

01:10:18.560 --> 01:10:20.680
macht im Wesentlichen das, was sie sagt.

01:10:20.680 --> 01:10:21.940
Ich gebe eine Sequenz rein

01:10:21.940 --> 01:10:24.380
und die zählt, wie oft jedes Element drin vorkommt.

01:10:25.440 --> 01:10:26.460
Das heißt, wenn ich einen String

01:10:26.460 --> 01:10:28.520
reingebe, dann habe ich hinterher ein Dictionary und in dem

01:10:28.520 --> 01:10:30.340
Dictionary steht drin,

01:10:30.500 --> 01:10:32.500
wie oft jeder Buchstabe in diesem String

01:10:32.500 --> 01:10:32.940
vorkommt.

01:10:34.860 --> 01:10:36.400
Und das ist großartig, weil das

01:10:36.400 --> 01:10:37.720
baut man sich so oft selbst

01:10:37.720 --> 01:10:40.460
und das baut man sich so oft

01:10:40.460 --> 01:10:41.740
von Hand und macht

01:10:41.740 --> 01:10:44.220
ein Default-Dict oder macht ein Get und

01:10:44.220 --> 01:10:46.100
inkrementiert die Zahl dann und so weiter.

01:10:47.260 --> 01:10:48.500
Einfach ein Counter und die Sequenz

01:10:48.500 --> 01:10:50.400
reintun und fertig. Und man kriegt ein Dictionary

01:10:50.400 --> 01:10:52.220
raus mit der Anzahl.

01:10:52.460 --> 01:10:54.500
Super, ist großartig. Und das hat auch diese ganzen

01:10:54.500 --> 01:10:56.280
Funktionen, die man dazu braucht. Also wenn man das

01:10:56.280 --> 01:10:57.640
dann updaten möchte oder wenn man das

01:10:57.640 --> 01:11:00.120
wenn man

01:11:00.120 --> 01:11:01.720
einen Generator hat oder wenn man

01:11:01.720 --> 01:11:03.920
irgendwas anderes in der Hand hat und das nicht

01:11:03.920 --> 01:11:06.340
genau vorher weiß oder wenn man zwischendurch noch was machen möchte,

01:11:06.400 --> 01:11:07.480
Das ist großartig.

01:11:07.960 --> 01:11:10.240
Ein Counter zusammen mit einer Comprehension, super.

01:11:10.960 --> 01:11:11.460
Ja, ja.

01:11:12.440 --> 01:11:13.940
Das deckt so viele von diesen Fällen ab,

01:11:14.080 --> 01:11:15.420
für die man sonst Default-Dict verwendet.

01:11:16.920 --> 01:11:17.100
Ja.

01:11:18.440 --> 01:11:19.920
Ich habe noch was anderes Schönes gefunden

01:11:19.920 --> 01:11:21.540
und zwar heißt es Chain-Map.

01:11:21.860 --> 01:11:23.200
Das ist auch im Collections-Modul drin.

01:11:23.940 --> 01:11:25.060
Was ist denn eine Chain-Map?

01:11:25.540 --> 01:11:29.620
Eine Chain-Map, das ist so ein ...

01:11:29.620 --> 01:11:31.680
Mich hat das so ein bisschen an JavaScript-Objects erinnert.

01:11:33.220 --> 01:11:35.620
Wenn du nach einem Key suchst,

01:11:36.160 --> 01:11:38.380
dann suchst du quasi durch die ganze Reihe durch.

01:11:38.480 --> 01:11:40.840
Das heißt, Chainmap nimmt eine Menge von Dictionaries

01:11:40.840 --> 01:11:43.980
und wenn du nach einem Key fragst,

01:11:45.000 --> 01:11:46.820
dann guckt er im ersten Dictionary, ist der da drin?

01:11:47.520 --> 01:11:48.780
Wenn er da drin ist, kriegst du den Wert.

01:11:49.200 --> 01:11:50.800
Wenn er nicht drin ist, guckt er im zweiten nach.

01:11:51.120 --> 01:11:52.440
Wenn er da drin ist, kriegst du den Wert.

01:11:52.840 --> 01:11:54.520
Wenn er nicht drin ist, guckt er im dritten nach und so weiter,

01:11:54.840 --> 01:11:58.880
bis er alle seine darunter liegenden Dictionaries durchgeschaut hat.

01:11:58.880 --> 01:12:01.020
Wenn er es nirgendwo findet, kriegst du immer noch einen Key Error.

01:12:02.120 --> 01:12:06.460
Wenn du aber einen Wert reinschreibst in diese Chain-Map,

01:12:06.560 --> 01:12:10.520
dann schreibt er das immer in das oberste Dictionary rein.

01:12:10.580 --> 01:12:13.520
Das heißt, du veränderst nur das erste Dictionary aus deiner Kette,

01:12:14.160 --> 01:12:16.580
hast aber lesenden Zugriff auf die darunterliegenden.

01:12:18.220 --> 01:12:22.060
Und das ist so ein bisschen so, wie Objekte in JavaScript funktionieren,

01:12:22.120 --> 01:12:23.540
wie Object in JavaScript funktioniert.

01:12:24.220 --> 01:12:27.620
Wenn du liest, liest du immer aus dem Ersten, was verfügbar ist,

01:12:27.680 --> 01:12:29.360
aber wenn du schreibst, schreibst du immer ins Oberste rein.

01:12:30.480 --> 01:12:31.440
Ja, ja, ja.

01:12:32.120 --> 01:12:35.320
Ja, ich überlege gerade auch, also ich meine,

01:12:35.620 --> 01:12:37.500
das ist auch sowas, ja, ich weiß es nicht genau,

01:12:37.560 --> 01:12:39.480
aber es ist halt eine, ich mache jetzt auch

01:12:39.480 --> 01:12:41.640
so ein bisschen JavaScript gerade und

01:12:41.640 --> 01:12:43.560
was ich da, was dann

01:12:43.560 --> 01:12:45.440
doch ein bisschen einfacher hinzuschreiben ist als

01:12:45.440 --> 01:12:46.440
in Python ist halt dieses

01:12:46.440 --> 01:12:48.120
Dreipunkt

01:12:48.120 --> 01:12:51.500
Spread Operator Syntax, wo man dann halt

01:12:51.500 --> 01:12:53.500
sich neue Sachen generiert, indem man halt ein altes Ding nimmt

01:12:53.500 --> 01:12:55.340
und dann sagt man Punkt, Punkt, Punkt, altes Ding

01:12:55.340 --> 01:12:57.360
und dann schreibt man noch ein neues Ding

01:12:57.360 --> 01:12:59.440
dazu oder so und mit Chain Map hat man

01:12:59.440 --> 01:13:01.180
ja da quasi was ganz

01:13:01.180 --> 01:13:03.780
ähnliches. Genau, das ist eben

01:13:03.780 --> 01:13:05.880
wie gesagt diese Prototyp-Sache.

01:13:06.460 --> 01:13:07.740
JavaScript ist die halt der Kern

01:13:07.740 --> 01:13:09.420
von JavaScript.

01:13:10.780 --> 01:13:11.080
Jedes

01:13:11.080 --> 01:13:13.860
Object oder jedes Dictionary in JavaScript

01:13:13.860 --> 01:13:16.060
hat einen Prototypen, auf den

01:13:16.060 --> 01:13:16.920
du zurückfallen kannst.

01:13:17.780 --> 01:13:19.400
Und das kannst du hier mit Chainmap nachbauen.

01:13:20.560 --> 01:13:20.720
Ja,

01:13:22.080 --> 01:13:23.820
nett. Fand ich sehr schön,

01:13:23.920 --> 01:13:25.940
dass es gibt. Habe ich noch nie gebraucht.

01:13:26.660 --> 01:13:27.780
Wüsste jetzt auch nicht, an welcher Stelle

01:13:27.780 --> 01:13:29.180
ich das einsetzen würde, aber

01:13:29.180 --> 01:13:31.320
gibt es

01:13:31.320 --> 01:13:33.160
auf jeden Fall und ich glaube, wenn man

01:13:33.160 --> 01:13:34.800
das braucht, ist das eine sehr, sehr nützliche Sache.

01:13:35.900 --> 01:13:36.080
Ja.

01:13:38.180 --> 01:13:39.200
Weil man so Hierarchien

01:13:39.200 --> 01:13:39.860
damit bauen kann.

01:13:42.680 --> 01:13:43.040
Ja.

01:13:43.620 --> 01:13:45.160
Vielleicht nochmal einmal ganz kurz, weil ich

01:13:45.160 --> 01:13:46.440
gerade nachgeguckt hatte zu diesem

01:13:46.440 --> 01:13:49.060
WhichPythonDataClassIsBest, habe ich

01:13:49.060 --> 01:13:50.920
ein Artikel, also ein Video gefunden von

01:13:50.920 --> 01:13:52.520
einem Kanal, der mCoding heißt

01:13:52.520 --> 01:13:55.080
und da vergleicht jemand tatsächlich

01:13:55.080 --> 01:13:56.960
Dataclasses, NameTupil,

01:13:57.020 --> 01:13:59.120
TupilEthers und Pydentic

01:13:59.120 --> 01:14:01.600
nach Geschwindigkeit und Memory

01:14:01.600 --> 01:14:03.800
und so. Und da schneidet Pidentic

01:14:03.800 --> 01:14:05.740
vor allem beim Erstellen von den Objekten relativ

01:14:05.740 --> 01:14:07.740
schlecht ab. Okay, gut, ja.

01:14:08.460 --> 01:14:09.680
Das irgendwie

01:14:09.680 --> 01:14:11.380
15 Mal so lange dauert oder so.

01:14:12.280 --> 01:14:13.360
Aber sonst vielleicht schnell.

01:14:14.500 --> 01:14:14.960
Ja, gut.

01:14:16.360 --> 01:14:18.080
Im Laufe seines Programmiererlebens

01:14:18.080 --> 01:14:20.120
hat man sich davon weg entfernt, auf Geschwindigkeit

01:14:20.120 --> 01:14:21.680
zu achten. Notiz hätte er wieder

01:14:21.680 --> 01:14:23.620
angemacht. Ja, genau, Geschwindigkeit, ja.

01:14:23.620 --> 01:14:25.160
Da ist die Frage, braucht man das überhaupt, will man das?

01:14:25.620 --> 01:14:27.380
Genau. Egal, haben wir nicht genug Hauptspeicher

01:14:27.380 --> 01:14:28.980
und sind solche, also das war

01:14:28.980 --> 01:14:31.060
nie genügend Geschwindigkeit und nie genügend.

01:14:31.420 --> 01:14:32.460
Ja, wir hatten letztens

01:14:32.460 --> 01:14:33.680
jemand,

01:14:35.380 --> 01:14:37.160
den kennt ihr

01:14:37.160 --> 01:14:37.860
bestimmt auch, der

01:14:37.860 --> 01:14:40.520
Pavel Mayer aus

01:14:40.520 --> 01:14:43.700
Chaos Radio

01:14:43.700 --> 01:14:45.240
oder

01:14:45.240 --> 01:14:47.020
aus dem Chaosumfeld, ne, die kenne ich ja nicht.

01:14:47.180 --> 01:14:48.880
Ah, okay, der, naja, gut.

01:14:49.820 --> 01:14:51.040
Der hatte das mal

01:14:51.040 --> 01:14:53.240
irgendwie so beschrieben, dass ein Computer

01:14:53.240 --> 01:14:54.960
eigentlich für ihn nur eine relevante Eigenschaft,

01:14:55.420 --> 01:14:56.400
also eine

01:14:56.400 --> 01:14:58.580
ein Attribut hat, das

01:14:58.580 --> 01:15:00.740
wichtig ist. Oder es gibt

01:15:00.740 --> 01:15:02.660
drei ganz wichtige. Und zwar, das ist halt

01:15:02.660 --> 01:15:04.840
erstens Performance. Das zweite ist halt

01:15:04.840 --> 01:15:06.860
Performance. Und das dritte ist, was auch

01:15:06.860 --> 01:15:08.700
noch sehr wichtig ist, Performance.

01:15:11.180 --> 01:15:12.260
Sind ja nur drei Dinge.

01:15:13.580 --> 01:15:14.520
Ja, da ist auch

01:15:14.520 --> 01:15:16.720
schon was dran. Aber tatsächlich

01:15:16.720 --> 01:15:18.860
sowas wie Lesbarkeit ist auch nicht

01:15:18.860 --> 01:15:20.720
so schlecht. Ist das der Prof. Mayer, der dieses

01:15:20.720 --> 01:15:22.420
mega langsame Covid-Dashboard geschrieben hat?

01:15:22.460 --> 01:15:23.380
Ja, genau.

01:15:24.600 --> 01:15:25.200
Just saying.

01:15:26.400 --> 01:15:29.180
Es gibt so Leute, also ich meine

01:15:29.180 --> 01:15:31.100
es gibt auch Felder

01:15:31.100 --> 01:15:32.940
in denen das wichtig ist, ja

01:15:32.940 --> 01:15:34.940
die Geschwindigkeit und Geschwindigkeit ist immer irgendwie

01:15:34.940 --> 01:15:37.020
so ein Faktor, der wichtig

01:15:37.020 --> 01:15:39.040
ist, aber man kann

01:15:39.040 --> 01:15:40.940
da so tief reingehen, wie man

01:15:40.940 --> 01:15:42.960
möchte und es gibt immer noch jemanden, der das schneller macht

01:15:42.960 --> 01:15:44.980
Ich sehe mir

01:15:44.980 --> 01:15:47.080
sehr gerne die Videos von Casey Muratori an

01:15:47.080 --> 01:15:49.240
und der kommt halt aus der Spieleentwicklung

01:15:49.240 --> 01:15:50.200
und der sagt

01:15:50.200 --> 01:15:52.980
man kann in C alles machen, also solltest

01:15:52.980 --> 01:15:54.940
du in C auch alles machen, aber wenn es schnell

01:15:54.940 --> 01:15:56.900
sein muss, dann musst du halt schon auf die Intrinsics

01:15:56.900 --> 01:15:58.700
gehen und den Prozessor kennen, den

01:15:58.700 --> 01:16:00.740
du da gerade benutzt und dann

01:16:00.740 --> 01:16:02.840
den Befehlssatz

01:16:02.840 --> 01:16:04.600
kennen, weil dann kannst du nämlich alles

01:16:04.600 --> 01:16:06.720
256 Mal so schnell machen wie vorher

01:16:06.720 --> 01:16:07.020
und

01:16:07.020 --> 01:16:10.600
ja, das ist

01:16:10.600 --> 01:16:12.780
prinzipiell korrekt, aber

01:16:12.780 --> 01:16:14.760
Vielleicht ist Assembly-Coden

01:16:14.760 --> 01:16:16.660
auch zu langsam, also wenn man es gut kann, ich weiß nicht.

01:16:17.200 --> 01:16:17.960
Noch ganz kurz.

01:16:18.140 --> 01:16:19.340
Ich kann das sicherlich gut genug, aber

01:16:19.340 --> 01:16:22.180
noch kurz zu

01:16:22.180 --> 01:16:24.400
genau, da gibt es auch gerade auf Netflix

01:16:24.400 --> 01:16:26.500
so eine Miniserie oder so

01:16:26.500 --> 01:16:28.300
The Billion Dollar Code, die ist quasi

01:16:28.300 --> 01:16:30.340
mehr so, die orientiert sich

01:16:30.340 --> 01:16:32.060
an der, an dem oder deren

01:16:32.060 --> 01:16:34.460
Biografien da in, ja.

01:16:35.400 --> 01:16:37.180
Und die scheint wohl ganz gut.

01:16:37.820 --> 01:16:39.020
Wir machen schon wieder Werbung,

01:16:39.120 --> 01:16:40.340
Jochen, das ist aber eine werbungsvolle Folge.

01:16:40.960 --> 01:16:42.680
Ja, diesmal ist ja noch gar nicht so,

01:16:43.120 --> 01:16:45.040
also, ja, gut, wir machen Werbung,

01:16:45.120 --> 01:16:46.880
Werbung machen wir immer, aber wir werden

01:16:46.880 --> 01:16:48.920
nicht dafür bezahlt, dass

01:16:48.920 --> 01:16:50.520
Netflix, falls ihr zuhört,

01:16:50.900 --> 01:16:52.860
der Jochen wäre durchaus offen dafür, bezahlt

01:16:52.860 --> 01:16:54.860
zu werden. Du weißt, Johannes Verkunde

01:16:54.860 --> 01:16:56.800
ist ja nicht mit anderen Werbepartnern direkt parallel.

01:16:57.900 --> 01:16:58.980
Also Netflix-Werbung würde ich

01:16:58.980 --> 01:16:59.620
vielleicht auch nicht.

01:17:00.440 --> 01:17:02.880
Wir hatten ja letztes Mal, also wenn wir jetzt schon das Thema Werbung haben,

01:17:02.980 --> 01:17:03.900
wo der jetzt gerade Werbung für so eine Werbung macht.

01:17:03.900 --> 01:17:05.460
Ich mach mal eine Chapter Mark hier.

01:17:05.940 --> 01:17:08.520
Ja, wir haben ja überlegt, ob wir Werbung

01:17:08.520 --> 01:17:10.700
mal schalten sollen und ein bisschen uns drüber lustig gemacht und

01:17:10.700 --> 01:17:12.940
wir haben ein bisschen Feedback bekommen. Du wolltest sagen, ja, mach doch

01:17:12.940 --> 01:17:14.760
einfach. Ja, dann haben wir jetzt auch gedacht,

01:17:14.860 --> 01:17:15.780
ja, okay. Na gut, dann machen wir halt.

01:17:18.060 --> 01:17:19.220
So ein bisschen kostendeckend

01:17:19.220 --> 01:17:20.800
arbeiten oder so. Gibt es Leute, die euch

01:17:20.800 --> 01:17:22.080
bezahlen, das ist ja verrückt.

01:17:22.580 --> 01:17:23.120
Noch nicht.

01:17:23.900 --> 01:17:24.800
Berührt und schockiert.

01:17:25.620 --> 01:17:26.840
Du wirst nicht bezahlt, Johannes.

01:17:28.200 --> 01:17:29.400
Achso, ja gut dann.

01:17:30.040 --> 01:17:30.600
Dann ist mir egal.

01:17:31.540 --> 01:17:33.960
Nicht so direkt, aber ich meine, das wäre natürlich so eine Sache,

01:17:34.040 --> 01:17:35.500
die man machen könnte. Man könnte halt also einmal

01:17:35.500 --> 01:17:38.040
Hostingkosten und so die anfallen, ein bisschen damit

01:17:38.040 --> 01:17:40.360
vielleicht bezahlen.

01:17:40.420 --> 01:17:42.060
Aber was man auch machen könnte, wir könnten

01:17:42.060 --> 01:17:43.920
dem Johannes ordentliches

01:17:43.920 --> 01:17:45.900
Audioequipment schicken zum Beispiel.

01:17:46.340 --> 01:17:47.600
Ja, da müssen wir nochmal drüber nachdenken.

01:17:47.620 --> 01:17:49.540
Dann ist das jetzt hier mit der Spendenaufruf,

01:17:49.540 --> 01:17:51.480
wenn die Zuhörer gerne möchten, dass

01:17:51.480 --> 01:17:52.640
ihr mich besser hören könnt, dann

01:17:52.640 --> 01:17:55.760
finden sie jetzt eine folgende Bitcoin-Adresse.

01:17:55.960 --> 01:17:57.080
Wir schalten ab jetzt einfach Werbung.

01:17:58.140 --> 01:17:58.260
Ja.

01:17:59.260 --> 01:18:01.980
Aber wenn ihr dann Werbung

01:18:01.980 --> 01:18:03.600
schalten würdet und dann auch

01:18:03.600 --> 01:18:05.380
Geld einnehmen würdet, dann könntet ihr

01:18:05.380 --> 01:18:07.240
euch ja auch richtige Gäste leisten und

01:18:07.240 --> 01:18:09.480
dann würde ich ja einfach gar

01:18:09.480 --> 01:18:11.260
nicht mehr, ich wäre dann einfach gar nicht mehr hier,

01:18:11.420 --> 01:18:13.300
sondern ihr würdet euch richtige, kompetente Gäste

01:18:13.300 --> 01:18:15.300
brauchen. Vielleicht könnte man sich dann auch

01:18:15.300 --> 01:18:17.340
andere Hosts leisten, die das so

01:18:17.340 --> 01:18:18.880
etwas professioneller machen und sowieso

01:18:18.880 --> 01:18:21.100
eine andere Webseite, die auch nicht so kacke aussieht

01:18:21.100 --> 01:18:23.160
und dann könnten wir endlich, was könnten wir

01:18:23.160 --> 01:18:25.080
denn dann eigentlich machen? Ich wollte mir ein Schloss kaufen.

01:18:25.160 --> 01:18:27.140
Dann könnten wir uns an den Strand setzen und mal

01:18:27.140 --> 01:18:29.060
eure Hobbys verfolgen, vielleicht, keine Ahnung,

01:18:29.440 --> 01:18:30.580
vielleicht machen wir einen Podcast auf.

01:18:34.180 --> 01:18:34.540
Ja.

01:18:35.080 --> 01:18:35.360
Naja.

01:18:36.700 --> 01:18:38.560
Ich hab schon gesagt, ich warte immer noch auf mein Schloss.

01:18:39.640 --> 01:18:39.820
Ja.

01:18:40.820 --> 01:18:41.580
Auch, möchtest du auch?

01:18:41.620 --> 01:18:43.640
noch einen Spendenaufruf starten. Also mein Spendenaufruf

01:18:43.640 --> 01:18:45.660
war für ein gescheites Mikrofon, Dominik's

01:18:45.660 --> 01:18:46.780
Spendenaufruf ist für ein Schloss.

01:18:47.740 --> 01:18:49.620
Ja, für mein, nicht für ein Schloss, für mein

01:18:49.620 --> 01:18:51.100
Schloss. Ja, ja, für sein Schloss. Ja, okay.

01:18:52.700 --> 01:18:53.580
In dieser ganzen,

01:18:53.700 --> 01:18:55.500
in diesen ganzen anderthalb Stunden, wo wir jetzt schon

01:18:55.500 --> 01:18:57.580
zusammensitzen, haben wir

01:18:57.580 --> 01:18:59.520
jetzt tatsächlich noch gar nicht drüber gesprochen, was

01:18:59.520 --> 01:19:01.680
eine Hashmap überhaupt ist. Du hast die Stunde vorher vergessen,

01:19:01.740 --> 01:19:03.440
wenn wir gebraucht haben, unser Audioequipment vorzubereiten,

01:19:03.540 --> 01:19:05.780
obwohl wir alle voll drauf sind. Ja, das ist halt am einen schlechten Mikrofon,

01:19:05.900 --> 01:19:06.080
aber

01:19:06.080 --> 01:19:09.480
trotzdem sind wir noch nicht so weit gekommen, zu

01:19:09.480 --> 01:19:11.440
erklären, was überhaupt eine Hashmap ist und wie sie

01:19:11.440 --> 01:19:12.580
funktioniert. Ja, okay. Das stimmt.

01:19:13.800 --> 01:19:14.980
Also das ist irgendwas, wo man

01:19:14.980 --> 01:19:17.080
ganz schnell nachgucken kann, weil man direkt weiß, wo es ist.

01:19:17.400 --> 01:19:19.500
Also man kann quasi dem Key ansehen,

01:19:19.640 --> 01:19:20.500
wo er sein muss.

01:19:21.440 --> 01:19:23.360
Oder so. Dem Key nicht,

01:19:23.520 --> 01:19:25.660
aber man kann aus dem Key was rauskitzeln.

01:19:26.040 --> 01:19:27.480
Okay, aber aus diesem Rauskitzeln

01:19:27.480 --> 01:19:29.480
weiß man direkt, wo es sein muss, weil

01:19:29.480 --> 01:19:31.480
das irgendwie...

01:19:32.540 --> 01:19:33.720
Ja, der Trick

01:19:33.720 --> 01:19:36.060
ist im Wesentlichen

01:19:36.060 --> 01:19:37.660
schon im Namen. Also man nimmt

01:19:37.660 --> 01:19:39.760
nicht die Keys selber, sondern man nimmt Hashes von Keys.

01:19:40.100 --> 01:19:41.360
Deswegen muss es auch Hatchable sein.

01:19:41.440 --> 01:19:58.120
Genau deshalb muss es hashable sein. Und weil eine Eigenschaft eine Hash-Funktion sein soll, dass sie nicht vorhersehbar ist, bedeutet das auch, dass sie gleich verteilt ist über den Raum der möglichen Hash-Ausgänge.

01:19:59.140 --> 01:20:07.320
Das bedeutet, wenn ich aus einem Wert einen Hash mache, dann kriege ich im Wesentlichen einen zufälligen Wert in der Menge aller möglichen Hashes raus.

01:20:08.300 --> 01:20:09.840
Und wenn ich diesen Hash jetzt

01:20:09.840 --> 01:20:12.160
mit Modulo nehme, ja, und quasi

01:20:12.160 --> 01:20:13.980
als Index in eine Liste reinnehme,

01:20:15.040 --> 01:20:16.060
dann bedeutet

01:20:16.060 --> 01:20:17.600
es, dass der irgendwo hinzeigt.

01:20:17.900 --> 01:20:19.240
An einen Index, der

01:20:19.240 --> 01:20:22.160
nicht vorhersehbar ist und

01:20:22.160 --> 01:20:24.260
der auch gleich verteilt ist über die gesamte

01:20:24.260 --> 01:20:26.100
Reichweite der Liste. Aber ich muss

01:20:26.100 --> 01:20:27.940
da reingehen, quasi die Länge der Liste. Das heißt, ich weiß,

01:20:28.040 --> 01:20:30.020
wie groß das maximale Reich ist. Genau, ich muss wissen, wie groß

01:20:30.020 --> 01:20:32.180
die Liste ist. Beziehungsweise Python

01:20:32.180 --> 01:20:33.360
macht da viele coole Tricks,

01:20:34.140 --> 01:20:34.260
die

01:20:34.260 --> 01:20:37.880
dir helfen. Magie, Magie.

01:20:38.100 --> 01:20:40.000
Aber das ist bei einer Hashmap

01:20:40.000 --> 01:20:42.060
immer so, die hat so einen Füllungsgrad,

01:20:42.140 --> 01:20:43.800
wir haben es vorhin schon angesprochen, bei Python ist es

01:20:43.800 --> 01:20:45.360
2 Drittel, die ist maximal 2 Drittel voll.

01:20:45.580 --> 01:20:46.820
Also Wurzel 3, hast du gesagt.

01:20:47.660 --> 01:20:49.240
Wurzel 3 wäre noch besser, aber

01:20:49.240 --> 01:20:51.800
das ist halt leider kein Integer.

01:20:51.920 --> 01:20:53.060
Ist das der goldene Schnitt? Nein.

01:20:55.040 --> 01:20:55.900
Ne, der goldene Schnitt

01:20:55.900 --> 01:20:58.140
ist 1,618 noch was.

01:20:58.360 --> 01:20:59.080
Was ist Wurzel 3?

01:20:59.080 --> 01:21:00.380
Der heißt auch Phi.

01:21:02.160 --> 01:21:02.840
Wurzel 3 ist

01:21:02.840 --> 01:21:04.260
1,7 irgendwas.

01:21:04.260 --> 01:21:05.460
Verdammt, knapp daneben.

01:21:08.100 --> 01:21:09.660
Vielleicht noch besser.

01:21:09.940 --> 01:21:11.000
Ist übrigens auch interessant,

01:21:11.160 --> 01:21:12.520
weil ternäre Logik wäre besser,

01:21:12.760 --> 01:21:15.300
weil das näher an irgendeiner Zahl dran ist.

01:21:15.380 --> 01:21:16.660
Ach, keine Ahnung, spielt keine Rolle jetzt.

01:21:18.500 --> 01:21:19.440
Das Wichtige ist,

01:21:20.300 --> 01:21:23.760
wenn ich aus einem Diktionario rauslesen möchte,

01:21:25.360 --> 01:21:28.120
dann nehme ich den Key, den ich lesen möchte

01:21:28.120 --> 01:21:28.920
und hashe den

01:21:28.920 --> 01:21:33.440
und nehme dann diesen Hash als Index in eine Liste rein.

01:21:33.800 --> 01:21:35.980
Und wenn in dieser Liste an der Stelle was steht,

01:21:36.860 --> 01:21:37.620
was nicht None ist,

01:21:38.100 --> 01:21:40.240
dann ist das der Wert,

01:21:40.980 --> 01:21:43.120
der zu diesem Key gespeichert wurde.

01:21:45.200 --> 01:21:49.840
Und umgekehrt, wenn ich in eine Hashmap etwas reinschreiben möchte,

01:21:51.160 --> 01:21:53.860
dann mache ich den Hash aus diesem Key

01:21:53.860 --> 01:21:57.940
und schreibe den Wert in diese Liste

01:21:57.940 --> 01:22:00.120
an der Stelle des Hashindex rein.

01:22:01.020 --> 01:22:02.300
Und das ist sozusagen der Trick.

01:22:02.880 --> 01:22:05.140
Ich berechne einen, ich nenne es mal,

01:22:05.260 --> 01:22:06.980
zufälligen Index in diese Liste

01:22:06.980 --> 01:22:09.260
weil der gleich

01:22:09.260 --> 01:22:11.260
verteilt ist, weil diese Hash-Funktion gleich verteilt

01:22:11.260 --> 01:22:13.120
ist, füllt die diese Liste

01:22:13.120 --> 01:22:15.020
gleichmäßig auf und

01:22:15.020 --> 01:22:17.460
kann

01:22:17.460 --> 01:22:17.760
dann

01:22:17.760 --> 01:22:21.400
eben in O von 1, weil diese Berechnung

01:22:21.400 --> 01:22:22.860
dieses Hashes immer gleich lange dauert,

01:22:23.420 --> 01:22:24.960
diesen zufälligen Index finden und dann

01:22:24.960 --> 01:22:26.980
da reinschreiben. Jetzt gibt es ein Problem.

01:22:27.500 --> 01:22:29.120
Was ist, wenn zwei Hashes zu dem

01:22:29.120 --> 01:22:31.200
auf den gleichen, also wenn zwei Keys auf den

01:22:31.200 --> 01:22:32.320
gleichen Hash-Index zeigen?

01:22:33.260 --> 01:22:34.840
Und das passiert, wenn wir

01:22:34.840 --> 01:22:37.200
Wenn wir ein Dictionary haben, was acht Einträge hat,

01:22:37.900 --> 01:22:40.540
dann ist die Wahrscheinlichkeit, dass zwei auf den gleichen Index zeigen,

01:22:40.640 --> 01:22:41.360
vergleichsweise hoch.

01:22:42.040 --> 01:22:42.820
Eins zu acht.

01:22:44.600 --> 01:22:47.780
Das heißt, man muss sich eine Technik überlegen,

01:22:47.900 --> 01:22:50.180
um sogenannte Kollisionen zu vermeiden.

01:22:52.020 --> 01:22:53.420
Und da gibt es zwei Möglichkeiten.

01:22:53.420 --> 01:22:57.480
Entweder kann ich sagen, jeder Eintrag in meinem Dictionary ist eine Liste.

01:22:59.300 --> 01:23:01.000
Das heißt, wenn zwei auf die gleiche Sache herrschen,

01:23:01.100 --> 01:23:02.560
dann muss ich halt durch diese Liste durchgucken

01:23:02.560 --> 01:23:03.980
und da den entsprechenden Wert rausholen.

01:23:04.840 --> 01:23:23.280
Das heißt Chaining. Oder man kann einen neuen Hash berechnen und sagen, wenn da eine Kollision ist, dann verändere ich meine Hash-Berechnung und wähle sozusagen einen neuen zufälligen Hash. Und die Wahrscheinlichkeit, dass da eine Kollision auftritt, wird eben jedes Mal kleiner. Und das heißt Open Addressing.

01:23:24.100 --> 01:23:38.240
Und Python Dictionaries machen tatsächlich Open Addressing, das heißt, die haben keine Liste an jeder Stelle gespeichert, sondern die sagen halt, wenn da eine Kollision ist, wenn das nicht der richtige Key ist, den ich da gefunden habe, dann muss ich diesen Prozess fortsetzen.

01:23:38.800 --> 01:23:41.500
Muss einfach sozusagen nochmal einen Hash berechnen.

01:23:41.680 --> 01:23:42.320
Ein Hash vom Hash.

01:23:43.340 --> 01:23:50.180
Ja, da wird dann so ein Counter mitlaufen gelassen, damit man eben wieder diese Eigenschaft hat, aber sozusagen diese Bits wiederverwenden kann.

01:23:51.460 --> 01:23:53.900
Dass du nicht in zwei Richtungen wächst,

01:23:54.020 --> 01:23:57.120
sondern dass deine Hashmap einfach nur in eine Richtung wächst.

01:23:58.260 --> 01:23:59.700
Das sind Implementierungsdetails.

01:23:59.840 --> 01:24:01.300
Aber das ist im Wesentlichen die Magie,

01:24:01.500 --> 01:24:03.080
dass man aus dem Key einen Hash berechnet

01:24:03.080 --> 01:24:04.500
und dieser Hash hat eine gewisse Eigenschaft

01:24:04.500 --> 01:24:05.860
und die heißt gleich verteilt.

01:24:07.120 --> 01:24:09.400
Und auch wenn ich die auf einen Index zusammendampfe,

01:24:09.500 --> 01:24:10.720
dann sind sie immer noch gleich verteilt

01:24:10.720 --> 01:24:11.600
und das ist der Trick da dran.

01:24:12.180 --> 01:24:13.940
Bedeutet halt, dass der Key hashable sein muss.

01:24:15.200 --> 01:24:17.520
Es gibt eine ähnliche Datenstruktur, die heißt TreeMap.

01:24:19.340 --> 01:24:21.540
Da werden die Keys in einen Tree abgelegt.

01:24:21.760 --> 01:24:23.080
Dann müssen sie nicht hashable sein,

01:24:23.140 --> 01:24:24.180
dann müssen sie sortierbar sein.

01:24:26.260 --> 01:24:27.160
Und dann habe ich halt einen Tree.

01:24:27.300 --> 01:24:29.660
Dann habe ich Zugriffe, die alle log-in sind.

01:24:30.600 --> 01:24:30.800
Genau.

01:24:32.760 --> 01:24:34.100
Ich weiß nicht, ob es immer noch so ist,

01:24:34.320 --> 01:24:38.440
die Hash-Map-Default-Implementation

01:24:38.440 --> 01:24:41.640
der Standard-C++-Bibliothek von Boost

01:24:41.640 --> 01:24:43.540
war irgendwie so ein Tree-Map.

01:24:43.760 --> 01:24:44.400
Eine Tree-Map, ja.

01:24:44.440 --> 01:24:46.240
Und hat dann irgendwie,

01:24:46.240 --> 01:24:48.840
als wenn man was optimieren wollte,

01:24:49.340 --> 01:24:51.280
dann ein C++ geschrieben habe und dann war das

01:24:51.280 --> 01:24:53.120
überraschend von der Performance her, weil das war dann hinterher

01:24:53.120 --> 01:24:55.060
langsamer als die Ticks und Beiden.

01:24:55.820 --> 01:24:56.220
Großartig.

01:24:58.220 --> 01:24:59.380
In Java gibt es diese

01:24:59.380 --> 01:25:01.260
beiden Optionen unter diesen Namen. Es gibt

01:25:01.260 --> 01:25:03.260
HashMap und es gibt DreamMap. Das heißt, bei Java

01:25:03.260 --> 01:25:04.860
muss man sich immer raussuchen, was man haben möchte.

01:25:06.380 --> 01:25:07.300
Die Antwort ist immer HashMap,

01:25:07.400 --> 01:25:07.700
aber egal.

01:25:13.440 --> 01:25:15.600
Und natürlich bei einer HashMap

01:25:15.600 --> 01:25:17.260
heißt das, dass man immer Hash-Funktionen

01:25:17.260 --> 01:25:19.100
haben muss. Und Hash-Funktionen sind auch

01:25:19.100 --> 01:25:21.060
so eine Sache. Die müssen

01:25:21.060 --> 01:25:23.180
schnell sein und trotzdem gut und ich möchte

01:25:23.180 --> 01:25:25.080
gerne viele verschiedene haben und

01:25:25.080 --> 01:25:26.980
die sollen alle schnell sein und alle

01:25:26.980 --> 01:25:29.080
möglichst gut. Und da die

01:25:29.080 --> 01:25:30.920
richtige Hash-Funktion rauszufinden

01:25:30.920 --> 01:25:33.140
und eine gute Implementation davon zu haben, ist nicht ganz

01:25:33.140 --> 01:25:33.540
einfach.

01:25:35.560 --> 01:25:36.780
Welche wird verwendet?

01:25:37.580 --> 01:25:38.340
Das weiß ich nicht.

01:25:39.180 --> 01:25:41.220
Na, ich stelle

01:25:41.220 --> 01:25:42.600
dir Fragen, das weiß ich nicht.

01:25:43.020 --> 01:25:44.840
Ja, es gibt ja so Hash-Funktionen, die kennt man ja.

01:25:44.900 --> 01:25:46.900
Es gibt MD5 und SHA-1

01:25:46.900 --> 01:25:48.820
und SHA-256 und

01:25:48.820 --> 01:25:51.100
CRC32 und die sind

01:25:51.100 --> 01:25:52.380
aber alle nicht geeignet dafür

01:25:52.380 --> 01:25:55.100
und dann gibt es so welche, die kennt man

01:25:55.100 --> 01:25:57.080
überhaupt nicht und die haben

01:25:57.080 --> 01:25:58.480
auch abgefahrene lustige Namen,

01:25:58.900 --> 01:26:00.820
von denen ich jetzt keinen einzigen sagen kann, weil ich

01:26:00.820 --> 01:26:02.860
kenne sie ja nicht, die aber eben

01:26:02.860 --> 01:26:04.900
keine kryptografischen Hashes sind, sondern

01:26:04.900 --> 01:26:06.540
eben solche Hash-Funktionen, die man für solche

01:26:06.540 --> 01:26:07.540
Satenstrukturen verwendet,

01:26:08.460 --> 01:26:10.820
die dann halt aber andere Eigenschaften haben.

01:26:10.900 --> 01:26:12.840
Die brauchen dann nur acht Cycles und

01:26:12.840 --> 01:26:15.000
geben nur zwei Byte als Hash zurück

01:26:15.000 --> 01:26:15.900
oder irgendwie solchen Quatsch,

01:26:16.100 --> 01:26:18.220
weil das hier viel, viel wichtiger ist.

01:26:18.820 --> 01:26:24.840
Ja, also ich kenne die Hash-Funktion für kleine Integers

01:26:24.840 --> 01:26:26.400
und die ist sehr einfach.

01:26:26.700 --> 01:26:27.880
Die ist das Integer selber.

01:26:29.500 --> 01:26:32.020
Also der Hash von 1 ist 1, der Hash von 2 ist 2.

01:26:32.760 --> 01:26:34.420
Aber das wird dann, wenn die Zahlen größer werden,

01:26:34.520 --> 01:26:35.140
ist das dann nicht mehr so toll.

01:26:35.140 --> 01:26:37.000
Aber das ist der Hash von 128, Jochen.

01:26:37.840 --> 01:26:39.220
Das glaube ich auch immer noch, 128.

01:26:39.920 --> 01:26:41.220
Ah, ich glaube, es geht nur bis 127.

01:26:41.540 --> 01:26:42.360
Ja, ich weiß.

01:26:42.500 --> 01:26:44.880
Ich glaube, Small Integer in Python geht nur bis 127.

01:26:44.880 --> 01:26:46.960
Moment, Moment, ich habe doch hier die Rappel schon aufgemacht,

01:26:46.960 --> 01:26:48.020
da kann ich auch gleich nochmal

01:26:48.020 --> 01:26:49.920
128.

01:26:51.780 --> 01:26:52.480
Ich habe ja kürzlich

01:26:52.480 --> 01:26:54.500
immer noch 128, aber wenn ich

01:26:54.500 --> 01:26:56.780
512, verdoppeln

01:26:56.780 --> 01:26:58.300
war eine gute Strategie, habt ihr eben gesagt.

01:26:58.980 --> 01:27:00.460
512 ist auch immer noch, 512

01:27:00.460 --> 01:27:02.680
bei 1024 auch immer noch, oh mein Gott.

01:27:03.360 --> 01:27:04.780
65. Vielleicht ist es bei Integers

01:27:04.780 --> 01:27:05.640
einfach immer so.

01:27:06.420 --> 01:27:08.880
Nein, nein, wenn die wirklich groß werden,

01:27:08.940 --> 01:27:10.600
dann ist es nicht mehr so. Okay, sie müssen

01:27:10.600 --> 01:27:12.280
wirklich groß werden. Ich bin gerade schon bei einer Million,

01:27:12.700 --> 01:27:14.900
bei der Milliarde. Dann sind es vermutlich 32

01:27:14.900 --> 01:27:16.400
Bit, wenn die über 32 Bit sind.

01:27:16.960 --> 01:27:19.520
Unsigned and, man weiß es nicht,

01:27:19.580 --> 01:27:20.500
mal ein Minus.

01:27:21.560 --> 01:27:23.580
Es gibt ja ein sehr schönes Paper, das heißt

01:27:23.580 --> 01:27:25.860
People mistake knowledge

01:27:25.860 --> 01:27:27.380
on the internet for their own knowledge.

01:27:27.940 --> 01:27:29.500
Du hast eine gefunden. Also ich habe eine gefunden,

01:27:29.780 --> 01:27:31.780
aber da musste ich jetzt schon irgendwie 20, 30 Nullen

01:27:31.780 --> 01:27:33.440
hintendran machen. Ich weiß gar nicht mehr, wie das heißt.

01:27:35.360 --> 01:27:35.940
Das sind die,

01:27:36.060 --> 01:27:37.380
die früher L hießen. Das war super.

01:27:37.780 --> 01:27:38.880
Erstmal mal verdoppeln, also

01:27:38.880 --> 01:27:41.620
12.420, dann 10.000, 100.000,

01:27:41.620 --> 01:27:43.540
1.000.000, 10.000.000, 100.000.000

01:27:43.540 --> 01:27:45.500
und dann auf einmal so. Ich weiß nicht, wie die Zahl

01:27:45.500 --> 01:27:47.500
heißt, die jetzt da rausgefallen ist, aber ich weiß

01:27:47.500 --> 01:27:49.460
jetzt doch, bis wo denn das

01:27:49.460 --> 01:27:51.260
wohl ist, das ist wohl tatsächlich bis zur Grenze, bis zur

01:27:51.260 --> 01:27:53.380
64-Bit-Grenze, weil das, was hier rausgefallen

01:27:53.380 --> 01:27:55.440
ist, ist irgendwie maximal 64-Bit.

01:27:55.540 --> 01:27:57.400
Aber wo es halt die Implementation-Details

01:27:57.400 --> 01:27:59.320
sind, das ist eigentlich signed oder unsigned in Python

01:27:59.320 --> 01:28:01.020
und was ist das in 64 oder in 32?

01:28:01.020 --> 01:28:03.160
Das ist signed, meine ich.

01:28:04.800 --> 01:28:05.540
In Python

01:28:05.540 --> 01:28:07.460
die Integer sind Long-Integer.

01:28:08.120 --> 01:28:09.060
Also 64, also

01:28:09.060 --> 01:28:11.240
es gab früher eine Unterscheidung zwischen Long-Integer

01:28:11.240 --> 01:28:13.180
und Integer, die gibt es halt Python 3 nicht mehr.

01:28:13.180 --> 01:28:15.480
Ist jeder Integer eine Ganzzahl

01:28:15.480 --> 01:28:17.440
und die verhalten sich auch korrekt wie mathematische

01:28:17.440 --> 01:28:18.920
Ganzzahlen. Du kannst beliebig viele Stellen machen.

01:28:19.740 --> 01:28:21.120
Die Implementation dahinter

01:28:21.120 --> 01:28:23.400
schaltet um zwischen Integers

01:28:23.400 --> 01:28:25.320
und Long-Integers. Aber das ist ja nur

01:28:25.320 --> 01:28:27.220
ein Implementationsdetail. Das ist nur

01:28:27.220 --> 01:28:28.360
ein Umsetzungsdetail.

01:28:29.680 --> 01:28:31.260
Hash von minus 1 ist minus...

01:28:31.260 --> 01:28:33.640
Hash von minus 1

01:28:33.640 --> 01:28:34.500
ist minus 2. Ja, schön.

01:28:35.860 --> 01:28:36.440
Interessant. Okay.

01:28:37.440 --> 01:28:39.320
Wieder was gelernt. Gut. Die exakte

01:28:39.320 --> 01:28:40.420
Funktion spielt gar keine Rolle.

01:28:41.120 --> 01:28:43.220
Wenn du Hash von irgendeinem String machst, kriegst du halt auch

01:28:43.220 --> 01:28:43.980
irgendeine Zahl raus.

01:28:45.760 --> 01:28:47.260
Das Wichtige ist eher, dass das

01:28:47.260 --> 01:28:48.680
schnell sein muss und dass es

01:28:48.680 --> 01:28:51.060
deterministisch ist und so weiter und diese ganzen

01:28:51.060 --> 01:28:52.660
Eigenschaften, die man so stellt an

01:28:52.660 --> 01:28:54.840
Funktionen und halt,

01:28:55.600 --> 01:28:57.100
dass es gleich verteilt ist über die Menge

01:28:57.100 --> 01:28:58.700
der Hashes. Und ich glaube, die Menge der Hashes,

01:28:59.020 --> 01:29:01.180
wenn du die Zahlen vor dir hast, Jochen, die sehen aus wie 32

01:29:01.180 --> 01:29:01.780
Bits-Zahlen, oder?

01:29:03.160 --> 01:29:03.560
Ja.

01:29:04.720 --> 01:29:05.380
Minus 2?

01:29:07.960 --> 01:29:08.580
Minus 4.

01:29:09.240 --> 01:29:09.780
Nein, keine Ahnung.

01:29:11.120 --> 01:29:13.520
Oh, hash minus 1 ist gleich hash minus 2.

01:29:14.920 --> 01:29:16.520
Da hast du direkt eine Kollision.

01:29:16.860 --> 01:29:17.900
Dann musst du Open Addressing machen.

01:29:18.260 --> 01:29:19.620
Ja, okay.

01:29:21.080 --> 01:29:22.200
Ja, witzig, witzig.

01:29:23.100 --> 01:29:24.300
Das heißt, kann man Dicts,

01:29:24.420 --> 01:29:26.580
Keys, wenn das Int sein können,

01:29:26.640 --> 01:29:27.780
können das auch negative Int sein?

01:29:28.060 --> 01:29:29.080
Ja, na klar.

01:29:29.800 --> 01:29:31.440
Alles, was Hash-Build ist.

01:29:31.520 --> 01:29:34.840
Das heißt, wenn du minus 1 reinschreibst,

01:29:34.960 --> 01:29:36.360
dann muss er tatsächlich eine Kollision machen

01:29:36.360 --> 01:29:38.480
und minus 2, dann muss er quasi eine Ebene tiefer gehen.

01:29:38.480 --> 01:29:39.160
Ja, okay.

01:29:40.240 --> 01:29:42.440
Du kannst auch deine eigenen Objekte

01:29:42.440 --> 01:29:44.560
ersparen werden. Ja, genau. Das ist auch etwas, was ich gerne

01:29:44.560 --> 01:29:45.260
mache, tatsächlich.

01:29:46.780 --> 01:29:48.420
Und was Leute mal so überrascht,

01:29:48.480 --> 01:29:50.480
wenn man dann Objekte als Keys hat, dann

01:29:50.480 --> 01:29:50.980
sagen die immer so,

01:29:51.480 --> 01:29:54.120
aber nein, das geht.

01:29:54.340 --> 01:29:56.480
Das ist okay. Du solltest dann eigentlich

01:29:56.480 --> 01:29:57.980
auch immer noch Frozen-Versionen machen.

01:29:58.460 --> 01:30:00.360
Musst du dann eine Methode an deine Klasse dran machen, die

01:30:00.360 --> 01:30:02.440
hashable ist? Ja, das muss natürlich hashable

01:30:02.440 --> 01:30:04.060
sein. Wie wird das hashable?

01:30:04.240 --> 01:30:05.840
Was versucht der beim Hash denn zu machen?

01:30:06.460 --> 01:30:08.300
Implementierst einfach Dunder-Hash.

01:30:08.520 --> 01:30:10.900
Dann wird die aufgerufen und dann

01:30:10.900 --> 01:30:12.840
kannst du, wenn du eine ID schon hast,

01:30:13.120 --> 01:30:14.460
dann kannst du die natürlich auch zurückgeben.

01:30:15.220 --> 01:30:16.500
Oder du kannst halt, ja,

01:30:16.960 --> 01:30:17.820
wie auch immer du das...

01:30:17.820 --> 01:30:20.580
Also du gibst etwas zu...

01:30:20.580 --> 01:30:22.340
Jedes Objekt ist doch herrschbar, oder?

01:30:22.960 --> 01:30:24.840
Die Objektidentität als Herrschfunktion.

01:30:26.040 --> 01:30:27.000
Ja, das kann natürlich sein,

01:30:27.040 --> 01:30:28.460
dass das der Default ist.

01:30:30.460 --> 01:30:30.820
Ja.

01:30:31.020 --> 01:30:32.820
Hm, wie könnte man das jetzt schnell rausfinden?

01:30:33.000 --> 01:30:33.120
Ha.

01:30:35.420 --> 01:30:36.660
Hey, dann mal auf.

01:30:37.100 --> 01:30:37.780
Dann dein Hash.

01:30:38.520 --> 01:30:40.560
Help, dann dein Hash, wie wäre das denn?

01:30:41.140 --> 01:30:42.380
Genau, aber du kannst natürlich

01:30:42.380 --> 01:30:43.640
deine eigene Hash

01:30:43.640 --> 01:30:45.720
Scheint so zu sein, ja.

01:30:45.740 --> 01:30:46.540
Help, dann dein Hash?

01:30:49.140 --> 01:30:50.760
Du kannst natürlich deine eigene Funktion

01:30:50.760 --> 01:30:51.960
da reinschreiben, das heißt, du kannst

01:30:51.960 --> 01:30:54.180
eine Hash-Methode schreiben, die

01:30:54.180 --> 01:30:55.800
für deine Objekte spezifisch ist.

01:30:57.100 --> 01:30:58.120
Aber wenn du das machst,

01:30:59.360 --> 01:31:00.560
wenn man seine eigene Hash-Methode

01:31:00.560 --> 01:31:02.480
implementiert, dann muss man wirklich

01:31:02.480 --> 01:31:04.380
darauf achten, dass sich

01:31:04.380 --> 01:31:06.200
Keys in einem Dictionary nicht ändern dürfen.

01:31:07.280 --> 01:31:08.600
Das heißt, wenn ich einem Objekt

01:31:08.600 --> 01:31:11.540
eine Hash-Funktion gebe,

01:31:11.840 --> 01:31:12.700
eine Hash-Methode gebe,

01:31:13.260 --> 01:31:15.440
die sich zwischendurch verändern kann,

01:31:15.560 --> 01:31:16.620
dann geht mein Dictionary kaputt.

01:31:16.880 --> 01:31:16.980
Ja.

01:31:18.980 --> 01:31:20.760
Und das geht dann auch gleich richtig kaputt,

01:31:20.860 --> 01:31:22.420
weil dann finde ich gar nichts mehr in meinem Dictionary.

01:31:27.460 --> 01:31:28.140
Ja, ja, ja.

01:31:28.220 --> 01:31:30.080
Also da muss man dann natürlich aufpassen.

01:31:30.220 --> 01:31:32.080
Aber ich meine, oft hat man ja tatsächlich eine ID,

01:31:32.140 --> 01:31:32.700
die man nehmen kann.

01:31:33.540 --> 01:31:35.220
Und man gibt halt bei der Hash-Methode,

01:31:35.220 --> 01:31:36.160
man rechnet das nicht selber aus,

01:31:36.220 --> 01:31:38.300
aber man gibt halt etwas zurück, was dann

01:31:38.300 --> 01:31:39.740
durch Hash nochmal durchläuft.

01:31:39.980 --> 01:31:42.220
Man fällt zurück auf irgendwas, aber dass man

01:31:42.220 --> 01:31:44.240
halt sagt, okay, eine Adresse ist halt,

01:31:44.360 --> 01:31:46.180
der Hash einer Adresse ist der Hash aus der

01:31:46.180 --> 01:31:48.340
Straße und der Postleitzahl und der

01:31:48.340 --> 01:31:50.120
Stadt, das ist ja schon

01:31:50.120 --> 01:31:52.100
irgendwie naheliegend, dass du halt irgendeinen

01:31:52.100 --> 01:31:53.880
wegbildest, was du dann hashst.

01:31:55.520 --> 01:31:55.720
Und

01:31:55.720 --> 01:31:57.620
klar, das kann man natürlich

01:31:57.620 --> 01:32:00.080
machen. In meiner

01:32:00.080 --> 01:32:02.060
Erfahrung tritt es nicht so häufig auf, aber wenn

01:32:02.060 --> 01:32:03.980
du sagst doch, dass du das gerne machst, dann

01:32:05.980 --> 01:32:07.700
Vielleicht mach ich es auch falsch, ich weiß es nicht so genau.

01:32:08.200 --> 01:32:09.780
Also ja, gerade mit

01:32:09.780 --> 01:32:11.800
Zusammenhang mit Data Classes,

01:32:11.820 --> 01:32:13.220
beziehungsweise so Atris, da benutze ich...

01:32:13.220 --> 01:32:14.860
Data Classes sind ja automatisch hashable, oder?

01:32:15.240 --> 01:32:18.000
Ja, bei Data Classes weiß ich es gar nicht so genau.

01:32:18.000 --> 01:32:20.040
Also ich hab das jetzt, das, was ich jetzt im Kopf hab,

01:32:20.060 --> 01:32:21.920
ist mit Atris und da muss man dann auch,

01:32:21.960 --> 01:32:23.840
da kann man dann auch solche Sachen sagen, also einmal, man kann es natürlich

01:32:23.840 --> 01:32:25.960
selber implementieren, aber man kann auch sagen irgendwie,

01:32:26.380 --> 01:32:28.180
also ich hab, es soll hashable sein

01:32:28.180 --> 01:32:30.040
und diese Attribute will ich dafür

01:32:30.040 --> 01:32:31.860
verwenden und die müssen dann auch natürlich auch in der Uni sein

01:32:31.860 --> 01:32:33.040
und so, ja.

01:32:34.280 --> 01:32:35.880
Und dann macht es manchmal Sinn,

01:32:35.960 --> 01:32:37.820
weil dann kann man halt bestimmte Sachen

01:32:37.820 --> 01:32:39.480
look-uppen

01:32:39.480 --> 01:32:41.820
mit einem anderen bestimmten Ding und dann

01:32:41.820 --> 01:32:43.020
ist es manchmal ganz praktisch.

01:32:44.240 --> 01:32:45.820
Ja, das ist ja oft so, dass

01:32:45.820 --> 01:32:48.020
man seine

01:32:48.020 --> 01:32:49.740
Algorithmen beschleunigen kann, wenn man so ein

01:32:49.740 --> 01:32:51.520
look-up macht, wenn das

01:32:51.520 --> 01:32:52.740
in dem Algorithmus vorkommt.

01:32:53.880 --> 01:32:55.360
Wir hatten einmal so einen Fall

01:32:55.360 --> 01:32:57.640
im Computerclub, da war der

01:32:57.640 --> 01:32:59.600
Bison auch da und hat da eben seinen Algorithmus mit

01:32:59.600 --> 01:33:01.620
einer Liste geschrieben, wo er

01:33:01.620 --> 01:33:03.460
dann eben immer die Elemente aus der Liste raussuchen

01:33:03.460 --> 01:33:05.340
musste, wo er immer nachgucken musste, habe ich diesen

01:33:05.340 --> 01:33:06.340
Knoten schon besucht

01:33:06.340 --> 01:33:09.080
in der Liste und das war halt O von N

01:33:09.080 --> 01:33:10.940
und dann haben wir es umgebaut zu einem Set,

01:33:12.960 --> 01:33:13.120
was

01:33:13.120 --> 01:33:15.360
im O von 1 ist, wo diese Operation O von 1 ist

01:33:15.360 --> 01:33:17.160
und dann wird es halt deutlich schneller. Also wenn man das

01:33:17.160 --> 01:33:18.340
braucht, ist das

01:33:18.340 --> 01:33:20.220
schon ein Superpower.

01:33:22.720 --> 01:33:23.120
Ja.

01:33:24.480 --> 01:33:25.280
Hast du noch etwas

01:33:25.280 --> 01:33:26.320
auf deiner Liste stehen, Johannes?

01:33:26.940 --> 01:33:29.640
Nee, ich habe jetzt tatsächlich meinen ganzen Notizzettel

01:33:29.640 --> 01:33:31.660
abgefrühstückt.

01:33:31.740 --> 01:33:33.220
Jochen, hast du noch was zu Dikt, was wir

01:33:33.220 --> 01:33:35.200
noch nicht gefunden haben? Also ja, was ich ganz

01:33:35.200 --> 01:33:37.300
gerne vielleicht noch sagen

01:33:37.300 --> 01:33:39.180
wollen würde oder so, ist halt, dass man

01:33:39.180 --> 01:33:41.080
auch selber sich Sachen implementieren kann,

01:33:41.160 --> 01:33:42.580
die dann halt so funktionieren wie Dicts.

01:33:43.020 --> 01:33:45.140
Es gibt ja seit Python 3.3, glaube ich,

01:33:45.660 --> 01:33:46.860
Protocols oder was weiß ich wie das.

01:33:47.060 --> 01:33:48.820
Man hat halt auf jeden Fall diese AppSecBase-Klasses,

01:33:49.340 --> 01:33:51.200
wo es dann Interfaces für diese ganzen Geschichten gibt.

01:33:51.520 --> 01:33:53.160
Und da hat man dann halt...

01:33:53.160 --> 01:33:55.260
Moment, also Protocols sind fertige

01:33:55.260 --> 01:33:56.940
ABCs, AppSecBase-Klasses? Protocols sind was

01:33:56.940 --> 01:33:59.380
total Cooles. Die Implementierung

01:33:59.380 --> 01:34:01.080
von Python-Modulen,

01:34:01.200 --> 01:34:03.200
die es schon gibt? Ach, cool.

01:34:03.420 --> 01:34:04.560
Die kann man ja auch fürs Typing dann benutzen.

01:34:04.560 --> 01:34:06.760
und so. Ja, genau. Und die sind großartig

01:34:06.760 --> 01:34:08.520
fürs Typing. Da kann man nämlich richtig gutes

01:34:08.520 --> 01:34:10.660
Duck-Typing machen, was aber trotzdem getypt

01:34:10.660 --> 01:34:12.540
ist. Genau. Das ist großartig. Genau. Und dann kannst du

01:34:12.540 --> 01:34:14.440
eben deine eigene, für

01:34:14.440 --> 01:34:16.560
eben deinen Anwendungsfall etwas Spezielles hinbauen,

01:34:16.760 --> 01:34:18.520
wo du dann sicher sein kannst, dass sich das dann aber

01:34:18.520 --> 01:34:20.060
genauso verhält und auch an den Stellen

01:34:20.060 --> 01:34:22.380
verwendet werden kann, wo du normalerweise

01:34:22.380 --> 01:34:23.420
ein DIC benutzen würdest und so.

01:34:23.720 --> 01:34:25.480
Da kannst du auch sehr coole Sachen mitmachen.

01:34:26.820 --> 01:34:28.220
Wobei das Protokoll von einem DIC-Driver

01:34:28.220 --> 01:34:30.340
ist ja vergleichsweise groß. Was ist das denn?

01:34:30.460 --> 01:34:32.060
Was ist denn ein DIC-Type? Das ist, meine ich, mappable,

01:34:32.320 --> 01:34:34.420
aber ich gucke mal gerade.

01:34:34.560 --> 01:34:35.520
wo haben wir das denn da?

01:34:36.000 --> 01:34:38.520
Es gibt Mapping, Mapping heißt das, genau.

01:34:39.840 --> 01:34:40.320
Ein Mapping.

01:34:40.600 --> 01:34:41.380
Mutable Mapping.

01:34:43.040 --> 01:34:44.520
So, ach,

01:34:44.700 --> 01:34:46.060
jetzt steht das Interface hier aber nicht dabei.

01:34:47.540 --> 01:34:48.540
Collections.abc

01:34:48.540 --> 01:34:49.540
Import.

01:34:50.880 --> 01:34:51.940
Abstract Base Class.

01:34:52.320 --> 01:34:54.300
Moment, ich importiere das gerade mal, mach mal ein Diagramm.

01:34:54.320 --> 01:34:56.260
Ja, das ist cool, weil dann kannst du einfach von Mapping ärgern lassen

01:34:56.260 --> 01:34:58.400
und alles, was du nicht implementiert hast, wird dann einfach direkt

01:34:58.400 --> 01:34:59.180
geraced.

01:35:00.420 --> 01:35:02.260
Genau. Wenn das halt nicht da ist, das ist doch schon

01:35:02.260 --> 01:35:04.720
Beziehungsweise ein MyPi oder ein Type-Checker

01:35:04.720 --> 01:35:05.640
sagt dir der auch direkt das.

01:35:05.760 --> 01:35:07.620
Ja, aber du wirst direkt gezwungen, das richtig zu implementieren.

01:35:10.480 --> 01:35:11.440
ABC Blood Collections.

01:35:11.480 --> 01:35:12.420
Ja, ich hab mich gerade geschützt.

01:35:13.300 --> 01:35:15.100
Weil ABC ist ja die ABC selber drin.

01:35:15.200 --> 01:35:15.940
Ich weiß, ich weiß.

01:35:17.760 --> 01:35:19.960
Gleichzeitig reden, tippen und das alles.

01:35:20.280 --> 01:35:21.320
Ich glaube, was du auch machen kannst,

01:35:21.420 --> 01:35:22.120
wo keiner zu sehen kann.

01:35:22.120 --> 01:35:23.940
Mach mal ein neues Objekt von Mapping auf, einfach.

01:35:26.500 --> 01:35:27.920
Das kannst du nicht ins Studio.

01:35:27.940 --> 01:35:29.480
Sehen Sie nächstes Mal in diesem Podcast.

01:35:30.820 --> 01:35:31.500
Das geht nicht.

01:35:31.800 --> 01:35:33.420
Genau, da steht aber jetzt dann, was du brauchst.

01:35:34.720 --> 01:35:35.600
Ja, okay.

01:35:36.640 --> 01:35:37.760
Du musst halt Get-Item-Itter

01:35:37.760 --> 01:35:39.660
und Längen definieren von meinem

01:35:39.660 --> 01:35:41.680
Wrapping. Okay, zumindest, ja.

01:35:41.940 --> 01:35:43.560
Also das Interface selber ist jetzt doch

01:35:43.560 --> 01:35:44.720
etwas größer, das sind halt

01:35:44.720 --> 01:35:46.620
37

01:35:46.620 --> 01:35:49.380
Methoden und das ist natürlich schon eine ganze Menge.

01:35:49.700 --> 01:35:51.580
Ja, das hatten wir ja vorhin auch schon angesprochen, dass eben

01:35:51.580 --> 01:35:53.600
Dicts relativ viel Oberfläche

01:35:53.600 --> 01:35:54.260
haben. Ja.

01:35:55.280 --> 01:35:56.720
Weil sie halt für alles verwendet werden.

01:35:57.760 --> 01:35:57.920
Ja.

01:35:59.660 --> 01:36:01.580
Ja, aber eben, also man kann das

01:36:01.580 --> 01:36:03.480
halt verwenden. Interessant,

01:36:03.540 --> 01:36:03.840
interessant.

01:36:05.420 --> 01:36:07.480
Ja. Ist das euer Lieblingsdatentyp?

01:36:10.240 --> 01:36:11.460
Ja, also von den primitiven

01:36:11.460 --> 01:36:13.440
Dingen auf jeden Fall. Ich habe das auch

01:36:13.440 --> 01:36:15.240
letztens, also diese ganzen

01:36:15.240 --> 01:36:16.140
Type-Ins,

01:36:16.380 --> 01:36:19.220
Typisierungsgeschichten, die es jetzt neuerdings gibt.

01:36:19.480 --> 01:36:21.380
Es gibt ja immer so, auf Twitter gibt es dann so

01:36:21.380 --> 01:36:23.660
die alten Säcke, die da rumhängen

01:36:23.660 --> 01:36:24.820
und die

01:36:24.820 --> 01:36:26.500
äußern sich ja manchmal.

01:36:26.500 --> 01:36:28.280
Wie alt bist du gleich noch, ihr jungen Hüpfer?

01:36:30.040 --> 01:36:31.940
Ja, sie sind noch älter als ich.

01:36:31.960 --> 01:36:33.120
Die im Kopf alten Säcke.

01:36:33.960 --> 01:36:35.620
Ja, nee, also

01:36:35.620 --> 01:36:37.780
verdiente Veteranen.

01:36:37.780 --> 01:36:39.380
Ah ja, okay, sehr schön.

01:36:39.820 --> 01:36:41.560
Der Python-Community und

01:36:41.560 --> 01:36:44.040
die sich manchmal so ein bisschen despektierlich äußern,

01:36:44.200 --> 01:36:45.880
was diese ganzen neuen

01:36:45.880 --> 01:36:47.940
Entwicklungen angeht. Der ganze Scheiß, gar nicht mehr

01:36:47.940 --> 01:36:49.940
Pythonic. Genau, und so ein bisschen

01:36:49.940 --> 01:36:51.780
kann ich das natürlich auch, kann ich das nachvollziehen, muss ich

01:36:51.780 --> 01:36:53.840
sagen. Also zum Beispiel, ich sag jetzt mal

01:36:53.840 --> 01:36:55.800
einen Namen, David Beasley zum Beispiel.

01:36:56.820 --> 01:36:57.800
Der ganz viel cooles

01:36:57.800 --> 01:36:59.920
Zeug gemacht hat, der auch eines der besten Bücher

01:36:59.920 --> 01:37:01.780
Python-Bücher geschrieben hat, irgendwie Python

01:37:01.780 --> 01:37:03.820
Essential Reference, glaube ich.

01:37:04.100 --> 01:37:06.080
War lange super. Jetzt gibt's da sogar

01:37:06.080 --> 01:37:07.720
Python Distilled, ist jetzt nochmal

01:37:07.720 --> 01:37:09.680
eine neue Ausgabe.

01:37:10.800 --> 01:37:11.360
Super Buch.

01:37:11.900 --> 01:37:13.920
Und der sagt so, also ich weiß

01:37:13.920 --> 01:37:15.160
nicht, dieses ganze Typing-Zeugs,

01:37:15.920 --> 01:37:17.800
ich finde, das sieht nicht gut aus,

01:37:17.860 --> 01:37:19.160
ich mag das nicht. Und was wir

01:37:19.160 --> 01:37:21.620
früher, als wir nix hatten, was wir gemacht haben,

01:37:21.900 --> 01:37:23.760
wir haben immer irgendwie Dicts genommen und

01:37:23.760 --> 01:37:25.640
ein paar List Comprehensions und damit haben wir

01:37:25.640 --> 01:37:27.640
alles gemacht. Alles haben wir damit gemacht. Und das war

01:37:27.640 --> 01:37:29.680
viel besser, als irgendwie, wenn einer sich mit Java

01:37:29.680 --> 01:37:31.760
hingesetzt hat und hat dann irgendwie so angefangen

01:37:31.760 --> 01:37:33.600
erst mal Interfaces zu definieren und dann

01:37:33.600 --> 01:37:35.480
irgendwie, keine Ahnung, sich da erst mal

01:37:35.480 --> 01:37:37.740
in, ja,

01:37:37.900 --> 01:37:40.240
weiß ich nicht, in so ein Spinnennetz

01:37:40.240 --> 01:37:41.900
aus komischen Dingen, die man alle so machen

01:37:41.900 --> 01:37:42.880
muss, weil man sie halt machen muss.

01:37:43.000 --> 01:37:45.160
Wenn man irgendwas hinschreibt, genau,

01:37:45.260 --> 01:37:47.860
diese ganze Zeugs, dann hat man sich in so einem Spinnennetz

01:37:47.860 --> 01:37:50.120
von Dingen verheddert,

01:37:50.260 --> 01:37:51.400
bevor man auch nur eine Zeile

01:37:51.400 --> 01:37:53.700
produktiven Code geschrieben hat und dann ist man mit den Dicts und

01:37:53.700 --> 01:37:55.600
den Miscomprehensions so lange fertig.

01:37:56.280 --> 01:37:57.780
Und damit hat er nicht so

01:37:57.780 --> 01:37:59.460
ganz Unrecht. Also tatsächlich ist es so,

01:37:59.680 --> 01:38:01.340
das dickst, wenn man das beherrscht und

01:38:01.340 --> 01:38:03.760
so wirklich verstanden hat, wie das funktioniert, mit eben

01:38:03.760 --> 01:38:05.720
vielleicht noch Dick-Comprehensions,

01:38:06.160 --> 01:38:07.780
vielleicht noch Generator-Expressions würde ich

01:38:07.780 --> 01:38:09.600
dazu nehmen und List-Comprehensions.

01:38:10.200 --> 01:38:10.920
Damit kann man

01:38:10.920 --> 01:38:13.580
einen Großteil von dem, was man so im Alltag an

01:38:13.580 --> 01:38:15.720
Programmierproblemen hat, tatsächlich lösen

01:38:15.720 --> 01:38:17.740
und es ist

01:38:17.740 --> 01:38:19.820
sehr, ja, man kommt da schnell

01:38:19.820 --> 01:38:21.320
hin. Sehr convenient und halt

01:38:21.320 --> 01:38:22.480
dem Python-Prinzip gar nicht.

01:38:23.060 --> 01:38:25.720
Das ist auch

01:38:25.720 --> 01:38:27.620
so ein bisschen die Stärke von Python.

01:38:28.620 --> 01:38:29.660
Ich muss auch

01:38:29.660 --> 01:38:31.600
gelegentlich andere Sprachen machen, jetzt so ein bisschen

01:38:31.600 --> 01:38:33.780
TypeScript kommt auf mich zu und

01:38:33.780 --> 01:38:34.980
C-Sharp

01:38:34.980 --> 01:38:37.880
und da sind solche Mapping-Typen

01:38:37.880 --> 01:38:39.720
einfach unhandlich, die sind einfach

01:38:39.720 --> 01:38:41.980
schwieriger zu benutzen.

01:38:42.560 --> 01:38:43.780
Du musst definieren,

01:38:43.860 --> 01:38:45.500
was da für Typen drin sind, nicht in TypeScript.

01:38:45.640 --> 01:38:46.440
In TypeScript kannst du einfach,

01:38:47.220 --> 01:38:49.440
der Trick an TypeScript, kannst du einfach immer Annie sagen.

01:38:51.040 --> 01:38:51.840
Jeder Typ ist Annie

01:38:51.840 --> 01:38:54.040
in TypeScript, aber in C-Sharp

01:38:54.040 --> 01:38:55.820
kannst du das auch machen, kannst du auch

01:38:55.820 --> 01:38:56.680
Annie sagen, aber

01:38:56.680 --> 01:38:58.560
wird nicht gerne gesehen.

01:38:58.900 --> 01:39:01.380
Mein Lieblingstalent wird Andy übrigens, der sagt, das reicht ihm nicht.

01:39:01.940 --> 01:39:02.660
Ja, okay, gut.

01:39:02.900 --> 01:39:05.120
Das ist eine Einstellungsache, das kannst du ja abschneiden.

01:39:05.120 --> 01:39:05.600
Ja, kann ich.

01:39:05.920 --> 01:39:06.760
Das geht trotzdem.

01:39:08.560 --> 01:39:09.920
Aber es ist einfach unhandlicher.

01:39:10.320 --> 01:39:14.440
Und das ist auch sowas, wenn man sich an diese Art zu denken gewöhnt hat,

01:39:15.140 --> 01:39:16.400
dann sieht man auch überall Dictionaries.

01:39:17.220 --> 01:39:18.600
Und dann will man sie auch überall verwenden.

01:39:18.760 --> 01:39:21.120
Deshalb mir fällt die Schauprogrammierung sehr, sehr schwer,

01:39:21.800 --> 01:39:24.340
weil ich mir ganz oft denke, ja, da könnte ich jetzt einen Dictionary verwenden,

01:39:24.520 --> 01:39:25.860
aber kann ich an der Stelle nicht.

01:39:26.720 --> 01:39:28.000
Ja, muss nicht so viele Spiele programmieren.

01:39:28.100 --> 01:39:30.260
und muss aber zwölf Umwege

01:39:30.260 --> 01:39:32.080
machen.

01:39:32.600 --> 01:39:33.900
Ich sehe aber auch, also

01:39:33.900 --> 01:39:36.020
ich sehe auch den Vorteil von diesem Typing an.

01:39:36.200 --> 01:39:38.340
Ich bin da ganz klar auf der

01:39:38.340 --> 01:39:39.920
Seite der jungen Hüpfer wie dir, Jochen.

01:39:42.720 --> 01:39:44.060
Und das ist für mich so ein bisschen

01:39:44.060 --> 01:39:45.880
diese, es gibt ja diesen klassischen

01:39:45.880 --> 01:39:48.380
Kampf zwischen Explore and Exploit,

01:39:49.740 --> 01:39:53.980
wo jeder entscheiden muss, was

01:39:53.980 --> 01:39:56.280
er machen muss, um ein Problem

01:39:56.280 --> 01:39:58.240
zu lösen. Also Explore ist unbekannte

01:39:58.240 --> 01:40:00.300
Dinge angucken und Exploit ist bekannte

01:40:00.300 --> 01:40:02.180
Dinge so lange gegenhauen, bis es irgendwie kaputt geht?

01:40:02.920 --> 01:40:04.080
Ja, genau. Also Explore heißt

01:40:04.080 --> 01:40:05.720
Lösungen ausprobieren, die

01:40:05.720 --> 01:40:07.780
dir selber noch nicht bekannt sind.

01:40:08.660 --> 01:40:10.380
Also suchen quasi. Und Exploit

01:40:10.380 --> 01:40:12.020
heißt Dinge anwenden, die du schon weißt.

01:40:13.620 --> 01:40:13.980
Und

01:40:13.980 --> 01:40:16.500
Menschen sind da halt sehr unterschiedlich

01:40:16.500 --> 01:40:18.400
und das ist tatsächlich wohl so, dass das mit dem Alter

01:40:18.400 --> 01:40:20.420
eher zu Exploit geht

01:40:20.420 --> 01:40:22.220
als zu Explore, was ja auch okay ist, weil

01:40:22.220 --> 01:40:23.800
du viel Explore schon gemacht hast

01:40:23.800 --> 01:40:25.720
und dann eben die Dinge

01:40:25.720 --> 01:40:27.620
anwendest, die du schon weißt. Wenn du mehr weißt, ist das

01:40:27.620 --> 01:40:29.720
natürlich effektiver, als wenn du weniger weißt. Kinder machen

01:40:29.720 --> 01:40:31.580
viel, viel mehr Explore. Wusstest du, dass einige

01:40:31.580 --> 01:40:33.620
Hacker schon von Anfang an Greise

01:40:33.620 --> 01:40:35.360
im Kopf gewesen sind? Ja, das

01:40:35.360 --> 01:40:39.700
Man muss sich das auch manchmal wieder zurück

01:40:39.700 --> 01:40:41.280
in den Kopf rufen, dass man vielleicht

01:40:41.280 --> 01:40:43.680
gelegentlich wieder Explore machen muss. Das ist auch der Grund, warum

01:40:43.680 --> 01:40:45.560
ich C-Sharp und TypeScript und so weiter mache, damit

01:40:45.560 --> 01:40:47.600
man mal ein bisschen wieder was anderes macht. Ich dachte, C-Sharp

01:40:47.600 --> 01:40:49.340
machst du, damit du endlich noch ein Spiel realisieren kannst.

01:40:50.220 --> 01:40:51.660
Ja, irgendwie muss man

01:40:51.660 --> 01:40:53.300
ja sein Schloss sicher arbeiten.

01:40:53.800 --> 01:40:56.960
wie erschlossen arbeiten

01:40:56.960 --> 01:40:58.660
das spricht sich doch schon von alleine

01:40:58.660 --> 01:41:00.900
ja Erben

01:41:00.900 --> 01:41:01.720
ich glaube

01:41:01.720 --> 01:41:04.660
oder erobern

01:41:04.660 --> 01:41:05.980
Schlösser müssen eigentlich geobert werden

01:41:05.980 --> 01:41:09.600
mit Verteidigungsanlagen oder Heirat

01:41:09.600 --> 01:41:11.120
ja das ist auch eine Art

01:41:11.120 --> 01:41:11.660
der Eroberung

01:41:11.660 --> 01:41:14.940
sieht bei mir

01:41:14.940 --> 01:41:16.180
jetzt nicht so gut aus

01:41:16.180 --> 01:41:18.100
ich bin schon verheiratet

01:41:18.100 --> 01:41:19.440
und mit Erben

01:41:19.440 --> 01:41:20.660
ich habe meinen Vater gefragt

01:41:20.660 --> 01:41:23.300
im Inventar.

01:41:23.980 --> 01:41:25.880
Hast halt die hübsche genommen, ist eine schlechte Entscheidung.

01:41:28.360 --> 01:41:28.760
Absolut.

01:41:29.400 --> 01:41:31.760
Und hübsch und schlau, das sind ja schon zwei Ereigenschaften,

01:41:32.040 --> 01:41:33.680
die man sonst nicht im Paket kriegt.

01:41:35.500 --> 01:41:36.700
Hat sich mein Vater gefragt,

01:41:36.820 --> 01:41:39.120
wann ich als Erbpatter direkt die Schlösser austauschen lasse.

01:41:42.820 --> 01:41:46.840
Ja, aber das ist eben,

01:41:47.120 --> 01:41:49.720
man muss sich auch immer wieder in den Kopf rufen,

01:41:49.800 --> 01:41:51.620
dass man ein bisschen Explore macht und nicht nur Exploit.

01:41:51.700 --> 01:41:53.000
Also nicht nur das anwenden, was man kann,

01:41:53.060 --> 01:41:54.800
sondern auch mal was ausprobieren, was man noch nicht kann.

01:41:56.080 --> 01:42:00.020
Und Dictionaries und Typing gehören halt dazu.

01:42:00.680 --> 01:42:03.060
Es gibt so eine witzige Liste von,

01:42:03.780 --> 01:42:05.720
wie man Programmiersprachen beschreiben kann.

01:42:05.720 --> 01:42:09.940
Und die fangen alle an mit, what if everything was?

01:42:10.720 --> 01:42:13.320
Und C zum Beispiel, bei C ist das Mandat,

01:42:13.400 --> 01:42:14.440
what if everything was a pointer?

01:42:15.040 --> 01:42:17.120
Und in Java ist, what if everything was an object?

01:42:17.520 --> 01:42:19.580
Und Python ist halt

01:42:19.580 --> 01:42:20.660
what if everything was a dictionary?

01:42:21.400 --> 01:42:23.540
Und das ist schon so. Dictionaries sind so ein bisschen

01:42:23.540 --> 01:42:24.880
der Kern von Python.

01:42:25.560 --> 01:42:27.620
Die sind leicht zu verwenden, die sind sehr mächtig,

01:42:27.680 --> 01:42:29.880
man kann so gut wie alles damit machen und

01:42:29.880 --> 01:42:31.120
die

01:42:31.120 --> 01:42:33.160
formen dann so ein bisschen das Denken.

01:42:33.620 --> 01:42:35.400
Jetzt haben wir es ein bisschen verherrlicht, weil wir jetzt noch gar nicht die Nachteile

01:42:35.400 --> 01:42:37.480
davon erklärt haben. Warum wollen wir das denn vielleicht

01:42:37.480 --> 01:42:38.920
nicht benutzen? Nachteile?

01:42:39.540 --> 01:42:41.500
Was könnte es jetzt noch für Nachteile geben?

01:42:41.620 --> 01:42:43.420
Es ist O von 1, es kann alles speichern,

01:42:43.480 --> 01:42:45.400
das ist großartig. Also vielleicht so wie

01:42:45.400 --> 01:42:47.240
Speicherverbrauch. Ja,

01:42:47.380 --> 01:42:48.600
Ja gut, das haben wir am Anfang schon gesagt.

01:42:48.600 --> 01:42:50.520
Also ein Dictionary verbraucht direkt

01:42:50.520 --> 01:42:51.380
ein Viertel Kilobyte.

01:42:51.840 --> 01:42:54.260
Das heißt, bei so Embedded Programming oder irgendwelche

01:42:54.260 --> 01:42:55.680
IoT-Sachen ist das dann

01:42:55.680 --> 01:42:57.800
vielleicht nicht die richtige Wahl.

01:42:59.020 --> 01:42:59.920
Es ist auf jeden Fall

01:42:59.920 --> 01:43:02.100
relativ wasteful.

01:43:02.560 --> 01:43:04.360
Also man hat immer einen großen

01:43:04.360 --> 01:43:06.020
Overhead. Immer mindestens

01:43:06.020 --> 01:43:08.240
50 Prozent Overhead. Wir laufen alle auf so Kisten, wo wir genug

01:43:08.240 --> 01:43:10.280
Speicher haben, da ist das wurscht. Ja, natürlich.

01:43:10.380 --> 01:43:12.440
Das ist die Ausrede, die man heutzutage macht. Aber es gibt

01:43:12.440 --> 01:43:14.480
natürlich auch Fälle, wo es eben nicht so der Fall ist.

01:43:14.680 --> 01:43:15.820
Oder wo man an die Grenzen kommt.

01:43:15.820 --> 01:43:20.960
Ja, so eine Waschmaschine hat halt 4 Kilobyte Hauptarbeitsspeicher.

01:43:21.660 --> 01:43:27.580
Wenn du 100.000 TPS machen kannst statt 1 Million und du brauchst dann 1 Million, dann wird das halt schon irgendwann relevant.

01:43:29.160 --> 01:43:31.840
Ja, Moore's Law wird alles gut machen langfristig.

01:43:32.620 --> 01:43:36.620
Auch eine Waschmaschine bekommt dann mehrere Gigabyte Speicher für einzelne Waschbocken.

01:43:36.920 --> 01:43:39.800
Ja, Waschmaschinen haben ja heutzutage schon mehr Hauptspeicher.

01:43:39.800 --> 01:43:44.940
Irgendwann musst du da einfach mal noch so Grundrohstoffe reinkippen wie, keine Ahnung, weiß jetzt nicht, Sand und Salz oder sowas.

01:43:45.300 --> 01:43:46.900
Und da baut es automatisch Waschmittel raus

01:43:46.900 --> 01:43:48.900
und das perfekt für die Wäsche

01:43:48.900 --> 01:43:49.400
geeignet ist.

01:43:51.280 --> 01:43:52.700
Du kannst doch schon so

01:43:52.700 --> 01:43:54.900
Waschmaschinen, Waschmittel, Cartridges kaufen

01:43:54.900 --> 01:43:57.080
und die werden dann auch so dosiert,

01:43:57.220 --> 01:43:59.200
dass es für den Waschmittelhersteller optimal ist.

01:43:59.360 --> 01:43:59.480
Okay.

01:44:01.620 --> 01:44:02.780
Für den Waschmittelhersteller,

01:44:02.880 --> 01:44:03.840
das ist natürlich, ja, egal.

01:44:04.540 --> 01:44:05.680
Ja, leider nicht.

01:44:06.240 --> 01:44:08.540
Ich hoffe, euch hat eure Folge, unsere Folge zu Dix

01:44:08.540 --> 01:44:10.560
heute gefallen. Falls dir noch irgendwas dazu einfällt,

01:44:10.700 --> 01:44:11.200
dann...

01:44:11.200 --> 01:44:14.220
Ich glaube, Pics und sowas machen wir irgendwann anders.

01:44:14.640 --> 01:44:16.520
wir sind auch schon. Ja, ich glaube, wir sind jetzt heute weit

01:44:16.520 --> 01:44:18.580
fortgeschritten. Also mein Lieblingsmodul

01:44:18.580 --> 01:44:20.420
in Python ist ja

01:44:20.420 --> 01:44:22.660
Buildings.dict. Das ist mein Pick der Woche.

01:44:23.000 --> 01:44:23.200
Okay.

01:44:26.560 --> 01:44:28.540
Ich mache dann einfach von einem Padentic.dict.

01:44:29.260 --> 01:44:30.160
Ja, okay, perfekt.

01:44:30.460 --> 01:44:31.740
Und Jochen macht Name-Tubel.

01:44:32.240 --> 01:44:33.080
Ja, Adress eher.

01:44:33.660 --> 01:44:34.820
From Jochen Imports.

01:44:36.700 --> 01:44:38.500
Die eigene Implantierung, ja. Aber genau, kann man sich

01:44:38.500 --> 01:44:40.400
auf jeden Fall auch mal angucken. Das lohnt sich.

01:44:40.880 --> 01:44:42.660
Da haben wir doch Picks gemacht.

01:44:42.800 --> 01:44:43.440
Ging schnell.

01:44:44.640 --> 01:44:46.440
Ja, dann bleibt uns gewogen,

01:44:46.520 --> 01:44:48.140
hört uns immer, wo ihr uns hören wollt und

01:44:48.140 --> 01:44:50.440
eine schöne Zeit und bis zum

01:44:50.440 --> 01:44:51.200
nächsten Mal. Bis zum nächsten Mal.

01:44:51.580 --> 01:44:53.000
Bis zum nächsten Mal. Tschüss.