Transcript: Fragen über Fragen

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der 15. Episode.

Hier ist der Dominik, bei mir ist der Jochen, wir sind wieder im Wintergarten.

Hallo, hallo.

Es ist sicher, diesmal scheint sogar noch die Sonne zu sein, der Wahnsinn.

Ja, es ist auch selten, dass wir aufnehmen, wenn es noch hell ist, aber heute...

Das ist mitten im Winter.

Ja, wir haben tatsächlich Dezember irgendwie...

Ja, der 12. Dezember, genau.

Vielleicht gar nicht so schlecht, wenn wir das mal dazusagen, wenn das ist.

Ja, wir haben uns ein bisschen Zeit gelassen in letzter Zeit, in den Folgen ist mal so viel zu tun,

aber wir versprechen, wir werden es nicht aufgeben und euch weiter damit bespaßen können.

Ich wollte ja nicht belästigen sagen.

Ja, genau.

Das ist immer die Frage, was man da empfindet, wenn man das hört.

Unsere Folge heute soll wirklich mal so eine Anfängerfolge sein.

Ja, wir werden mit euch heute reden über ein, zwei Fragen, die wir stellen möchten,

was für Anfänger für Fragen haben oder was mir eingefallen ist oder was einige Hörer uns geschrieben haben.

Worum es eigentlich bei Python geht, sind ein paar ganz grundlegende Sachen.

Vielleicht wird es ja spannend.

Also, ja.

Keine Leidenschaft.

Die Lava-Folge kennt ihr schon, wen ihr schon gehört habt.

Ja, genau.

Das mit den Themen können wir auch irgendwann mal klassen.

Wir machen einfach mal nur die nächste Lava-Folge.

Ja, ja.

Ja, was machen wir hier eigentlich heute Morgen und was ist so passiert in der Szene?

Und gibt es irgendwas Neues?

Nee, nicht, dass ich, ich glaube, seit dem letzten Mal hat sich da gar nicht so viel getan.

Django 3 ist raus.

Oh ja, doch.

Ja, richtig.

Du hast recht.

Ja, tatsächlich.

Django 3 ist raus und das war, das ist natürlich eine tolle Geschichte.

Ich habe das schon gesagt.

Ich habe direkt mal versucht zu installieren und da so ein paar Sachen irgendwie mitzumachen.

Aber habe dann feststellen müssen, dass ein Haufen der Abhängigkeiten, die man so defaultmäßig

irgendwie in Django-Projekten drin hat, dann nicht mehr so richtig funktioniert haben.

Beziehungsweise dazu führen, dass man dann halt ein Faceback kriegt, wenn man versucht,

den Entwicklungsserver zu starten.

Und ja, unter anderem sowas wie Django Model Utils, was irgendwie fast alle Leute verwenden.

Oder ich verwende das eigentlich immer.

Wahrscheinlich auch eine Menge andere Leute.

Wegen Timestamp Model oder sowas, was man ja oft verwendet.

Und ich weiß nicht mehr genau, was es noch alles war.

Es waren, ich habe dann für die Sachen, die nicht funktioniert haben, da habe ich dann

einfach die gefolgt auf GitHub und habe das dann versucht zu fixen und dann halt entsprechend

immer Pull Requests aufgemacht.

Also ihr könntet bei Jochen in den Repos die versuchen, die auch bei Django 3 funktionieren,

wenn das wollen.

Nein, das sollte man vielleicht nicht machen.

Also.

Darum muss ich das irgendwie kennen oder so.

Nee, nee, nee, nee.

Aber es hat mich gewundert, wie viel da noch nicht funktioniert hat.

Also es waren bei so einem normalen, ich weiß nicht, bei welchem ich das probiert habe,

entweder bei einer Webseite oder auch bei der Python Podcast Projektdings, habe ich

mal versucht, das auf Django 3 umzustellen.

Und das ist mit fünf Einhängigkeiten oder so sind kaputt gegangen.

Und da habe ich, ich glaube, ich habe auch so fünf Pull Requests irgendwie gemacht.

Aber danke, bis irgendwie immer drei.

Oder vier Versionen.

Oder nee, drei.

Also null, eins und zwei.

Und dann ist nämlich ein Major Release.

Was heißt nochmal was?

Ich glaube, null ist immer so die neue Feature Sachen.

Nee, ist immer gerade, ungerade.

Gerade sind immer die Long Term.

Ich glaube, zwei ist Long Term.

Punkt zwei.

Also 2.2, 1.2, 3.2 sind die Long Term.

Und eins.

Ja, kannst du mal nochmal angucken.

Ich bin mir sicher.

Okay, gut.

Sehr gut.

Und eins ist irgendwas anderes.

Das weiß ich nicht.

Aber ja, deswegen habe ich nur gefragt.

Also was man dann macht.

Also für Security Patches dann wahrscheinlich.

Man kann ja nicht mal die 2. Version nehmen,

dass man irgendwie stabil sein möchte irgendwie.

Nee, also das, was tatsächlich empfohlen wird eigentlich.

Also das ist auch so eine Legacy-Geschichte,

das mit den Long Term Support-Geschichten.

Und naja, jedenfalls sagt das derjenige,

der aktuell irgendwie da ja auch hauptruflich

für das Django-Projekt arbeitet,

Carlton Gibson,

dass er empfehlen würde.

Und das machen eigentlich alle Leute,

die da wirklich viel Ahnung von haben,

dass man halt heute, also früher war das wohl mal anders,

aber mittlerweile sind die neuen Versionen von Django so stabil

und so gut getestet,

dass man eigentlich immer möglichst nah dran

an der Entwicklung bleiben sollte.

Weil es auch gar nicht mehr so schlimm ist,

bis dahin abzudaten.

Es geht gar nicht mehr so viel kaputt.

Sollte eigentlich nicht.

Ja, wir haben gerade gesehen, genau.

Also eigentlich, weil das halt macht halt viele andere Sachen

deutlich einfacher, wenn man das so rum macht.

Und wenn man halt auf der Long Term Support-Version sitzt,

dann hat man halt irgendwann ein großes Problem,

und das will man vielleicht dann doch nicht.

Also die Art, wie man das heute macht,

aber auf der anderen Seite machen das viele Leute schon

seit langer Zeit so.

Insofern kann man auch nicht einfach alle so vor den Kopf stoßen.

Aber so wie man das heute eigentlich machen sollte,

ist eigentlich immer die aktuellste Django-Version verwenden.

Ja, okay.

Und ich versuche das auch immer.

Und normalerweise funktioniert das,

also bis jetzt auf die 2. Serie hat das eigentlich sehr gut funktioniert.

Bis jetzt, Umstieg auf 3, da hat es halt nicht mehr funktioniert.

Und das war auch in allen Fällen das gleiche Problem.

Und zwar,

sind halt so ein paar private APIs

für die Unterstützung von so alten

Python 2-Geschichten sind jetzt aus Django 3

rausgeflogen. Also eigentlich

gibt es ja keinen Python 2-Support mehr,

auch seit Django 2 schon nicht mehr.

Oh, das läuft ja aus. Wir können ja runterzählen.

Ja, nur noch Tage, bis es irgendwie vorbei ist.

18, 19.

Ja.

Und,

aber es waren noch so ein paar Geschichten

dabei. So zum Beispiel, man konnte

irgendwas, es gab so einen Dekorator

bei 2 Unicode-Stringen oder so.

So was, den man über Funktionen setzen konnte.

Und dann kam das halt mit

auch den alten Geschichten

klar. Und

Six gab es halt auch in Django

drin. Was auch immer Six ist.

Ja, auch so eine Geschichte, die einem helfen

soll, damit umzugehen,

wenn es halt

Python 2 und Python 3

Geschichten sind.

Wir haben eigentlich versprochen, dass es eine Anfängerfolge

sein sollte.

Und wir fangen schon mit der Ahnung ganz tief in die Materie reinzugehen.

Nee, das ist eigentlich auch nicht so.

Also es sind ein paar,

ein paar Hilfsfunktionen, die einem

dabei helfen, das für 2 und 3,

Python 2 und 3 gleichzeitig zu machen.

Die sind jetzt tatsächlich entfernt worden.

Die waren vorher bloß deprecated, aber jetzt sind

die halt wirklich weg.

Und das heißt, wenn jemand die noch verwendet,

ein Paket die noch verwendet, dann

gibt es halt ein Traceback an der Stelle.

Also alles, was jetzt in Python 3 deprecated angezeigt wird,

ist bei Python 4 dann weg. Bei Python sag ich schon.

Bei Django 3, 4.

Ja, also diese Geschichte,

diese Geschichten waren jetzt halt dann weg.

Ja, okay.

Und das hat dann auch,

ja, also diverse Pakete gebrochen.

Und insofern, ja, also Umstieg auf Django 3

nicht so super easy.

Wie lange ist jetzt Django 2 rausgekommen?

Wie lange das her ist?

Ich weiß es nicht mehr genau.

Ich würde mal so tippen.

Ages.

Ja, fast zwei Jahre oder so.

Irgendwas um die zwei Jahre ein bisschen.

Ja, also die Release-Zyklen

bei Django sind ja auch viel kürzer geworden.

Also das war

alles viel länger und ja,

Django 2 gab es jetzt gar nicht so lange.

Ja, wenn du noch welche News einst,

weil sonst machen wir tatsächlich weiter mit Content heute.

Ja, Content klingt gut.

Also ich stelle jetzt immer

ein paar blöde Fragen.

Ja.

Und ich versuche dich

dazu zu bringen, dass du die Fragen möglichst kurz beantwortest.

Also so

eine Minute pro Frage oder so.

Vielleicht schaffen wir das.

Wow, okay. Ja, alles klar.

Ich weiß, es wird nicht immer ganz einfach bei einigen Themen.

Es ist natürlich auch was anderes, aber mal gucken.

Ja, schauen wir einfach mal.

Also erste Frage.

Python, eine Schlange.

Ja, wo kommt der Name her?

Also, nee, tatsächlich ist das eine Referenz

auf Monty Python.

Spam, spam, spam, spam, spam, spam.

Genau, genau.

Und auch interessant,

der

Monty Pythons

Flying Circus, also

der Flying Circus ist wiederum

eine Anspielung auf, glaube ich,

Ersten Weltkrieg, Roter Baron

irgendwie, Geschichte.

Die nannte man halt,

das war halt so die

informelle Bezeichnung, weil die halt immer mit Zelten

auf irgendwelchen Äckern und Wiesen

unterwegs waren, weil es sowas wie

Flugflugplätze ja damals noch gar nicht gab,

wurden die dann halt auch mal der

Fliegende Circus genannt.

Ja,

aber wo Monty Python

eigentlich herkommt,

weiß ich jetzt auch nicht.

Genau, aber

die Referenz des Namens

der Programmiersprache bezieht sich schon auf,

äh, Monty Python.

Also ich finde aber eine Schlange eigentlich viel cooler.

Und ich würde einfach sagen, ich nehme auch immer so eine Schlange als Symbol.

Und es ist ja sogar im Logo mittlerweile drin.

Nee, klar.

Wenn ich mir ganz viele

Python-Muster auf meinen Körper tätowieren lasse,

dann ist das natürlich ein Teilchen von meiner Liebe zur

Sprache.

Tja, man kann sich ja schlecht nur irgendwelche Gags

auf den Körper tätowieren lassen, das geht natürlich nicht.

Ich habe übrigens noch keine Tattoos.

Leider, meine Frau sagt, ich darf nicht.

So.

So, so.

Tja, da musst du dich wohl entscheiden.

Ja.

Also, naja.

Ja, die nächste Frage wäre, welche

Einsatzzwecke von Python fallen dir ein?

Hm.

Na ja, schon eine ganze Menge, aber ich würde

sagen, die allerwichtigsten zur Zeit sind

ja, Data Science

ist jetzt, glaube ich, das am stärksten

gehypte Thema momentan.

Immer noch sogar. Ja, doch, ich denke schon.

Einfach deswegen, weil das halt irgendwie alle

machen wollen, weil da auch viele Fortschritte passieren

und Python ist halt die

Programmiersprache,

mit der man das vielleicht am besten machen kann, abgesehen

von R, aber R ist halt ein bisschen,

hat ein bisschen einen engeren Einsatzzweck und du kannst halt

nicht gut Webgeschichten zum Beispiel

nachschreiben oder so, oder ganze komplette

Systeme in A bauen, das geht eigentlich nicht gut.

Aber mit Python geht das, daher ist Python

irgendwie da schon so

gerade für produktive Geschichten das

Mittel der Wahl. Also, wenn man jetzt

nicht nur Sachen analysieren möchte oder

explorative Analyse von irgendwas machen möchte, sondern

man möchte es tatsächlich einsetzen, dann

kommt man eigentlich um Python nicht wirklich drum herum.

Es sind ja auch noch so ein paar Leute, die dann irgendwie

oder sagen wir so, das ist auch ein großer Bereich, aber die

dann Java oder so verwenden, es gibt ja auch

irgendwie mit Scala, also

nicht Java, sondern die Java4M und

meistens verwenden die Leute dann irgendwie Scala

obendrauf und Spark

und da gibt es auch so DataFrames,

aber

ich würde sagen, das ist ein

deutliches Stück kleiner als die Python,

als der PyDataStack.

Ja, also

das ist auf jeden Fall das

größte Thema, glaube ich, momentan,

aber Webentwicklung ist nach wie vor auch sehr groß.

Dann eine Geschichte,

die jetzt kommt irgendwie,

da wollen wir auch unbedingt noch mal was zu machen,

ist alles, was irgendwie so mit

Home-Automation-Zeugs zu tun hat.

Home-Assistant ist

ein großes Thema.

Ich habe da letztens, weil so um Weihnachten rum,

dann kann ja auch noch mal gucken, ob diese ganzen

Geschichten noch gehen oder

Geschenke in bestimmte Richtungen werfen, die irgendwas

in der Art tun, weil das ja doch eine ganz

angenehme Sache ist, wenn man halt

Lampen und sowas automatisch steuern kann.

Das ist natürlich ganz spannend, weil man hat halt irgendwie

ganz viel kleines Zubehör, das irgendwie, wenn ich das richtig

mal verstehe, meistens so in C am besten programmiert ist.

Man hat irgendwie so eine High-Level-API, so wie

MicroPython oder sowas, die man da drauf schmeißt und kann dann einfach

in Python auch die ganzen Module nehmen.

Ja, also die ganzen

Endgeräte,

das ist ja die Frage. Also man kann das, wenn es

so was Arduino-mäßig ist, dann ist das auf C,

was man da normalerweise schreibt, aber

es gibt halt auch mittlerweile Chips,

auf denen man MicroPython

installieren kann und dann kann man da einfach Python schreiben.

Die haben halt WLAN und ansonsten

hast du ein Problem, wie kommunizierst du eigentlich mit

Sensoren oder irgendwelchen Dingen, die dann was schalten oder so.

Wenn du da

irgendwie das über Funk, DVB-T

oder so machen, also ein bisschen ätzend

und WLAN ist natürlich schon nicht so schlecht und das geht

eigentlich mit alles mittlerweile, aber halt eben,

ich glaube, der größte Punkt ist, dass Home Assistant

ist halt in Python geschrieben und das ist halt

das Ding, was zum Verwalten von diesem ganzen Kram halt

üblicherweise so verwendet wird.

Wir haben ja jetzt nicht irgendeine fertige

Lösung wie jetzt,

na, wie heißt das denn,

von Apple?

Ja, hast du nicht gesehen.

Ja, oder Google

oder Amazon oder so, die haben

natürlich ihre eigenen Geschichten.

Und was ich da interessant, ich habe da

letztens nochmal, genau in dem Zusammenhang, mir

dieses State of the Union von Home Assistant

den Talk angeguckt und

das war mir gar nicht so

klar, dass die mittlerweile unter den

Top Ten der

Projekte bei GitHub sind, die am meisten

Contributions kriegen.

Aber die würden am meisten gerne daran basteln, ne?

Ja, ich war eigentlich,

überrascht, wie viel das ist, weil

das ist ja jetzt eben noch nicht so prominent.

Ich glaube, es waren sowieso sehr wenig

Open Source Projekte in den ersten zehn.

Also da waren eher solche, das fand ich

auch so ein bisschen erschreckend.

Wir haben doch keine Zeit.

Aber sowas wie Visual Studio zum Beispiel,

VS Code oder so ist in den

Top Ten, TensorFlow und so,

das sind ja alles nur so mehr oder weniger Open Source Projekte,

nicht so richtig eigentlich, aber Home Assistant schon.

Also, ja, da geht auf jeden Fall

auch noch was. Und

ansonsten, ja, alles, was

wir noch so an

Server-Infrastrukturen automatisch hochziehen,

Deployment,

da ist Python auch sehr stark

vertreten.

Das heißt, Web, hat man doch so ganz kurz gesagt,

ist gar nicht so klein, oder?

Nee, Web ist auch sehr groß, ja. Also

Django und Flask sind ungefähr beide gleich

groß, mehr oder weniger.

Und es sind beides große

Bereiche.

Viele der

Top-Seiten sind irgendwie eins von beiden.

Also, genau.

Also,

ziemliche Allround-Sprache eigentlich, kann man sagen.

Ja, okay.

Kann man fast alles mitmachen.

Was sollte man in Python können, um einen Job zu bekommen?

Hmm.

Das, äh,

äh,

hm.

Ich weiß nicht. Also, ich glaube, da kann man,

das ist immer ein bisschen schwer, ne?

Wenn man das dann sagt, was Leute da machen sollen,

und dann sagt irgendwie die Library

oder das, was besonders interessant zur Zeit,

dann braucht man irgendwie eine gewisse Zeit, um das zu lernen.

Wobei die meiste Zeit, die man braucht, um das zu lernen,

wahrscheinlich dabei drauf geht,

programmieren zu lernen. Das dauert halt einfach lange.

Und dann ist es halt in dem Moment, wo man es kann,

wieder veraltet. Also, insofern, das hilft alles nicht.

Aber ich würde sagen, tatsächlich,

die Geschichte, die am meisten bringt

und von der aus man dann alle anderen

Sachen, die man vielleicht lernen kann, ist halt

tatsächlich einfach richtig programmieren können.

Das ist schon so die

Fähigkeit, die man

haben sollte. Oder es ist halt auch etwas, was nicht so...

Es ist ja, äh, ja...

Richtig programmieren können, das hört sich jetzt

total einfach an. Das hört sich total einfach an, aber das ist

tatsächlich nicht so verbreitet, wie man

sich das wünschen würde.

Also, das kann man immer...

Man denkt immer so, ja, das macht man halt irgendwie.

Dann machen Leute irgendwie einen Kurs oder

kaufen sich irgendwie, ich weiß nicht, ob es sowas überhaupt gibt,

Python in 21 Tagen oder Java.

Das geht nicht in 21 Tagen.

Das geht auch nicht in einem halben Jahr. Das dauert alles

ein bisschen länger. Ja, manche Leute denken ja,

dass, wenn sie die Syntax mal einmal gesehen haben...

Genau, dass das das Gleiche wäre. Aber das stimmt halt nicht.

Es ist...

Die Syntax ist ja auch bei Programmiersprachen eigentlich

gar nicht so...

Also, für Anfänger schon. Die verstehen ja erst mal überhaupt nicht,

was da steht. Das ist der erste Schritt zum

Verstehen, was überhaupt, worum es überhaupt geht.

Ja, aber wenn man das eben mit einer natürlichen Sprache vergleicht,

es gibt halt viel weniger Worte. Es gibt halt ein paar,

äh, ja,

es gibt ein paar Verben

sozusagen für Worte. Hast du aber die ganze

Standard-Library mit bedacht?

Klar, also die Libraries sind ja nochmal ein anderes Thema,

aber das muss man ja auch alles gar nicht so unbedingt können.

Ähm, man muss halt,

wenn man die Syntax und halt die paar

Worte, die es tatsächlich gibt, kann,

dann kann man das ja zumindest mal alles lesen.

Und, ja, also, ähm,

ja, das ist halt, also programmieren

können ist aber so ein bisschen wie ein Musikinstrument

können oder halt auch Fremdsprache

lernen oder so. Und das ist halt so eine Geschichte, die dauert

einfach. Äh, da gibt's dann halt auch

Sachen, wie man das schneller hinkriegt und, äh, wie man das

effektiver üben kann und so. Und, ähm,

äh, aber

das, äh, aber wenn man das dann kann, dann

äh, kann man sich

eigentlich in jedes Thema relativ schnell

einarbeiten, würde ich jetzt mal so einfach sagen.

Ja. Und, äh, das ist halt

auch, denke ich, also die entscheidende,

äh, Geschichte, äh, die man, die man

können sollte, ähm.

Solche Themen schnell einarbeiten. Ja,

beziehungsweise halt diese... Die Prinzipien des Programmierens.

Diese, diese Geschichte, die halt lange dauert, halt schon

vorher erledigt haben, weil das, äh,

wird einem niemand gerne bezahlt,

weil, äh, das ist einfach das

lange Dauertum. Aber ich würde auch

sagen, da gibt's halt, äh, ein neues Potenzial.

Jetzt hört sich so ein bisschen an, das kann das ja jeder, aber das ist

nicht so. Also die allermeisten

haben damit Probleme und, und strugglen da

und das, äh, nur ein,

ein, ein, nicht, nicht die Mehrheit aller Programmierer,

äh, haben damit Probleme und, und strugglen da.

Man kann ordentlich programmieren, würde ich jetzt mal so sagen, ne?

Ja, das musst du eigentlich noch definieren, was denn

ordentlich programmieren muss. Und, und, das ist vielleicht auch, das ist auch vielleicht,

ja, das, das kann ich, ehrlich gesagt, gar nicht so genau.

Und, äh, ist auch die Frage, ob, eigentlich

ist es auch wieder so ein bisschen, ne, äh,

ich will eigentlich niemanden ausschließen,

äh, ich,

ich würde sagen, ja, selbst wenn man das nicht so total

hundertprozentig kann, wahrscheinlich haben die

meisten von uns auch schon irgendwie, äh,

Jobs gemacht, wo sie dachten, dass sie dafür, äh,

eigentlich gar nicht geeignet wären oder so und das haben dann halt

irgendwie gelernt, ja. Ich meine, so ist

das halt auch, äh, normal. Das ist wahrscheinlich

auch in anderen Bereichen so und, ähm,

vielleicht muss man sich einfach mal trauen,

irgendwas zu machen oder zu sagen, dass man irgendwas kann,

auch wenn man es halt vielleicht nur so ein bisschen kann und dann nicht so

perfekt, ne, dann, ja.

Ja, aber du musst

ja trotzdem dabei rausfinden, was denn jetzt, äh, richtiges

Programmieren dann überhaupt ist. Also, das ist jetzt zwar eigentlich jetzt nicht

auf meiner Liste, aber da musst du jetzt ein kleines

Kofotos teilen. Ich hab ja sogar zwei Minuten.

Naja,

äh, das wäre gar kein Problem, wenn das in zwei Minuten

zwei Minuten, sag ich mal. Äh, also ich,

ich würde sagen, also wenn man halt

keine, nichts total

äh,

also wenn man Dinge so macht, wie sie

gemacht werden sollten, nicht so

total schrecklich Dinge falsch macht, vielleicht.

Weil tatsächlich ist es das, was man

oft sieht, dass Sachen halt wirklich, also

nicht, nicht nur so ein bisschen

nicht ordentlich sind, sondern

so Kleinigkeiten, sondern dass so Dinge so gar nicht

richtig sind eigentlich. Was, was gehört denn dazu?

Also was würde denn da? Also ich würde, ich würde

sagen, eben das, äh, den, der Umgang mit den,

äh, mit den ganz einfachen

äh, Datenstrukturen,

ja, also irgendwie

Listen, Dicks,

äh, irgendwie

Skalare und damit halt ordentlich umgehen kann.

Also wenn man das schon kann, ist schon viel.

Hat man schon viel. Äh, weil das

schon viele Leute nicht so richtig hinkriegen.

Und, ähm, ja,

dann halt, äh,

dass man eben

Sachen halt ordentlich in Funktionen packt, nicht irgendwie

Spaghetti-Gut schreibt, dass das halt alles so halbwegs, äh,

sondern sich nicht dauernd wiederholt.

Dry, don't criticize yourself.

Ja, und, und

die ganzen, aber da gehen wir fast schon

in diese Detailgeschichten, oder dass man halt,

äh, Tests schreibt und diese ganzen Best Practices,

äh, verwendet und Versionskontrolle

verwendet und so.

Mit den Daten, das muss ich später nochmal sagen, da hab ich noch ein paar Fragen, da, ähm,

müssen wir nochmal ein bisschen drauf eingehen, was denn überhaupt jetzt, ähm,

Skalar, Datenschule, was alles ist, ja.

Ja. Okay, also du sagst halt

einfach, okay, man muss halt die Prinzipien, Best Practices

irgendwie kennen und anwenden und sich daran so ein bisschen

hochhangeln und irgendwie sich was besorgen, was

man da... Ja, und viel Code lesen, halt

viel sich mal angucken, was...

Das Problem ist natürlich, wenn man jetzt jemanden liest, wo du sagst,

dass die Mehrheit der Programmierer ist gar nicht so

hervorragend, und dann lese ich jetzt

von... Oder wie lese ich davon?

Ich würde sagen, da ist viel Verbesserungspotenzial.

Also wenn man sich anguckt, was, was,

wenn der Code, der geschrieben wird von Leuten

oder der so in Firmen, äh, äh, läuft

oder so, ist das dann so, wie es sein könnte, oder

kann da noch, geht da noch mehr?

Und da muss man sagen, da geht eigentlich fast immer

noch deutlich mehr. Ja gut, aber wenn man

sich jetzt einen eigenen Code anguckt, dann

ein halbes Jahr später, dann denkt man natürlich schon so, oh, oh, was ist das?

Ja, das ist auch so, ja.

Äh, genau. Aber, äh, ja.

Ja, was,

äh, erstmal, also ich habe noch eine Basisfrage

bekommen vom, vom Olli, der hatte noch geschrieben,

Tipps für eine gute Syntax, also dein Top 5

oder so. Äh, ich,

heute, heutzutage würde ich sagen, Black verwenden

und nicht mehr drüber nachdenken.

Also einfach Black, bumm. Ja.

Vielleicht, also Namen vielleicht auch, äh,

muss man vielleicht... Namen sind natürlich

das sind ganz, ganz, ganz, das ist eine ganz schwierige

Sache, also wie kommt man da auf gute Namen, da muss man

auch lange drüber nachdenken oft, äh,

also, äh, ja, das gibt, da gibt es ja auch

den bekannten Witz, ne, wie, was sind

die zwei schwierigen Sachen?

Äh, ähm, ja, äh,

in der Informatik, äh,

irgendwie Dinge benennen, äh,

Caching und, und oft bei One Error

erhors.

Ja, aber, äh, genau. Also, äh,

Dinge benennen ist, ist, ist schwierig,

ist eine Kunst und, ähm, ja, wo man

sich da auch dran orientieren kann, ist so ein bisschen

wie bei, bei guten Kommentaren.

So sollte eher darauf achten,

hinzuschreiben, warum man das macht oder

was das macht. Nicht so sehr,

wie da irgendwas passiert oder so.

Äh, äh,

ja, und halt dabei,

wenn man verschreibt, äh, äh,

dran denken, dass das, äh,

wenn das, äh, jemand liest,

dann halt verständlich sein sollte, weil Code

viel öfter gelesen wird als geschrieben.

Ja. Okay.

Ähm, was ist mit sowas wie List Comprehension?

Würdest du das bevorzugen gegenüber

klassischen Loops? Nö, kommt, kommt

drauf an. Also, äh, ich würde sogar eher

ein bisschen, die andere, ich würde

sagen, lieber eine, eine, eine

Vorschleife verwenden und List Comprehension

halt eher dann, wenn es halt,

irgendwas Einfaches ist, wo,

ja, wenn es halt offensichtlich und

einfach ist, dann kann man auch gerne

List Comprehension verwenden, aber wenn

man, also, ich meine, ähm,

auch da, auch da,

das ist halt, wenn man irgendwas entdeckt, wie es

funktioniert und das dann cool findet, dann fängt man an, das überall

zu benutzen und, äh, ich habe dann auch schon

nicht List Comprehensions gebaut, äh, irgendwie,

wo ich dann halt, äh, ähm,

mehrfach verschachtelt irgendwie

über Dinge iteriert habe und das wird bei

List Comprehension sehr, sehr schnell, sehr, sehr

unübersichtlich, ja, wo ich dann halt irgendwie,

äh, stolz darauf war, so ein Statement hingekriegt zu haben,

äh, also, äh, nicht in einer

Zeile, das geht dann halt nicht mehr in einer Zeile,

aber dann so drei Zeilen, List Comprehension

irgendwie, äh, mit Bedingungen

drin und verschachtelt und, äh,

so lange getüftelt, bis es irgendwie ordentlich funktioniert hat,

das macht ja dann auch irgendwie Spaß,

das ist halt so ein bisschen wie puzzeln, aber

ich fürchte, wenn da jemand dann draufguckt,

der das, äh,

der das verstehen muss und das unter dem

gewissen Zeitdruck tut, dann, äh,

würde der sich wahrscheinlich irgendwie, äh,

rot vor Hut,

Spaß zur Ärger, da würde sich das,

äh, da gibt's, äh, das Remote

Strangulation-Protokoll irgendwie

zu Hilfe wünschen. Das Remote?

Ja.

Ähm, ich weiß nicht, ähm,

äh, äh,

ja, das kennt wahrscheinlich auch keiner, äh, damals

gab's so ein Text, äh, auch schon lange

her, äh, Bastard Operator from Hell

und, äh,

da gibt's die SysAdmin, äh,

also es gibt die SysAdmin-Man-Pages oder die, äh,

äh, äh, Sys, äh,

äh, Admin Recovery gab's in den News,

äh, News Group

und dann, äh, ASR, ne?

Alt SysAdmin Recovery, das war

die News Group und dann gab's die ASR-Man-Pages

und Tools, äh, ich glaub, wenn man

Man-ASR sagt

oder Man-Knife oder Man-

Snip oder so, dann kriegt man das

auch noch, äh, irgendwie auf dem Linux,

äh, zu sehen, da gibt's dann Tools, mit

denen man, äh, irgendwie Usern,

äh, die, die

Attitüde, äh, Attitüde von, von Usern wieder,

äh, re, re, rejustieren kann

und diese Tools sind halt sowas wie, äh,

Snip

oder Knife ist da, ächs,

ja, so, mit der Axt

irgendwie mal dazwischen geht und, äh, Dinge

gerade richtet und, äh,

Regulieren, das hört sich toll an.

Ja, das klingt, äh, klingt nach Spaß an,

äh, wenn man auf der richtigen Seite steht.

Äh, ja, ist natürlich

so ein bisschen, ich mein, das Mindset dahinter ist

auch etwas fragwürdig, aber es ist damals

was irgendwie lustig und, äh, eines

der, da gab's auch Protokolle und eines der Protokolle

in dem Zusammenhang ist halt, dass, äh,

äh, es, äh, äh,

RSCP, RS, äh,

äh, eben, Remote Strangulation Protokoll

mit einer Software über

Fernverbindungen.

Sehr gut. Ja, also, ne,

das ist das, was man in Startorganisationen

gerne hätte oder wo man dran arbeitet, das auch

zu bekommen, ja. Also ihr braucht gute Admins

für den Start, damit das funktioniert. Ähm,

ja.

Ja, also, okay, ein bisschen Syntax haben wir gemacht, ja,

also die Frage wäre jetzt noch, was gehört als zu

Python Fullstack dann? Also wenn man jetzt schon

ganz viel kann und so, was würdest du sagen, wenn man richtig

Fullstack entwickelt? Ja, Fullstack, ja, das ist so

ein Ding, was heutzutage auch wieder, äh, in aller

Munde ist, wobei das auch selten tatsächlich

so ist.

Würde ich sogar sagen, auch, das ist auch das, ich mach das nicht,

eigentlich, ich bin deutlich eher auf der Backend-Seite

als auf der Frontend-Seite, aber

Fullstack hieße ja, dass du quasi alles

machen kannst, von unten bis, äh,

also Frontend. Also Fullstack in Python geht gar nicht, weil

das geht nicht richtig, genau, weil du mit Frontend

bist du halt nicht, äh, da brauchst du

halt dann schon JavaScript für

und, ähm, ja, oder

es ginge theoretisch auch, aber das ist halt ein

Bereich, der schön wäre, wenn das mit Python funktionieren

würde, aber momentan geht das nicht richtig, also

man konnte natürlich Python auch irgendwie Richtung

WebAssembly kompilieren und dann

halt im Frontend verwenden, aber es gibt keine,

es gibt, ähm, eben nicht

so viel wie für JavaScript, die ganzen

UI-Bibliotheken, die man da so braucht, um halt

Dinge irgendwie auszumachen, also

schwierig.

Ja, okay. Ja, das heißt,

JavaScript braucht ihr, wenn ihr Fullstack machen wollt, und wenn du

Python kriegst, dann kannst du hin. Aber ja, vielleicht

wollt ihr das ja auch gar nicht so machen, weil, warum sollte man

Fullstack machen, wenn man sich andere Sachen wie Data und

Backend so gut kennt? Naja, also, wenn du eine Webseite

machst, hast du halt sofort diesen ganzen

Kram, wobei du da möglicherweise eben auch ohne

JavaScript oder ohne viel JavaScript

auskommen kannst. So eine ganz

stinknormale Webseite

so. Hätte man ein bisschen

CSS-Forschung machen oder sowas, ja.

Ja, okay. Auch kein Python.

Auch wieder kein Python, genau. Aber das geht natürlich

auch immer noch und ist eigentlich auch für viele

Anwendungen irgendwie gar nicht so

schlecht. Aber, ja.

Ja, gibt ja so ein paar Framework, ne?

Grid, Materialize und so.

Naja, also ohne JavaScript.

Aber das ist ja was anderes. Ja,

Fullstack geht gar nicht ohne Python.

Ja, und das ist tatsächlich

auch einer der großen

Risiken irgendwie für die Zukunft von

Python, wenn das halt, wenn das

quasi so aus dem Wettding, weil die Frage

ist jetzt, kommt Python nochmal ins Frontend

oder geht JavaScript

ins Backend? Und wenn der Weg

in die Zukunft so aussieht, dass wir dann JavaScript,

weil das natürlich auch gewisse Vorteile bringt, du kannst

was halt, dann schreibst du einmal den Code, kannst den

im Backend und im Frontend verwenden.

Wenn wir jetzt auch

im Backend zunehmend JavaScript kriegen,

dann brauchst du halt eigentlich Python

in der Webentwicklung gar nicht mehr. Oder?

Es läuft umgekehrt. Und

wir kriegen auch irgendwann Python im Frontend.

Das wäre natürlich eigentlich die schönere Variante.

Ja, da müssen wir mal dran arbeiten, dass das passiert.

Ja.

Ich glaube, also die Chance ist gar nicht so schlecht. Also ich glaube,

Python ist noch bei Anfängern

gerade ein bisschen beliebter. Vielleicht bedeutet das, dass

das irgendwann dann auch in diese Richtung driftet.

Ja, mal schauen.

Wer weiß. Ja,

Import Sys?

Import Sys, Sun of Python.

Ja, ich glaube, das hatten wir letztes Jahr auch schon,

mal ziemlich genau um diese

Zeit. Hatten wir das nicht in der ersten Folge schon mal?

Am Schluss, glaube ich, ja.

Aber kann man sich auf jeden Fall immer

mal wieder angucken. Ja, also den Interpreter öffnen,

einfach Import Sys eingeben und

abschicken und dann seht ihr das. Sun of Python,

also die Prinzipien, die man

sich drauf geeinigt hat, die in Python gelten,

sollen auch sein.

Da ist auch immer so ein bisschen Humor mit dabei.

Aber ja,

ist auch was dran. Ja, also das ist direkt

verknüpft zu PEP 8. Ich glaube, das hatten wir dann auch schon mal kurz

erwähnt, aber an der Stelle vielleicht nochmal.

Einfach nur die Art, wie man

relativ minimalistischer

Konsens

darüber, wie man Python-Code

formatieren sollte, vielleicht.

Und wer macht das nicht, dann

kommt ihr in die Python-Höhe. Ja,

aber auch innerhalb von PEP 8 gibt es ja so

Dinge, die dann nicht geklärt sind dadurch.

Und

Black hat halt zum Beispiel eben eine Meinung

dazu, wie das sein soll.

Das ist bei einigen Sachen total furchtbar. Das sieht

scheußlich aus. Okay, was denn?

Ja, wenn ich zum Beispiel Argumente,

in Funktionen packe oder

längere Print-Statements schreibe,

wie er die dann umbricht,

dann macht er die Klammer auf

in eine Zeile, dann nächste Zeile den

String aus dem Print-Statement und dann da drunter

die Klammer wieder zu, wo ich

dann sagen würde, hey, für die fünf Zeilen,

wenn das Print-Statement eh länger als 89 Zeichen ist,

hättest du das auch einfach in eine Zeile schreiben können.

Oder halt, wenn Kommentare am Ende der

Zeile sind, dann bricht er dann trotzdem

die ganze Funktion auseinander, obwohl sie noch reinpassen würde.

Oder wenn

Black sagt,

ganz viele Argumente in einer Funktion,

bricht das dann aber um, weil es nicht genug Argumente sind,

um auf jeder Zeile ein Argument zu haben.

Das sieht auch ganz furchtbar aus.

Und dann ist dann die Klammer zu mit dem

Doppelpunkt dann am Anfang von einer

Zeile irgendwie drei Zeilen

Funktionsdefinition. Das finde ich

total furchtbar. Ich bin eh nicht

so ein Freund von diesen 89 Zeichen

Editor-Quatsch, weil ganz ehrlich,

so entziehen, dass wir

nur 89 Zeichen auf dem Bildschirm haben.

79. Ja, 79. Entschuldigung.

Ich entwickle nicht die ganze Zeit mit meinem Telefon.

Nee, das ist für Konsolen eigentlich.

Die haben halt bloß

80 Zeilen, also 24 Zeilen,

80

Spalten.

Und es gibt natürlich,

oder ich weiß nicht... Ja, die alten aber nur.

Also die neuen.

Weiß ich nicht, ob es dann... Nee, nee, der Standard ist immer noch so.

Es ist auch so, wenn du

jetzt auf dem Linux oder so bist, dann hast du ja nicht unbedingt immer

ein grafisches System und deine Konsole sieht halt so aus.

Da gibt es keinen...

Ja, aber auch bei VI hast du ja mehr.

Ja, zum Beispiel.

Auf einer Konsole?

Ja.

Also ohne grafische

Benutzeroberfläche, glaube ich, ist schwierig.

Aber auf der anderen Seite wahrscheinlich gibt es diesen Fall,

dass jemand an einem Rechner ohne grafische Benutzeroberfläche

sitzt, praktisch gar nicht mehr so.

Also wenn ich mich auf meinen Server einlogge, habe ich da mehr als

80 über die Konsole.

Hast du dich mal an eine Konsole

gestellt, an einem Rechner zu drum, an eine serielle

Konsole? Ich glaube, da hast du

genau die 80 Spalten

und 24...

Das ist ja uralt, DOS.

Ja, bei DOS war das auch so, genau.

Ja.

Ja.

Ich weiß gar nicht.

Also ich glaube auch nicht, das ist eigentlich nicht mehr relevant, aber

da kommt das halt her und...

Wenn, dann sieht man da halt, muss man kurz darauf aufpassen,

dass es dann umgebrochene Zeilen gibt.

Die automatisch vielleicht eingeguckt werden oder so.

Ich weiß gar nicht, auf was ich es gestellt habe

bei mir. Das ist ja auch ein Ding, das man bei Black

tatsächlich einstellen kann. Also da...

Das muss man nicht so

auf 79 zeichnen lassen.

Also 79 zeichnen deswegen, weil man halt noch eins braucht

von der Zeilung.

Ja. Aber...

Wenn...

Also ich glaube, ich habe es auch nur auf einer 10 stehen.

Ich weiß es nicht.

Jedenfalls, das kann man ja konfigurieren und dann ist es nicht mehr so schlimm.

Also ich finde auch, ein bisschen mehr als 80 geht schon.

Irgendwann ist es natürlich auch wieder doof, wenn das halt zu lang wird.

Ja, gut.

Also so, dass man es halt vernünftig auf einem normalen Arbeitsrechner

irgendwie von sich an lesen kann, dass es nicht immer halb so groß ist,

dass man viel zu viel Platz braucht. Das wäre ja völlig unheimlich

und hässlich, einige Sachen.

Also ich finde, Black ist dann so ein bisschen inkonsistent, wenn es halt dann...

Beispielsweise, du hast drei Debug-Statements

hintereinander. Das eine ist vier Zeichen zu lang,

dann bricht der jetzt ganz komisch rum, irgendwie

und die anderen darunter

sehen nicht so aus. Das ist irgendwie

komisch. Naja.

Also ich finde, mein ästhetisches

Empfinden wird da immer so ein bisschen angehört.

Naja, gut.

Wann ist man Amnesie-Syndrom erkrankt?

Ah.

Not invented hier, ja.

Das...

Ja, ja, ja.

Wenn man alles selber macht.

Sehr böse erwischt.

Ja, das ist halt das

Problem. Genau, das heißt einfach nur,

dass man halt versucht, alles selber zu machen

und wenn es halt nicht von hier kommt,

viele Firmen haben das auch, die ja alles

doof finden, was sie nicht selber gemacht haben und dann

halt viel zu viel selber machen. Das ist natürlich ein Problem.

Wir entfinden das Rad nochmal von vorn.

Genau.

Das ist halt immer nett, da kann man immer was damit lernen.

Also die Grundlagen zu verstehen, das kann ich so schlecht.

Und hat man irgendwann nicht, kein mehr, der versteht,

wie es irgendwann mal gebaut worden ist,

so nur noch Leute, die dann irgendwie auf dem Sand

und der Asche von alten versunkenen Städten

versuchen, neue Gebäude zu errichten.

Und dann immer so, oh, da war eine Grube.

Oder ein Schützerpalast zusammen.

Das ist natürlich dann das, was man vielleicht verhindern will.

Und deswegen ist das vielleicht auch gar nicht immer so schlecht.

Aber natürlich kann man ja viel Zeit damit verschwinden,

dass man einfach anfängt, komplett

das Rad nochmal neu zu erfinden,

obwohl man eigentlich schon irgendwie fliegen könnte.

Ja, es ist

immer schwierig. Man muss halt eine richtige

Balance finden. Es ist manchmal gut,

also ein Beispiel dafür wäre

auch dieses Timestamp-Modell

aus den Model-Utils. Deswegen haben alle als Abhängigkeit

Model-Utils drin.

Dabei, ja,

da hat es dann auch so,

wie meinte ich, Jango 3 kurz

auch gesprochen

und da hat er dann so,

naja, das sind halt eigentlich zwei Zeilen

irgendwie in einem Modell, wenn man das selber

macht.

Vielleicht wäre es besser gewesen, die beiden Zeilen dann selber

hinzuschreiben und dann diese Abhängigkeit

nicht zu haben, weil jetzt hat man halt das Problem,

dass wenn man, das ist ja auch wieder

blöd, wenn man nichts selber macht.

Ganz schlimm, NPM hat das ja auch so bei JavaScript-Geschichten.

Dann hast du halt,

musst du dich halt viel mit dieser

Maintenance von diesem Kram beschäftigen,

was ja auch blöd ist.

Ja, Paketversionierung muss immer stimmen und genau

dem Stufstand bleiben und wenn du dann irgendwelche

Bugs hast, musst du dann irgendwas updaten, weil irgendwas kritisch war

und das hat dann andere Abhängigkeiten

und dann fliegt dir irgendwas auseinander, weil das inkompatibel

ist mit irgendeiner neuen Implementierung.

Also es ist halt auch,

man kann nicht sagen, das eine ist super schlecht, das andere ist,

sondern es ist halt, man muss halt irgendwie

da einen,

ja,

irgendwie einen Weg,

finden, der für den Anwendungsfall,

den man hat, den besten Trade-Off bietet.

Aber tatsächlich

ist es so, dass die meisten Leute eher

zu viel Richtung Not-Invented

hier gehen.

Ja, manchmal ist das praktisch.

Ich glaube, manchmal ist es auch gar nicht so schlecht, wenn man einfach coole Sachen,

die cool funktionieren, einfach benutzen kann und die dann

cool weiter funktionieren und dann auch einem schnell

irgendwas ermöglichen zu entwickeln.

Ich glaube, gerade für Anfänger ist das gar nicht so schlecht, wenn man halt nicht

von ganz immer anfängt, obwohl es natürlich auch

nett ist, wenn man vielleicht erstmal Assembler lernt und dann

C und dann irgendwie guckt, wie es alles so funktioniert.

Aber es ist auch vielleicht ein bisschen aufwendig.

Man kann vielleicht auch ab und zu mal eine High-Level-Bibliothek

einfach benutzen, um zu gucken, wie man Dinge

damit anstellt, ohne direkt alles zu

verstehen oder selber zu implementieren.

Ja, über die Zeit ist es natürlich

so, dass auch der Level an

Abstraktion, auf dem man arbeitet, ist halt

immer höher eigentlich, weil halt immer mehr

wird Commodity, also die Sachen, die früher

der interessante Bereich waren, in dem man irgendwas

gemacht hat, die werden halt zunehmend

Community und wandern halt

sozusagen aus dem interessanten Feld raus.

Und das, wo man

die interessanten Sachen machen kann, das

geht über die Zeit immer in abstrakter

Geschichten. Das ist halt auch die Frage, inwiefern das

nicht unter Umständen...

Auf der einen Seite kann man sagen, man kann heute

mit viel weniger Zeilencode

viel kompliziertere Dinge und

tollere Sachen bauen. Auf der anderen Seite ist es halt, wenn man

sich das manchmal genauer anguckt, ist halt

steht das alles so ein bisschen auf

tönernen Füßen. Das ist halt so Kartenhaus über

Kartenhaus-Geschichte.

Auf den unteren Ebenen stimmen schon viele Sachen

nicht mehr so richtig, aber dann baut man halt so lange

Abstraktionen drüber, bis es wieder...

Aber in Wirklichkeit

hat man diese Probleme nicht wirklich gelöst.

Wenn man halt das Gebäude und den Palast auf der Samtgrube baut,

man kann tatsächlich noch ein paar Stahlträger einziehen, das dann zu tun

könnte, der Palast zu gehalten.

Das ist halt dann...

Ja.

Aha. Ja, aber jetzt gehen wir, glaube ich,

jetzt haben wir so ein bisschen generell darüber gesprochen, was

so Python generell

ausmacht. Jetzt gehen wir so ein bisschen tiefer

in die Probleme der...

Oder was heißt die Probleme? Die Ideen, die Konzepte

der eigentlichen Sprache, was man auch vielleicht

achten muss. Also, falls ihr noch Fragen habt, die ich nicht beantwortet hatte,

schreibt uns wieder, wie immer.

Hallo, AppPython Podcast.

Wofür ist die InetPy?

Das ist eine gute Frage. Ja, man braucht das

irgendwie,

damit es ein Paket ist.

Ein Modul?

Wo ist der Unterschied zwischen Modul und Paket? Oh mein Gott.

Ich glaube, das muss ich ja selber nochmal nachlesen.

Damit der Namespace irgendwie

vernünftig zugegriffen werden kann. Also alles, was man da irgendwie

reinpackt, das sitzt dann im Namespace dieses Moduls,

wenn man es importiert, direkt drin.

Mhm. Irgendwie so. Und dann kann man da direkt

aktiv drauf zugreifen. Aber die Frage ist halt,

warum man das dann nicht mit den Submodulen macht.

Nee, du kannst das ja auch

reinschreiben,

was du exportieren willst, welche Symbole.

Interessant ist, kann man da auch Sachen ausschließen?

Also, dass ich zum Beispiel sage, ja, aber diesen Modul

bitte nicht in den Namespace packen oder sowas?

Also, es kommt noch eine andere Frage von einem Hörer von uns,

der wissen wollte, wie das dann überhaupt so funktioniert,

dass man Module selber bauen kann. Ich glaube, das Einzige,

was man machen muss, ist halt ein Folder,

importieren. Also, indem man halt

relativ einen Zugriff drauf hat.

Und dann einfach sagen, import

Foldername oder sowas. Und wenn da eine

InitPy drin ist, dann kann man die Module,

die da drin sind, einfach aufrufen.

Mit einem Import-Teil. Und dann kann man

from Modul Verzeichnisname

import Python-Datei oder

from Modulname Punkt Python-Datei

import Funktionsname.

Und dann kann man die

einsetzen auf dieser lokalen Ebene.

Und die Frage wäre halt jetzt, warum man diese

InitPy an der Stelle braucht und was die halt

vielleicht macht. Und dass sie vielleicht

halt dieses Namespacing, was in Python auch

irgendwie so ein Ding ist. Also, zum Beispiel zu sagen,

welcher Name jetzt zu welcher Funktion,

zu welcher Sublibrary gehört,

dass das da ein bisschen

definiert wird. Ja, man kann auf jeden Fall

an der Stelle kontrollieren, was

halt eben,

was mit welchem Namen exportiert werden

soll, sozusagen. Und

dafür ist es ganz

nützlich. Warum man sie unbedingt braucht, weiß ich nicht so genau.

Und das ist auch etwas, was

mir schon öfter mal auf den Fuß gefallen ist und wahrscheinlich

vielen Leuten, die jetzt, dass man

halt, kriegt manchmal so wenig hilfreiche

Fehlermeldungen, wenn man die InitPy

vergisst, sozusagen.

Oder wenn die aus irgendwelchen Gründen abhanden gekommen ist, was ja

auch manchmal vorkommen kann. Und dann

kriegt man Facebacks, die sehen irgendwie komisch

aus. Und man sieht denen nicht sofort an,

dass da eine InitPy fehlt.

Irgendwann weiß man halt einfach so, ah, das sieht jetzt danach aus.

Okay, das könnte sein, dass da einfach eine InitPy fehlt.

Aber ich habe zehn Minuten da vor meinem

Bildschirm gestanden und überlegt, warum macht der jetzt nicht

die Migration von meinem Dankmodell, den ich da geschrieben

habe? Das verstehe ich nicht. Und dann fehlte

einfach die InitPy Migration-Spoiler und dann, also

ach so, ja klar, kennt der ja nicht, kann der ja gar nicht sehen.

Ja. Aber da muss man auch drauf kommen

tatsächlich, sonst. Ja, das ist ein bisschen

genau. Und

eben, ja, also gute

Idee mit, was

sind eigentlich Paketemodule, wie

funktioniert eigentlich Importsystem und so, müssen wir uns auch noch mal

beschäftigen. Aber da müsste ich mich auch erstmal anlesen.

Weiß ich jetzt alles gar nicht so genau.

Ja, kriegen wir bestimmt noch jeden Tag. Aber wir haben

ja schon die Minute schon wieder überschritten. Ah ja, gut.

Ja, aber InitPy ist halt, wenn man

mit dann, dann, also Doppel-Underscore am

Anfang und am Ende, also wofür brauchen wir überhaupt ein Underscore

und wofür zwei?

Ja, also ich glaube, das ist,

also die

Konvention ist,

ich glaube, früher war es mal nicht nur eine Konvention,

aber mittlerweile ist es tatsächlich nur Konvention,

dass man Sachen, die halt

innerhalb einer

Klasse oder innerhalb,

also Dinge, die halt sozusagen

private API sind oder privat

benutzt werden, aber nicht nach außen,

eigentlich nicht von außen

benutzt, also angefasst

werden sollten, die werden

halt mit Doppel-Underscore

halt irgendwie gepräfixt

und Sachen, die halt sozusagen

dann gibt es

einfach ein Underscore, das ist halt so

markiert für

ja,

also

kann, ist auch, sollte man

nicht, sollte man nicht, ist auch eher so

interner Gebrauch, ja, aber ist jetzt nicht so total

privat.

Ja,

also ist es eine Konvention,

im Grunde braucht man das auch, also

außer jetzt manchmal bei

bei Doppel-Underscore

eigentlich auch nicht

wirklich, also jedenfalls.

Also ich habe zum Beispiel diese internen Variablen, habe ich noch

nicht verstanden, wofür das gut ist, ich habe es auch noch nie

benutzt, außer jetzt im, sag mal,

im Magic-Method-Kontext von

Klassen, wo man halt dann irgendwelche magischen Methoden,

die es im Identitätsüberschreiben will, um andere Effekte

zu erzeugen, aber...

Ja, es ist halt so ein Hinweis

darauf, dass man da

nicht wirklich

mit interagieren sollte.

Nicht umfummeln, ich fasse meine Klasse nicht an.

Alles, was man selber schreibt, machen immer

anders vor, damit niemand anderes es macht.

Nee, nee, ich versuche mal

ein Beispiel zu geben, also wenn du

eine Klasse hast, die irgendwas cached, dann

packst du halt,

wenn, also du rechnest es

halt aus, du überprüfst in der Methode, ja, also

ein bestimmtes Attribut ist

eine Property von dieser Klasse,

also hat ein Property-Dekorator drüber, irgendwas wird

ausgerechnet und du schreibst

das Ergebnis dieser Berechnung, also prüfst,

also,

wenn du die Methode aufrufst, zuerst habe ich das schon

ausgerechnet, wenn ja, gibst du

einfach das

gecachete, den gecacheten Wert zurück

und ansonsten rechnest du es halt neu aus, unter

bestimmten Bedingungen.

Und

den Cache selber, den legt man oft

dann in so einem Underscore-Attribut

ab. Underscore-Cache. Ja.

Oder Underscore

dieser Name dieses Attributes

oder so, weil,

und das heißt halt ja, bitte nicht anfassen, weil das Problem

ist jetzt, wenn ich von außen da rangehe, dann kriege ich vielleicht

den gecacheten Wert, aber ich kenne ja jetzt gar nicht

die Bedingungen, unter denen das vielleicht

den Cache invalidieren müsste oder so.

Und wenn ich da jetzt einfach so drauf zugreife,

dann kann

sein, dass Dinge schief gehen.

Und das heißt,

ja, das ist halt so eine Markierung für

das Ding hier bitte nicht direkt verwenden,

sondern, ne, dann gibt es ja meistens ein öffentliches

Attribut,

was man benutzen kann und dann

kann die Klasse das intern handeln.

Was ist denn überhaupt eine API?

Ja, im Grunde

eine Schnittstelle, die Schnittstelle

zu irgendwas. Es gibt es jetzt

auch in unterschiedlichen

Kontexten kann man das verwenden,

aber ich würde jetzt mal sagen, also üblicherweise,

wenn man jetzt irgendein Paket

verwendet,

weiß ich nicht, Party-Django-Paket

oder eine Python-Bibliothek oder so,

dann ist die API das, was man

sozusagen von außen benutzt.

Die besteht ja aus ganz vielen Funktionen.

Die man für seine Bibliothek benutzen kann,

um die Anwendung,

um damit irgendwas zu machen. Also wenn ich jetzt

zum Beispiel jetzt Requests nehme oder so,

dann macht request.get

macht halt ein get-Request. Das ist halt der öffentliche.

Intern macht das dann unter Umständen

noch eine ganze Menge anderer Funktionsaufrufe

und Dinge und weißer Teufel.

Und die sind aber intern gar nicht alle mit

einem Underscore. Nö, also manche von denen kann ich

auch einfach so verwenden, das ist ja auch gar kein Problem, aber

andere wahrscheinlich auch eher nicht.

Und die, die ich nicht unbedingt verwenden sollte

von außen, die sind halt dann so markiert

als, ja, für internen Brauch.

Ja.

Was ist eine private und eine globale Variable

und was ist der Unterschied und wofür braucht man das?

Global, privat. Also privat,

öffentlich, das ist halt so ein bisschen,

aber das hat man in Python eigentlich auch gar nicht so

wahnsinnig viel. Also es gibt in anderen Programmiersprachen

gibt es da eine stärkere

Unterscheidung, aber also im Grunde

ist es einfach so. Also ich hatte es gerade so in den

Anfängertagen ganz oft so, dass ich irgendwie mir

dachte, so ja, private Variable,

das ist alles irgendwie ein bisschen blöd. Ich muss ja irgendwie von einer Funktion

immer irgendwie so einen Wert returnen und damit das dann,

also ich glaube im Kontext einer Funktion sind ja die

eigentlich die Variablen immer privat.

Nein, nee, das ist nur eine Verwechslung. Also du meinst

lokal, lokal und global.

Privat und öffentlich,

das ist halt genau diese Geschichte mit dem Double-Andersquad.

Ja, okay. Dann meinte ich lokal

und global, ja.

Also lokal heißt, Variablen sind

halt quasi in dem

Block

gültig.

Und global.

Und ich habe immer gehört, man braucht keine globale,

man darf die nicht nehmen und das ist total nicht so

backrested. Kann man schon.

An einigen Stellen habe ich halt gemerkt, also gerade ich habe manchmal so Spiele

rein,

gemacht, Spiele gebaut oder sowas, da haben das

total super geholfen, weil das nicht die

Lebensenergie des kleinen Männchens

global zu definieren, anstatt in einer Funktion

oder so. Ja, ja, nee, kann

man durchaus machen. Es gibt auch Fälle, wo man das

durchaus

praktische Anwendungsfälle

hat.

Ist jetzt nicht unbedingt immer so guter, also es kommt

halt drauf an, was man damit machen möchte.

Also man

muss das halt explizit halt dann

als global markieren, wenn man das tun möchte.

Und dann gibt es auch noch, glaube ich, nochmal einen Unterschied zwischen

nur global oder global für

ein Modul oder

aber

ja, also für manche Sachen

ist das durchaus, also gerade irgendwelche Konstanten

oder so, die definiert werden, die sind oft global.

Also wenn man das nicht

ändert, ist das ja auch nicht schlimm. Wenn man

jetzt globale Variablen hat, die man ändert,

dann ist so ein bisschen

das riecht dann schon so ein bisschen

danach, als ob da irgendwas nicht so richtig ordentlich

funktioniert, weil

was

möchte man damit eigentlich machen? Also man

hat da irgendwie State, auf den man

zugreift von unterschiedlichen Stellen, also es wird dann halt sehr schwer

zu debuggen und sehr schwer vorauszusagen,

was da eigentlich passiert, wenn man das einfach so verwendet

und in unterschiedlichen Stellen des Codes

das dann ändert, einfach so.

Da muss man sich halt sehr, sehr genau überlegen

oder man muss halt, also

vielleicht fange ich so rum an.

Das Problem beim Programmieren ist dann halt irgendwie,

dass ich an der Stelle, wo ich das ändere,

muss mir ja immer klar sein,

was an allen anderen

Stellen im Code, an dem

an diesem Ding irgendwie rumgeschraubt wird, auch passiert.

Warum?

Also ich nehme jetzt mal so ein Beispiel, wo ich jetzt intuitiv

sagen würde, das wäre jetzt für mich das, was ich

jetzt als globale Variable nennen würde.

Ich habe jetzt ein Spiel, mein Barbar hat

Lebensenergie von 100 und es gibt

bestimmte Funktionen, die aufgerufen werden, wenn

der Barbar irgendwas macht, falsch macht, richtig macht,

runterfällt, gegen einen anderen, gegen einen Monster kämpft,

dann würde ich von dieser

globalen Lebensenergie irgendwas abziehen.

Ja.

Wofür muss ich denn dann an der einen Stelle,

wenn er jetzt, weiß ich nicht, auf ein Skelett trifft,

dem 10 Lebensenergie abzieht, wissen,

was an der anderen Stelle die Falle mit ihm gemacht hat?

Naja, also,

weil du, weil ja, naja,

lass mal überlegen, kann ich irgendwas konstruieren,

was dann problematisch

wird? Ich meine, es kann ja auch Dinge geben, die

Lebensenergie wieder erhöhen.

Ein Trank. Ja, und du musst halt zum Beispiel,

du musst halt wissen, dass das jetzt schon

nicht unter Null gefallen ist, wenn du jetzt,

sonst könntest du dich ja auch wieder

lebendig machen,

sozusagen, wenn du tot bist,

eigentlich. Ein Lifehack, ja.

Du musst irgendwie den,

ja, irgendwas musst du diesen State verwalten.

Irgendwas musst du halt sagen, okay, jetzt bist du aber tot.

So, und dann darfst du nicht durch,

darf nicht irgendein anderer Teil des Codes,

der jetzt nicht weiß, ob du tot bist oder nicht,

einfach deine Lebensenergie

oder deine Lebenspunkte erhöhen, weil

das macht dich ja eventuell wieder lebendig in einer Situation,

wo das gar nicht gehen darf.

Also, sozusagen, es ist...

Also, das würde nicht so gut funktionieren.

Das heißt, da würde man auch auch klassenbasiert

einen Ansatz nehmen, wo man irgendwie sowas machen

wie erhöhe Lebenspunkte und reduziere Lebenspunkte

und der macht das halt dann nur dann, wenn man nicht tot ist.

Oder so. Genau, und das erhöhe Lebenspunkte

geht halt nur, solange man nicht tot ist, zum Beispiel.

Aber diese Logik, wie das funktioniert,

wäre dann halt an einem Ort

gebündelt. Das wäre so ein bisschen die Idee auch hinter Klassen.

Haupt hinter

Objekt oder Theaterprogrammierung, dass du halt

die ganze Komplexität irgendwie

verbirgst.

Hinter, ja,

hinter dieser...

In diesem Objekt, hinter einer API.

Genau, und dann das halt alles nicht mehr wissen musst.

Während, wenn du jetzt einfach nur eine Variable hast, die da irgendwie

verändern kann, dann

ist die Komplexität verteilt

über den gesamten Code irgendwie,

der mit dieser Variable interagiert.

Was wäre denn jetzt aber ein cleveres Beispiel für eine globale Variable,

wo man sagen würde, hey, da macht das um jetzt dann doch Sinn?

Ich würde ich...

Mir fällt da fast keins ein, wo das irgendwie sinnvoll ist.

Also, was man manchmal hat,

ist, dass man sicher sein möchte,

dass man etwas

nur einmal hat oder so.

Aber da würde man auch

eher einen Singleton nehmen, beziehungsweise

in Python eher Borg-Personen.

Oh, Singleton, das steht hier ein bisschen weiter unten.

Nein, Singleton.

Ja, okay.

Was ist ein Singleton?

Was ist ein Borg-Personen?

Also, sozusagen,

Singleton ist,

wenn garantiert sein soll,

dass es von einer bestimmten Geschichte nur eine Instanz gibt.

Also, wenn ich zum Beispiel

eben in einem Spiel

die Spielfigur

oder so, die dann bestimmte Eigenschaften hat,

wie eben sowas wie Lebensenergie oder so,

wenn ich garantieren möchte,

dass alle, die damit interagieren,

immer die gleiche Instanz haben,

dass ich halt den nicht, weil es gibt nur einen,

es ist ja jetzt blöd, wenn ich zwei davon erzeuge

und dann in dem einen Objekt

verjähre ich die Lebensenergie und beim anderen nicht oder so.

Wie macht man das denn? Überschreibt man dann die New-Methode

und sagt dann so, nee, wenn es schon eins gibt, dann mach keinen neuen?

Ja, das ist, nee,

eigentlich, also,

dann kommt es in Borg-Python, so wird das üblicherweise

dann in Python implementiert,

man macht es einfach so, dass

wie ging das?

Also, ich glaube, der Trick ist,

aber das muss man mal nachgucken,

also mit Vorsicht genießen,

ist das sozusagen

den State innerhalb

von der,

eines Objekts sozusagen

in der Klassenvariable zu halten, die halt

bei allen Instanzen gleich ist. Und das, dann können

die Instanzen zwar unterschiedlich sein, aber der State ist immer gleich.

Und

dann ist es zwar kein Singleton in dem

Sinne, wie man das vielleicht ursprünglich

mal so definiert hat, in Gänger-Vorbuch

gibt es halt das Pattern Singleton,

weil man eben nicht

immer tatsächlich, also ich glaube,

bei der ursprünglichen Singleton-Beschreibung,

das wird einfach immer die

gleiche Instanz returnt, wenn man halt die...

Also, das heißt, wenn du überschreiben, das würde halt bedeuten,

wenn es dann ein anderes gibt, returnt es halt das.

Returnt es das alte halt.

Sowas kann man auch in Python machen, das wäre kein Problem,

aber praktischer ist es halt, weil es einfach weniger Code

und macht sozusagen,

verhält sich ähnlich und hat noch ein paar andere nette Vorteile,

dass du halt sozusagen

sagst, der State ist

über alle Instanzen verteilt,

bleibt über alle Instanzen von diesem Objekt gleich

und ich muss da nicht kompliziert irgendwie

dafür sorgen, dass ich immer die gleiche Instanz

zurückgebe.

Weil, wen interessiert es?

Ja, aber genau,

das sind alles, es geht immer so um State Handling

im Grunde, das ist immer so,

und wer manipuliert den und wie kann man

dafür sorgen, dass man

den Code,

der den State manipuliert, an einer Stelle

behält und so.

Weil das ist immer so, das ist was, was man am Anfang

das ist ein bisschen unintuitiv,

das denkt man sich so, naja,

das ist ja kein Problem, State kann irgendwo sein,

egal, ist in einer Variable,

in einer globalen Variable oder so,

oder halt auch oft verteilt,

oder man hat die Klassen,

sich mal irgendwie überlegt, wie so eine

Klassenhierarchie aussehen soll oder so,

und zieht das dann durch, unabhängig

davon, wie das Problem eigentlich ist.

Und das fiese, was

manchmal dann, oder fast immer passiert,

ist, dass man dann halt den State verteilt

über viel Code und

das ist dann halt

das, was du

speichern musst,

was sich irgendwie ändert.

Also,

der Status.

Ja,

also, sagen wir mal so, bei einer Web-Applikation

würde man sagen, dass der State

einer Web-Applikation liegt üblicherweise dann eben

in einer Datenbank.

Also, das ist in der klassischen...

Was bedeutet das? Also, was ist denn

überhaupt dann der State? Sagt der,

wie der Nutzer

gerade aussehen soll, wie der heißt und

was er für Daten gespeichert hat

für sein Profil, was er sehen soll

und dass das halt nicht dynamisch generiert,

sondern es liegt dann irgendwo rum.

Ja.

Das heißt, wenn man das ändern möchte,

dann muss man erst die Datenbank fragen oder sowas.

Das macht man dann gar nicht woanders.

Ja, genau.

Also,

das, was halt sozusagen

beschreibt, in welchem Zustand

deine Applikation ist.

Gehen wir jetzt nochmal aufs Spiel kurz.

Was mit der Figur ist. Was hat die gerade für eine Waffe in der Hand?

Was für eine Energie hat die? Wie viel Rüstung hat die noch an?

Das wäre der State.

Es geht so irgendwo in einen virtuellen Laden

und kaufst dir irgendwie das magische

sonst was Schwert, Feuerschwert.

Mit dem du irgendwie alle platt machen kannst.

Dann muss ja irgendwo gespeichert werden,

dass du das jetzt hast.

Dass das eine Adventure ist.

Und ich darf aber auch keine zwei gleichzeitigen Sachen

dann irgendwie haben.

Damit das sich jetzt nicht widerspricht,

darf es immer nur ein State geben.

Die interessante Frage ist,

wie verwaltet man diesen State?

Und naiv wäre halt,

man hat halt zum Beispiel

Held heißt halt in irgendwelchen globalen Variablen.

Man hat halt eine Liste.

Linke Hand, rechte Hand.

Die ist halt global.

Genau, da steht halt drin,

hier ist halt das Flammenschwert

und das ist da jetzt in dieser Liste der Items drin.

Und alle manipulieren diese Liste von Items irgendwie.

Aber das macht dann halt Probleme,

weil dann ist Logik jetzt irgendwie

solche Sachen abbildet,

wie das Flammenschwert macht jetzt plus 10 Angriff,

aber auf der anderen Seite wird dir heiß.

Das heißt, wird dir die Hand heiß

und du verlierst irgendwie alle halbe Stunde

ein paar Lebenspunkte oder sowas.

Keine Ahnung.

Das ist ja Code,

der irgendwie diese,

Business-Logik,

wenn man das so sagen kann,

in dem Spiel halt implementiert.

Und das kann ja sein,

dass da unterschiedlicher Code

an unterschiedlichen Stellen steht.

Und wenn du jetzt überall das gleiche globale,

die gleiche globale Variable hast,

auf die du zugreifst,

dann musst du dafür sorgen,

dass dieser gesamte Code,

der halt über dein Projekt verteilt sein kann,

dass der immer weiß,

was alle anderen Sachen machen.

Und das geht ab einer gewissen Größe nicht mehr.

Das geht am Anfang,

geht das,

solange es alles sehr klein ist,

kriegt man das auch noch hin,

dass man das alles im Kopf behält.

Ja, du musst halt jedes Mal zumindest

diese Überprüfung machen.

Du musst halt jedes Mal gucken,

hat denn jemand irgendwas geändert an der Stelle,

das nicht sein darf.

Das heißt,

jede dieser Logiken müsstest du

bei jeder Stelle,

wo diese globale Variable geändert wird,

erneut machen,

was halt dem Don't Repeat Yourself

widerspricht und so.

Das kann schon durchaus so sein,

dass man sich da nicht wiederholt,

aber du kannst halt Änderungen machen,

die dann nicht lokale Auswirkungen haben.

Also nehmen wir an,

du weißt das halt alles nicht.

Du weißt halt,

du machst jetzt halt ein neues Item,

sozusagen,

das irgendwelche Spezialgeschichten hat,

schreibst da Code,

dass das halt irgendwie tut.

Und dabei bedenkst du aber nicht,

dass unter bestimmten Umständen

irgendwelcher anderer Code

irgendwas anderes tut.

Und dann passieren halt Fehler

und seltsame Effekte.

Und solange man halt

von dem ganzen anderen Code,

der irgendwie daran rummanipuliert,

irgendwie weiß,

ist das ja okay.

Aber sobald das Projekt irgendwie größer wird,

geht das irgendwann nicht mehr.

Und dann kann man überhaupt nicht vorhersagen,

was passieren wird,

wenn man jetzt irgendwie Dinge ändert.

Wie man manipuliert irgendwas

an den Lebenspunkten oder so.

Und dann gibt es irgendwann

was anderes,

was wiederum nochmal was anderes macht.

Ich bin der Invincible Geist.

Ja.

Ja.

Und das Mittel dagegen ist halt,

dass du eben nicht direkt die Daten

pro anfasst,

sondern dass du sagst,

okay,

wir haben hier eine Klasse oder so

und der ist,

bündeln wir den State,

also die Daten,

und die Logik,

die jetzt irgendwas damit macht.

Und haben dann eine API nach außen,

die öffentlich ist.

Und,

äh,

können sozusagen immer überprüfen,

dass alles ordentlich ist an einer Stelle.

Und dann,

ja.

Ja, die Frage war,

was ist ein Objekt in Python?

Was ist ein Objekt in Python?

Ja.

Ähm,

äh,

ich würde es jetzt mal sagen,

das erklärt aber nicht viel,

äh,

ist halt die Instanz,

äh,

konkretisierte Instanz von irgendwie

einer Klasse.

Also,

in einer Klasse definiert man sozusagen,

irgendwie,

äh,

ja,

äh,

äh,

eben eine Zusammenfassung von,

von,

von irgendwie Code,

der was tut.

Und,

äh,

irgendwie Daten,

äh,

die man irgendwie halten will.

Und,

ähm,

wenn man das jetzt,

das ist halt sozusagen die,

die,

äh,

Beschreibung.

Und wenn man da jetzt rauskommt.

Ich sag nicht so besonders an von dem Code,

der irgendwie,

irgendwie Beschreibung von irgendwelchen Sachen.

Ja,

also,

äh,

man könnte das vielleicht,

also,

äh.

Also ein Objekt ist ein Ding.

Also ich glaube in Python ist alles ein Ding.

Oder ein Objekt,

oder?

Alles ein Objekt,

ja.

Also,

also alles was es in Python gibt,

kann sich als Objekt darstellen.

Also ein Objekt ist immer,

ein Instanz einer Klasse,

wenn man das so sagt.

Ja.

Das heißt,

ähm,

alles was ihr habt in Python sind tatsächlich Instanzen von irgendwelchen Klassen,

von irgendwelchen Dingen.

Ja.

Ähm,

da,

die nächste Frage war,

was ist Self?

Self ist,

äh,

immer das Objekt selbst.

Also wenn man,

wenn das Objekt,

auch eine,

ist eine Konvention sozusagen,

dass man das so nennt.

Aber,

äh,

sehr sinnvoll das so zu machen.

Außer,

es gibt wiederum Spezialfälle,

bei denen man das ein bisschen anders macht.

Also,

wenn man,

ähm,

äh,

äh,

eine Methode hat,

also Methode ist nichts weiter als eine Funktion,

die sozusagen an so ein,

so eine,

Instanz an so ein Objekt gebunden ist.

Und,

ähm,

jetzt möchte man halt,

äh,

um zum Beispiel auf die Daten,

die man halten möchte,

in so einem Objekt,

äh,

äh,

um da drauf zuzugreifen,

muss man ja irgendwie sich selbst referenzieren können.

Deswegen wird immer als erstes Argument in Methoden,

äh,

das ist halt auch das,

was dann Methoden von Funktionen unterscheidet,

äh,

immer,

äh,

eine Referenz auf,

das,

äh,

auf,

auf sich selbst,

äh,

sozusagen mit übergeben.

Ja.

Man könnte das auch anders nennen.

Ja,

man kann auch sagen,

äh,

A statt Self,

dann ist es A,

aber,

ähm,

es ist schon sinnvoll,

das Self zu nennen,

damit man weiß,

dass es halt eine Referenz auf sich selbst ist,

sozusagen,

auf das Objekt,

was gerade,

was man gerade ist.

Und dann kann man halt auf Self-Punkt irgendwelche Daten zugreifen.

Okay.

Ähm,

da fangen wir jetzt direkt ein paar andere Sachen ein,

weil wir jetzt das gerade jetzt so hatten mit Objekt,

ne,

was ist denn ein Objekt?

Dann ist das eine Klasse.

Und jetzt gibt es irgendwie drei Dekoratoren,

also wir müssen noch gleich darüber sprechen,

was ein Dekorator ist,

aber es gibt drei Dekoratoren,

die,

ähm,

Python verwendet,

die da immer so drüber stehen.

Das ist Dessig-Method,

Class-Method und,

ähm,

Property.

Über Property hattest du eben auch schon.

Ähm,

was ist denn jetzt da irgendwie so der kleine Haken?

Also wann sagt man jetzt zum Beispiel,

das ist eine statische Methode?

Und wann sagt man,

das ist eine Klassenmethode?

Was,

was,

was heißt das denn in dem Kontext?

To Self und Objekt und,

äh,

Ja,

also ich würde,

ich würde eigentlich,

ähm,

am liebsten mit,

äh,

der Klassenmethode anfangen.

Also,

äh,

äh,

Class-Method.

Class-Method ist,

äh,

halt eine,

ähm,

äh,

eine Methode,

die eben nicht eine konkrete Instanz,

äh,

Das heißt,

da fehlt auch Self bei der,

Genau,

da,

da könnte man jetzt auch Self übergeben,

also es wäre dann sehr verwirrend.

Sondern was man da üblicherweise,

äh,

übergibt,

äh,

ist,

äh,

man CLS oder so und bekommt man die Klasse übergeben.

Na,

die Klasse ist auch wieder ein Objekt.

Das ist auch irgendwie,

man kann das auch noch ein Stückchen weiter treiben,

auch dann mit,

mit Metaklassen.

Aber,

Also die kleinste,

das kleinste Objekt,

also jede Klasse ist irgendwie ein Objekt und das Objekt,

Objekt und Objekt selber ist ein Objekt vom Typ,

Typ.

Hm.

Ja,

okay.

Ja,

okay.

Ähm,

man,

äh,

ja,

also,

ähm,

jedenfalls,

wenn,

in der,

in der Klassenmethode übergibt man halt CLS und nicht,

äh,

Self.

Weil man damit,

man halt weiß,

dass man jetzt gerade die Klasse in der Hand hat und nicht,

äh,

nicht,

äh,

eine Referenz auf,

äh,

die Instanz.

Und,

ähm,

äh,

es gibt halt,

das verwendet man vor allen Dingen dafür,

dass man,

es gibt halt bestimmte Methoden,

die brauchen eben nicht,

die müssen nicht auf irgendwelche,

äh,

internen Daten oder so zugreifen,

weil die hat man ja nicht.

Sondern,

die machen halt,

die,

die gehören zwar vielleicht irgendwie in die Klasse rein,

weil die Funktionalität,

die sie bieten,

halt sehr viel zu tun hat mit der Klasse.

Aber die verwalten,

verhalten,

verhalten sie in gewisser Weise natürlich dann so wie,

eine normale Funktion.

Ähm,

und vielleicht können sie auch auf Daten,

die halt für alle Instanzen dieser Klasse gleich sind,

zugreifen eben über die Klasse.

Aber,

ähm,

die brauchen jetzt nicht die,

ähm,

nicht,

nicht irgendwie eine konkrete Instanz,

auf der sie irgendwas machen.

Also Beispiel für,

äh,

sowas sind,

was ist denn ein gutes Beispiel für,

äh,

jetzt bin ich schon aus dem Spiel.

Also,

die können zwei Beispiele,

ich kann es,

äh,

gut visualisieren finde.

Entweder hat man so ein Spiel,

mit so Charakteren und so,

oder man hat so ein Universum mit Planeten und Dingen,

die umeinander kreisen oder sowas.

Zwei verschiedene Sonnensysteme als zwei Klasse.

Oh je.

Aber okay,

lass mir das.

Äh,

ich weiß nicht genau,

ob ich was da irgendwie,

also,

äh,

mir fällt da jetzt gar nichts.

Also ich,

man hat,

also es sind oft irgendwelche Hilfsfunktionen oder so,

die,

äh,

was machen,

was logisch dann in der Klasse gehört,

aber wo man nicht mit einer konkreten Instanz irgendwas,

äh,

zu tun hat.

Mir fällt jetzt tatsächlich kein super tolles Beispiel.

Was ist denn der besten Static Method?

Was wäre das denn jetzt so als?

Ja,

Static Method,

ähm,

ah,

die bekommt halt einfach tatsächlich überhaupt nicht mal die Klasse,

ja.

Aber im Prinzip ist es nichts anderes,

außer,

ähm,

sie nur nicht mal die Klasse bekommt.

Ja.

Das heißt,

sie könnte man auch draußen hinschreiben.

Genau.

Das einzige Unterschied bei der Static Method ist halt,

dass sie dann im Namespace der Klasse oder des Objekts aufrufbar ist,

oder so.

Ja.

Ja,

was ist jetzt in dem Vergleich eine Static Method?

Okay.

Ja,

also,

äh,

Static Method,

äh,

bekommt gar keiner,

äh,

gar kein,

auch ein automatisches,

äh,

Argument mit,

äh,

sozusagen,

also das wäre dann die reine,

äh,

wäre quasi wie eine Funktion,

ja,

also es ist egal,

ob man jetzt Static Method,

äh,

aufruft oder halt,

ähm,

äh,

ähm,

Funktion von draußen,

Funktion von draußen,

genau,

genau.

Ah,

äh,

äh,

richtig,

jetzt fällt mir doch wieder ein Beispiel ein zu Class Method,

wo das,

äh,

äh,

äh,

wenn man jetzt,

äh,

in,

in Django zum Beispiel Modelle hat,