Transcript: Fragen über Fragen

Ja, hallo liebe Hörerinnen und Hörer. Willkommen bei einem Python-Podcast in der 15. Episode.

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

Hallihallo.

Diesmal scheint sogar noch die Sonne zu sein. Wahnsinn.

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

Ja, wir haben tatsächlich Dezember irgendwie.

Ja, der 12. Dezember, genau. Vielleicht gar nicht so schlecht, wenn wir das mal dazusagen, wann das ist.

Ja, wir haben uns ein bisschen Zeit gelassen in letzter Zeit mit den Folgen, es war 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 aber 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. Ein paar ganz grundlegende Sachen.

Vielleicht wird es ja spannend.

Also, ja, keine Lava-Folge, kennt ihr schon.

Wen ihr schon gehört habt.

Ja, ja.

Genau, das mit den Themen können wir auch

irgendwann mal klassen.

Die nächste Lava-Folge.

Ja, was machen wir hier eigentlich heute?

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 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

halt ein Traceback kriegt, wenn man was für den Entwicklungsserver

zu starten und

ja, unter anderem sowas wie

Django-Model-Utils, was

irgendwie fast alle Leute, also ich verwende

das eigentlich immer. Wahrscheinlich auch eine Menge andere Leute

wegen

Timestamp-Model oder so, was man ja

oft verwendet.

Ich weiß nicht mehr genau,

was es noch alles war.

Ich habe dann für die Sachen, die

nicht funktioniert haben, da habe ich dann

einfach die geforkt auf GitHub

und

habe das dann versucht zu fixen und dann halt

entsprechend immer Pull-Requests aufgemacht.

Also das heißt, ihr könntet bei Jochen

in den Repos versuchen, die auch bei

Dango 3 funktionieren?

Nein, nee, das sollte man vielleicht

nicht machen, also

Daran wird sich das irgendwie

mitten oder so, nee, nee, nee

Aber es hat mich gewundert, wie viel da noch

nicht funktioniert hat, also es war bei so einem

normalen, ich weiß nicht, bei welchem

ich das probiert habe, entweder bei einer Webseite oder

auch bei der Python-Podcast

Projekt-Dings

habe ich mal versucht, das auf Django 3

umzustellen und das ist

mit fünf

Einhängigkeiten oder so sind kaputt gegangen

und ich glaube, ich habe auch so fünf Pull-Requests

irgendwie gemacht. Also bei Danko gibt es irgendwie

immer drei oder vier Versionen, oder nee, drei.

Also 0, 1 und 2 und dann ist

nämlich das Major Release. War das nochmal was?

Also ich glaube 0 ist immer so die neue

Feature-Sachen? Nee, ist immer

gerade, ungerade. Gerade

sind immer die Long-Term. Ich glaube

2 ist Long-Term. Punkt 2.

Also 2.2, 1.2, 3.2

sind die Long-Term.

Und 1...

Ich bin mir sicher. Okay, gut, sehr gut.

Und 1 ist irgendwas anderes, das weiß ich

nicht. Aber ja, deswegen habe ich nur gefragt.

was man dann macht? Also für Security-Patches dann wahrscheinlich

mal die 2er-Version nehmen, dass man irgendwie stabil sein möchte?

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, 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 rummacht. Und wenn man halt

auf der Long-Term-Support-Version sitzt, dann

ja, 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, die 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.

Okay. Und ich

versuche das auch immer und normalerweise funktioniert, also bis jetzt

auch die 2er-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, es sind nur noch Tage.

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

18, 19.

Ja.

Ja.

Aber es waren noch so ein paar

Geschichten dabei,

so zum Beispiel, man konnte irgendwas, es gab so einen

Dekorator-Pi2-Unicode-String

oder sowas, 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

ja, Python 2

und Python 3 Geschichten sind.

Ich unterbreche dich gerade ungenau. 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.

Es sind ein paar Hilfsfunktionen,

die einem dabei helfen, das für Python 2

und Python 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

Geschichten waren jetzt halt dann

weg. Und das hat

dann auch diverse Pakete gebrochen

und insofern, ja, also

Umstieg auf Django 3 nicht so super easy.

Wie lange ist es, bis Django 2 rauskam?

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?

Das geht ja. Ja, also die

Release-Zyklen bei Django sind ja auch viel kürzer geworden.

das war früher alles viel länger und

ja, Django 2 gab es

jetzt gar nicht so lang. Ja, wenn du noch

welche News einst, weil sonst machen wir tatsächlich weiter mit

Content heute. Ja, ne, Content

klingt gut. Also ich stelle

jetzt immer ein paar blöde Fragen

und ich

versuche dich dazu zu bringen, dass du die Fragen möglichst

kurz beantwortest.

Oder so eine Minute pro Fage oder so.

Vielleicht schaffen wir das.

Wow, okay.

Ja, alles klar.

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

Das ist natürlich auch was anderes.

Aber mal gucken.

Ja, schauen wir einfach mal.

Also erste Frage.

Ist Python eine Schlange?

Ah, wo kommt der Name her?

Also, nee, tatsächlich ist das eine Referenz auf Monty Python.

Spam, Spam, Spam, Spam, Spam, Spam.

Genau, genau.

auch interessant,

der

Monty Pythons

Flying Circus, also

der Flying Circus ist wiederum

eine Anspielung auf, glaube ich,

Ersten Weltkrieg, Roter Brunnen,

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 Flugplätze ja damals noch gar

nicht gab, wurden die dann halt auch mal

der fliegende Zirkus genannt und

ja,

ja, aber wo

Monty Python eigentlich herkommt,

weiß ich jetzt auch nicht. Also Guido hat sich das dann ja irgendwie

so ausgedacht. Genau, also

die Referenz

des Namens der Programmiersprache

bezieht sich schon auf 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 mein Körper

tätowieren lasse, dann ist das natürlich ein Zeichen von meiner

Liebe zur Sprache.

Tja. Ja, 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. Ja.

Tja, da musst du dich wohl entscheiden.

Ja.

Nächste Frage wäre,

welche Einsatzzwecke von Python fallen dir ein?

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 R 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

drumherum. Es gibt 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 der

PyData-Stack.

Ja, also das ist auf jeden Fall

das größte

Thema, glaube ich, momentan, aber Web-Entwicklung

ist nach wie vor auch sehr groß.

Dann eine Geschichte, die

jetzt kommt irgendwie,

da wollen wir auch unbedingt

nochmal 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

so um Weihnachten rum, dann kann ich 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 das so

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

normalerweise schreibt, aber

es gibt halt auch mittlerweile Chips, auf denen

man Mikro-Python

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 Falken geschrieben und das ist halt das Ding,

was zum Verwalten von diesem ganzen Kram halt

üblicherweise so verwendet wird, wenn man

jetzt nicht irgendeine fertige Lösung

wie jetzt, na, wie heißt

das denn, von Apple

oder Google oder

Amazon oder so, die haben natürlich ihre

eigenen Geschichten.

Und was ich da interessant, ich habe da letztens noch mal

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. Okay, cool.

Ja, weil die Leute am meisten gerne daran basteln, ne?

Ja, ich war

überrascht, wie viel das ist, weil

das ist ja jetzt eben noch nicht so prominent

als, ich glaube, es waren sowieso sehr wenig

Open-Source-Projekte in den ersten 10.

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 10, 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 irgendwie

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,

ich glaube, 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,

in denen es passiert.

Viele der Top-Seiten sind irgendwie

eins von beiden.

Also, genau.

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?

Hm, das, ä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, das ist 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, 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 gesehen haben.

Genau, dass das das Gleiche wäre,

aber das stimmt halt nicht.

Die Syntax ist ja auch bei Programmiersprachen

eigentlich gar nicht so...

Also für Anfänger schon, die verstehen

erst mal überhaupt nicht, was da steht. Das ist der erste Schritt

zum Verstehen, 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

ja,

es gibt ein paar

Verben sozusagen für Worte.

Hast du aber die ganze Standard-Library mit bedacht?

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

aber das muss man ja auch alles gar nicht so unbedingt

können.

Wenn man die Syntax und halt die paar

Worte, die es tatsächlich gibt,

kann, dann kann man das ja zumindest mal alles lesen.

Ja, also

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 eine Geschichte,

die dauert einfach. Da gibt es

dann halt auch Sachen, wie man das schneller hinkriegt und

wie man das effektiver üben kann und so.

Aber

wenn man das dann kann,

dann kann man sich

eigentlich in jedes Thema relativ schnell

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

Und das ist halt

auch, denke ich, also die entscheidende

Geschichte, die man

können sollte.

Sich in Themen schnell einarbeiten.

Ja, beziehungsweise die Prinzipien des Programmierens.

Diese Geschichte, die halt lange dauert, halt schon

vorher erledigt haben, weil das

wird einem niemand gerne bezahlen wollen,

sondern das lernt man, das

lange dauert. Aber ich würde auch sagen,

da gibt es halt enormes 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 strugglen da

und nicht die Mehrheit aller Programmierer

kann ordentlich programmieren, würde ich jetzt mal so sagen.

Ja, das musst du eigentlich noch definieren,

was denn ordentlich programmiert ist.

Und das ist vielleicht auch, das kann ich ehrlich gesagt

gar nicht so genau.

Und es ist auch die Frage,

eigentlich ist es auch wieder so ein bisschen,

ich will eigentlich niemanden ausschließen.

Ich würde sagen, ja,

selbst wenn man das nicht so total hundertprozentig kann.

Wahrscheinlich haben die meisten von uns

auch schon irgendwie Jobs gemacht, wo sie

dachten, dass sie dafür eigentlich gar nicht geeignet

wären oder so und das haben dann halt irgendwie gelernt.

So ist das halt auch

normal, das ist wahrscheinlich auch in anderen Bereichen

so und 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 total perfekt.

Ja, aber du musst ja trotzdem damit rausholen,

was denn jetzt richtiges Programmieren dann überhaupt ist.

Also das ist ja zwar eigentlich jetzt nicht auf meiner Liste, aber dann musst

du jetzt in kleinen Kurvortrag teilen. Ich gebe dir sogar

zwei Minuten.

Naja, das wäre

gar kein Problem, das sind zwei Minuten, ist ja klar.

Also ich würde

sagen, wenn man halt

nichts total, 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

nur so ein bisschen nicht ordentlich

sind, sondern so Kleinigkeiten, sondern

dass so Dinge so gar nicht richtig sind eigentlich.

Was gehört denn dazu, also was würde denn da?

Also ich würde sagen eben, dass

der Umgang mit den

ganz einfachen

Datenstrukturen, ja, also

irgendwie Listen,

Dicks,

irgendwie Skalare und damit halt ordentlich umgehen kann.

Also wenn man das schon kann, ist schon viel,

hat man schon viel,

weil das schon viele Leute nicht so richtig hinkriegen

und ja,

dann halt,

dass man eben

Sachen halt ordentlich in Funktionen packt,

nicht irgendwie Spaghetti-Gut schreibt, dass das halt alles so

halbwegs, sondern sich nicht

dauernd wiederholt. Dry, don't

repeat yourself.

Ja, aber da

gehen wir fast schon in diese Detailgeschichten,

oder dass man halt Tests schreibt und diese ganzen

Best Practices verwendet

und Versionskontrolle verwendet und so.

Mit den Daten schon, das musst du später nochmal sagen, da habe ich noch ein paar

Fragen, da müssen wir nochmal ein bisschen drauf eingehen, was denn

überhaupt jetzt im Skalar-Daten schon

was alles ist, 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. Das Problem ist natürlich, wenn man

jetzt jemanden liest, wo du sagst, die Mehrheit der Programmierer

ist gar nicht so hervorragend

und dann lese ich jetzt von...

Ich würde es vielleicht anders sagen,

da ist viel Verbesserungspotenzial. Also wenn man sich anguckt,

was, wenn der Code, der geschrieben

wird von Leuten oder der so in Firmen

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 da seinen eigenen Code anguckt,

dann ein halbes Jahr später, dann denkt man natürlich schon so,

oh, was willst du sagen?

Ist das auch so, ja.

Genau, aber ja.

Ja, was, erstmal,

also ich habe noch eine Basisfrage bekommen von Olli,

die hat ja noch geschrieben, Tipps für eine gute Syntax,

dein Top 5 oder so.

Ich, heute,

heutzutage würde ich sagen, Black verwenden und nicht mehr

drüber nachdenken.

Also einfach Black, bumm.

Also Namen vielleicht auch.

Namen sind natürlich, das sind ganz,

eine ganz schwierige Sache. Also wie kommt

man da auf gute Namen? Da muss man auch lange drüber nachdenken

oft. Also

ja, da gibt es ja auch mal den bekannten

Witz, was sind die zwei schwierigen

Sachen?

Ja,

in der Informatik irgendwie

Dinge benennen, Caching und

oft bei One Error

Errors. Ja, aber

genau. Also Dinge benennen

ist schwierig, ist eine Kunst und

ja, wo man sich da auch dran

orientieren kann, ist so ein bisschen wie bei

guten Kommentaren, sollte er

darauf achten, hinzuschreiben,

warum man das macht oder was das macht.

Nicht so sehr, wie da

irgendwas passiert oder so.

Ja, und

halt dabei, wenn man verschreibt,

dran denken, dass

das, wenn das

jemand liest, dann halt verständlich

sein sollte, weil Code viel öfter gelesen wird,

als geschrieben.

Ja, okay.

Was ist mit sowas wie List Comprehensions?

Würdest du das bevorzugen gegenüber klassischen

loben. Nö, kommt drauf an.

Also ich würde sogar eher ein bisschen

die andere, ich würde sagen

lieber eine Vorschleife

verwenden und List Comprehension

halt eher dann, wenn es halt irgendwas

einfacheres ist, wo

ja, wenn es halt offensichtlich und einfach ist,

dann kann man auch gerne List Comprehension

verwenden, aber wenn man, also

ich meine,

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 ich habe dann auch schon nicht List Comprehensions

gebaut, irgendwie, wo ich dann

halt mehrfach

verschachtelt irgendwie über Dinge iteriert habe

und das wird bei List Comprehension sehr, sehr

schnell, sehr, sehr unübersichtlich,

wo ich dann halt irgendwie stolz darauf war, so ein Statement

hingekriegt zu haben.

Nicht in einer Zeile, das geht dann halt

nicht mehr in einer Zeile, aber dann so drei Zeilen

List Comprehension irgendwie

mit Bedingungen drin und verschachtelt

und 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 drauf guckt, der das

verstehen muss und das

unter einem gewissen Zeitdruck tut, dann

würde der sich wahrscheinlich irgendwie

Rot vor Wut.

Spaß zur Ärger.

Da gibt es

das Remote Strangulation Protocol

irgendwie zur Hilfe wünschen.

Das Remote Strangulation Protocol?

Ja.

Ich weiß nicht.

Das kennt wahrscheinlich auch keiner.

Damals gab es so einen Text,

auch schon lange her,

Bastard Operator from Hell

und da gibt es die SysAdmin,

also es gibt die SysAdmin

ManPages oder die

SysAdmin Recovery,

gab es eine News Group

und dann ASR,

Alt SysAdmin Recovery,

das war die News Group und dann gab es die ASR

ManPages und Tools.

Ich glaube, wenn man ManASR

sagt oder ManKnife oder

Mansnip oder so, dann

kriegt man das auch noch irgendwie auf dem Linux

zu sehen. Da gibt es dann Tools,

mit denen man irgendwie Usern

die

Attitüde von Usern

wieder rejustieren kann

und diese Tools sind halt sowas wie

Snip

oder Knife

mit der Axt

irgendwie mal dazwischen geht und

Dinge gerade richtet.

Die Attitüde von Usern regulieren, das hört sich toll an.

Ja, das klingt

nach Spaß an, wenn man auf der

richtigen Seite steht.

Ja, ist natürlich so ein bisschen,

ich meine, das Mindset dahinter ist auch etwas fragwürdig,

aber es ist damals was irgendwie lustig.

Und da gab es auch Protokolle

und eines der Protokolle in dem Zusammenhang ist halt,

dass RSTP, RS, weiß nicht,

eben Remote Strangulation Protokoll

über Fernverbindungen.

Sehr gut, sehr gut.

Ja, das ist das, was man in Startorganisationen gerne hätte

oder wo man dran arbeitet, das automatisch zu bekommen.

Also ihr braucht gute Admins für den Start,

damit das funktioniert.

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, das ist so ein Ding, was heutzutage

auch wieder in aller Munde ist, wobei das

auch selten tatsächlich so ist.

Würde ich sogar sagen,

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 Frontend.

Also Full-Second-Python geht gar nicht, weil

das geht nicht richtig, genau, weil du mit Frontend

bist du halt nicht, da brauchst

du halt dann schon JavaScript für

und 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 könnte natürlich Python auch irgendwie Richtung

WebAssembly kompilieren

und dann halt im Frontend verwenden, aber es gibt

keine, es gibt

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 Full-Tag machen wollt.

Und mit nur Python kriegt ihr das gar nicht so hin.

Aber vielleicht wollt ihr das ja auch gar nicht so machen,

weil warum sollte man Full-Tag machen, wenn man nicht andere Sachen

wie Data und Backend so gut kann?

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.

Ein bisschen CSS könntest du vielleicht schon machen oder sowas.

Ja, 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 es ja so ein paar Framework, ne?

Grid, Materialize und so.

Naja, also ohne da was. Aber das ist

ja was anderes. Ja, also Fullstack geht gar nicht

nur mit Python. Ja, und das

ist tatsächlich auch einer der großen

Risiken irgendwie

für die Zukunft von Python, wenn das halt

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,

das wird dann JavaScript, weil das natürlich auch gewisse

Vorteile bringt. Du kannst, Marcel, dann

schreibst du einmal den Code, kannst ihn 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, das ist natürlich eine gute Sache.

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, noch ein Import-Sys.

Import-Sys, Son 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, den Interpreter öffnen, einfach Import-Sys eingeben und abschicken.

dann seht ihr das. Then of Python, also die Prinzipien,

die man sich

darauf geeinigt hat, die in Python gelten, sollen

auch sein, wenn man die Anwendung versteht.

Da ist auch immer so ein bisschen Humor mit dabei.

Aber ja, ist auch was dran.

Ja, das ist direkt verknüpft zu

PEP 8. Ich glaube, das hatten wir dann auch schon mal kurz erwähnt.

Ja, das ist sozusagen einfach nur die

Art, wie man

relativ minimalistischer

Konsens

darüber, wie man Python-Code formatieren

sollte, vielleicht.

Wer macht das nicht, dann kommt

hier in die Python. Ja, aber

auch innerhalb von Tab 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. Du kannst ja Dinge machen, die

Ich finde 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 extra, wenn

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

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

Oder halt, wenn Kommentare am Ende der

Zeile sind, dann bricht ja 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 der, 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 diesem 89 Zeichen

Editor-Quatsch, weil ganz ehrlich,

so Enzien, 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 da, ne, ne, der Standard ist immer noch so.

Also wenn, ist auch so, wenn du, 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.

Auf einer Konsole?

Ja, ich,

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 gut.

Also wenn ich mich auf meinen Server einlogge,

habe ich da mehr als 80.

Ja, natürlich, aber du hast...

Über die Konsole, über meine Shell.

Hast du dich mal an eine Konsole gestellt,

an einem Rechnerzentrum, 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, ich weiß auch nicht.

Also ich glaube auch nicht,

das ist eigentlich nicht mehr relevant,

aber da kommt das halt her.

Das heißt, wenn, dann sieht man da halt, muss man kurz

drauf aufpassen, dass es dann umgebrochene Zeilen

gibt, die automatisch vielleicht

eingruckt 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 den Zeilen.

Aber wenn,

also ich glaube, ich habe es auch irgendwo auf

einer 10 stehen, aber 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.

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

Arbeitsrechner irgendwie vernünftig anlesen kann, dass es dann nicht immer

halb so groß ist, dass man viel zu viel Platz braucht.

Das wäre ja völlig unabsichtlich und hässlich, einige Sachen.

Also ich finde, DECK 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.

Also ich finde das

wo 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, äh,

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, oder so viele

Firmen haben das auch, die ja alles

alles doof finden, was sie nicht selber gemacht haben und dann

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

Wir empfinden das Rad nochmal von vorn.

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

Also die Grundlagen zu verstehen, ist gar nicht so

schlicht und hat man irgendwann nicht

keinen mehr, der versteht, wie es irgendwann mal gebaut worden ist.

Es sind nur noch Leute, die dann irgendwie auf dem

Sand und der Asche von alten versunkenen

Stieten versuchen, neue Gebäude zu errichten.

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

Und dann steht es ja Palast 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, dann

naja. Ja, es ist

immer schwierig. Man muss halt eine richtige

Balance finden. Es ist manchmal gut,

Dinge, also ein Beispiel dafür

wäre auch dieses Timestamp-Modell

aus den Model-Utils. Ja, deswegen haben alle

als Abhängigkeit Model-Utils drin.

Dabei, ja,

ist dann auch so,

wie meinte ich, über Django 3 kurz

auch

gesprochen und

Und dann 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 schlimmen 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, Parc-V-Resonierung muss immer stimmen und genau dem Zustand bleiben und wenn du 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 von irgendeiner, ja.

Also man kann nicht sagen, das eine ist super schlecht, das andere ist, sondern man muss halt 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 erst mal 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 und das selber zu implementieren.

Ja, über die Zeit ist es natürlich so, dass auch der Level an Abstraktion, auf dem man arbeitet, wird immer höher eigentlich, weil halt immer mehr wird Commodity, also die Sachen, die früher der interessante Bereich war, 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, also auf der einen Seite kann man sagen, man kann halt mit viel weniger Zeilencode irgendwie viel kompliziertere Dinge und tollere Sachen bauen, auf der anderen Seite ist es halt, wenn man sich das manchmal genauer anguckt, steht das alles so ein bisschen auf tönernen Füßen, das ist halt so Kartenhaus über Kartenhaus geschichtet und irgendwie 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, also ja, aber in Wirklichkeit hat man diese Probleme nicht wirklich gelöst.

Wenn man halt das Gebäude, den Palast aus der Sandgrube

baut, man kann tatsächlich noch ein paar Stahlträger einziehen,

das dann zu tun hat, könnte der Palast auch gehalten werden.

Das ist halt dann, ja.

Ja.

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

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

was so, ne, Python generell,

was das so 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, so, was man auch vielleicht

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

hatte, ne, schreibt uns wieder, wie immer,

hallo at pythonpodcast.de, so.

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 Modulen und Paketen?

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.

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.

Du kannst das ja auch

reinschreiben, was du

exportieren willst, welche Symbole.

Interessanter Fall ist,

kann man da auch Sachen ausschließen?

Also, dass ich zum Beispiel sage, ja, auch 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

Zugriff drauf hat und dann einfach

sagen, Import-Folder-Name

oder sowas. Und wenn da eine Inis-Pi drin ist,

dann kann man die Module, die da drin sind,

einfach aufrufen mit

seinem Import-Teil. Und dann kann man

Modul-Verzeichnis-Name, 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 Init-Py vergisst,

sozusagen. Oder wenn die aus irgendwelchen Gründen abhanden

gekommen ist, was ja auch manchmal vorkommen kann.

Und dann kriegt man Tracebacks, die sehen

irgendwie komisch aus. Und man

sieht den nicht sofort an, dass da eine Input-Wire

fehlt. Irgendwann weiß man halt einfach so,

ah, das sieht jetzt danach aus, okay, das könnte sein,

dass da einfach eine Input-Wire fehlt, aber...

Ich hab zehn Minuten da vor meinem Bildschirm gestanden und überlegt,

warum macht der jetzt nicht die Migrationen von

meinem Dankmodell, den ich da geschrieben habe, verstehe ich nicht.

Und dann fehlte einfach die Input-Wire, Migrations-

Bruder und dann, ach so, ja klar, kennt der ja nicht,

kann der ja gar nicht sehen.

Aber da muss man auch drauf kommen, tatsächlich, sonst...

Ja, das ist so ein bisschen...

Genau, und eben, ja, also gute

Idee

mit, was sind eigentlich Paketemodule

wie funktioniert eigentlich ein Port-System?

Da müssen wir uns auch nochmal beschäftigen, aber da

müsste ich mich auch erstmal anlesen. Das weiß ich jetzt alles gar nicht so genau.

Ja, das kriegen wir bestimmt noch

jeden Tag. Aber wir haben ja die Minute schon wieder überschritten.

Ah ja, gut.

Aber Inipi ist ja immer mit dann, dann, also doppelt

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 das.

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

und Underscore halt irgendwie gepräfixt

und Sachen, die halt

sozusagen

dann gibt es einfach ein Underscore, das ist halt

so markiert

für

Aber ja, also sollte man nicht, ist auch eher so interner Gebrauch.

Ja, aber es ist jetzt nicht so total privat.

Ja, also es ist eine Konvention.

Im Grunde braucht man das auch, also außer jetzt manchmal bei Double Underscore eigentlich auch nicht wirklich.

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 Magic-Method-Kontext von

Klassen, wo man halt dann irgendwelche magischen

Methoden, die es identifiziert, überschreiben will,

um andere Effekte zu erzeugen.

Ja, es ist halt so ein

Hinweis darauf, dass man

da nicht

wirklich mit interagieren

sollte. Nicht umfummeln, ich fasse meine Klassen nicht an.

Alles, was man selber schreibt,

kann man immer anders kaufordern, wie man anderes

anfasst.

Ich versuche mal ein Beispiel zu geben, also wenn du

eine Klasse hast, die irgendwas casht, dann

packst du halt

wenn, also du rechnest

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

sozusagen 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

wenn du die Methode aufrufst, zuerst habe ich

das schon ausgerechnet, wenn ja

gibst du einfach das

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.

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 dann gibt es ja meistens

ein öffentliches

Attribut, was man benutzen

kann und dann kann die Klasse das intern

handeln, wie sie das integriert.

Ja, im Grunde

eine Schnittstelle,

die Schnittstelle zu irgendwas.

Das 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 irgendeine Python-Bibliothek oder so,

dann ist die API das,

was man sozusagen von außen benutzt.

Die besteht ja aus ganz vielen Funktionen.

Befehle, die man für seine Bibliothek benutzen

kann, um die

für den Anwendungsfall...

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ß

der 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 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

für intern gebraucht.

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 in anderen Programmiersprachen gibt es da

eine stärkere Unterscheidung,

aber im Grunde ist es einfach so.

Also ich hatte es gerade so in den Anfängertagen

ganz oft so, dass ich irgendwie mir dachte,

private Variablen, das ist alles irgendwie

ein bisschen blöd. Ich muss ja irgendwie von der Funktion immer

irgendwie so einen Wert returnen und damit das dann, also ich glaube

im Kontext einer Funktion sind ja eigentlich die Variablen

immer privat. Nein, nein, nein, nee,

das ist eine Verwechslung. Also du meinst lokal.

Lokal und global.

Privat und öffentlich, das ist halt genau

diese Geschichte mit dem Double Underscore.

Ja, okay. Dann meinte ich lokal

Und global, ja. Also lokal heißt, Variablen sind halt quasi in dem Block gültig. Und ich habe immer gehört, man braucht keine globalen, man darf die nicht nehmen oder es ist total nicht so backrested.

Kann man schon.

An einigen Stellen habe ich halt gemerkt, also gerade ich habe mal so Spielereien gemacht, Spiele gebaut oder sowas, da hat es immer total super geholfen, weiß ich nicht, die Lebensenergie des kleinen Männchens global zu definieren, anstatt in einer Funktion oder so.

Ja, kann man durchaus machen. Es gibt auch Fälle, wo das durchaus praktische Anwendungsfälle hat. Es kommt halt darauf an, was man damit machen möchte. Man muss das halt explizit als global markieren, wenn man das tun möchte.

und dann gibt es auch 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 an 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

haben 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.

Wofür muss ich

denn dann an der einen Stelle, wenn er jetzt,

weiß ich nicht, auf ein Skelett trifft, dem Zehn

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 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.

Irgendwas muss diesen State verwalten.

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

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 noch nicht tot ist

oder so. Genau, und das erhöhe

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

und so. Aber diese Logik, wie

das funktioniert, wäre dann halt an einem

Ort gebündelt. Das ist ja so ein bisschen die Idee auch hinter

Klassen.

Hinter Objektorientierter Programmierung, dass du

halt die ganze Komplexität

irgendwie verbirgst.

Hinter

ja, hinter dieser

in diesem Objekt hinter einer API

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

jetzt dann doch Sinn?

Mir fällt da fast keins ein,

wo das irgendwie sinnvoll ist.

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 ein Singleton nehmen,

beziehungsweise in Python eher Borg-Pattern.

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

Ja. Borg-Pattern, hast du gerade gesagt?

Ja, okay.

Was ist ein Singleton, was ist ein Borg-Pattern?

Du musst wieder anfangen.

Also sozusagen

Singleton

ist, wenn

garantiert sein soll, dass es von einer bestimmten

Geschichte nur eine Instanz gibt. Also wenn ich

zum Beispiel eben

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 sehen.

Es gibt nur einen, es wäre jetzt blöd, wenn ich zwei

davon erzeuge und dann in dem einen

Objekt verlinke 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

so, weil dann kommen wir zu dem Borg-Pattern,

so wird das üblicherweise dann in Python implementiert,

ist, man macht es einfach so, dass

wie ging das da?

Also ich glaube, der Trick ist,

aber das muss man mal nachgucken, also mit Vorsicht genießen,

ist, dass sozusagen

den State innerhalb

von der, eines Objekts

sozusagen in der

Klassenvariable zu halten, die halt bei allen Instanzen

gleich ist. Und 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. Im Gänger-Vorbuch gibt es

halt das Pattern Singleton,

weil man eben nicht immer

tatsächlich, also ich glaube, die

ursprünglichen Singleton-Beschreibungen, das wird einfach immer

die gleiche Instanz

retornt, wenn man halt die...

Also das heißt nie überschreiben. Das würde halt bedeuten, wenn

schon ein anderes gibt, retornt es halt das.

Retornt 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's?

Ja.

Ja, aber genau, das sind alles,

es geht immer so um State Handling

im Grunde. Das ist immer so das, und

wer manipuliert den und wie kann man

dafür sorgen, dass der, dass man

die,

den Code, der den State manipuliert,

an einer Stelle behält und so.

Weil das sind immer so, das ist was, was halt

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, aber

und zieht das dann durch,

unabhängig davon, wie das Problem eigentlich ist

und das fiese,

was manchmal dann oder fast immer passiert

irgendwie, ist, dass man dann halt den

State verteilt über viel Code

und dass man dann halt... Was ist überhaupt State?

Das, was ich,

das, was du speichern musst,

was sich irgendwie ändert.

Der Status.

Ja.

Also sagen wir mal so, bei einer Web-Applikation

würde man sagen, das ist der State

einer Web-Applikation, liegt üblicherweise dann eben

in der Datenbank.

Das ist so eine klassische...

Ja, 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 das ist halt nicht dynamisch generiert, sondern das liegt dann irgendwo rum. Das heißt, wenn man das ändern möchte, dann muss man ja erst die Daten anfragen oder sowas. Das macht man dann gar nicht woanders.

Ja genau, also

so

ja, 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 Lebensenergie

hat die? Wie viel Rüstung hat die noch an? Das wäre der State.

Genau, dann gehst du irgendwo in einen virtuellen

Laden und kaufst dir irgendwie das

magische Sonstwas-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. Also damit das sich jetzt nicht widerspricht,

darf es immer noch ein State geben.

Das, was dahinter steckt.

Die interessante Frage ist, wie verwaltet man diesen

State sozusagen?

naiv wäre halt,

man hat halt zum Beispiel,

Held ist halt in irgendwelchen globalen Variablen.

Man hat halt eine Liste, die ist halt

global und genau, da steht halt

drin, ja, 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, die jetzt irgendwie

solche Sachen abbildet, wie

das Flammenschmerz 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

ein 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 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. 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, also 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 machst jetzt halt ein neues Item, das irgendwelche Spezialgeschichten hat, schreibst da Code für, 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 rumanipuliert, 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 irgendwas anderes,

was wiederum nochmal was anderes macht.

Der Invincible Geist.

Ja, und das Mittel dagegen ist halt,

dass du eben nicht direkt die Daten anfasst,

sondern dass du sagst, okay, wir haben hier eine Klasse oder so

und 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 können sozusagen immer überprüfen,

dass alles ordentlich ist an einer Stelle.

Ja, die Frage war, was ist ein Objekt

in Python? Was ist ein Objekt in Python?

Ich würde es jetzt mal sagen,

das erklärt aber nicht viel,

ist halt die Instanz,

konkretisierte Instanz von

einer Klasse.

Also mit einer Klasse

definiert man sozusagen

eben eine Zusammenfassung

von Code, der was tut

und irgendwie Daten,

die man irgendwie halten will und

wenn man das jetzt, das ist halt sozusagen

die Beschreibung

und wenn man da jetzt daraus...

Ich sage nicht so besonders an von dem Brot, der irgendwie

Beschreibung von irgendwelchen Sachen...

Ja, also man könnte das vielleicht

also...

Also ein Objekt ist ein Ding. Also ich glaube in Python ist alles ein Ding

oder ein Objekt, oder? Alles ein Objekt, ja.

Also alles, was es in Python gibt, kann sich

als Objekt darstellen. Ein Objekt ist immer

eine Instanz einer Klasse,

wenn man das so sagt. Ja.

Das heißt, alles, was ihr habt

in Python, sind tatsächlich Instanzen von irgendwelchen

Klassen, von irgendwelchen Dingen.

Die nächste Frage war, was ist Self?

Self ist immer das Objekt selbst.

Ja, es ist auch eine

Konvention, dass man das so nennt, aber

sehr sinnvoll,

das so zu machen. Außer es gibt

wiederum Spezialfälle, bei denen man das ein bisschen anders macht.

Also wenn man

eine Methode

hat, also Methode ist nichts weiter als eine

Funktion, die sozusagen

an so eine

Instanz an so ein Objekt gebunden

ist. Und

jetzt möchte man halt, um

zum Beispiel auf die Daten, die man halten möchte, in so

einem Objekt, um da drauf

zuzugreifen, muss man ja irgendwie sich selbst referenzieren

können. Deswegen wird immer als erstes Argument

in Methoden,

das ist halt auch das, was dann Methoden von Funktionen

unterscheidet, immer

eine Referenz auf

sich selbst

sozusagen mit übergeben. Man könnte das auch

anders nennen. Man kann auch sagen,

A statt self, dann

ist es A, aber 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.

Da fangen wir jetzt direkt ein paar andere

Sachen ein, weil wir jetzt gerade so hatten mit Objekt.

Was ist denn ein Objekt? Es ist eine Klasse und

jetzt gibt es irgendwie drei Dekoratoren.

Wir müssen auch gleich darüber sprechen, was ein Dekorator ist.

Aber es gibt drei Dekoratoren, die

Python verwendet, die da

immer so drüber stehen. Das StaticMessage,

ClassMessage und

Property, über Property

hattest du eben auch schon. Was ist denn

jetzt da irgendwie so der kleine

Haken? Also wann dachte man jetzt zum Beispiel,

das ist eine statische Methode und

wann dachte man, das ist eine Klassenmethode? Was heißt

das denn in dem Kontext zu Self und Objekt

und... Ja, also

ich würde eigentlich am liebsten

mit der Klassenmethode

anfangen. Also... Class Method.

Class Method ist

halt eine

Methode, die

eben nicht eine konkrete Instanz.

Das heißt, da fehlt auch Self bei.

Genau, da könnte man jetzt auch Self

übergeben, das wäre dann sehr verwirrend.

Sondern was man da üblicherweise übergibt

ist ein CLS oder so

und bekommt man die Klasse übergeben.

Die Klasse ist auch wieder ein Objekt.

Man kann das dann auch ein Stückchen weiter treiben,

auch dann mit dem Meta-Klassenanschluss.

Also das kleinste Objekt, also jede Klasse

ist irgendwie ein Objekt und das Objekt-Objekt-Objekt

selber ist ein Objekt vom Typ-Typ.

Ja, okay.

Ja, okay.

Ja, also jedenfalls in der Klassenmethode übergibt man halt CLS und nicht Self, weil man damit halt weiß, dass man jetzt gerade die Klasse in der Hand hat und nicht eine Referenz auf die Instanz.

Und 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 internen Daten oder so zugreifen, weil die hat man ja nicht.

Sondern 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 verhalten sich in gewisser Weise natürlich dann so wie eine normale Funktion.

Und vielleicht können sie auch auf Daten, die halt für alle Instanzen dieser Klasse gleich sind, zugreifen eben über die Klasse.

Aber die brauchen jetzt nicht irgendwie eine konkrete Instanz, auf der sie irgendwas machen.

Also ein Beispiel für

sowas sind, was ist denn

ein gutes Beispiel für?

Jetzt bin ich schon aus dem Spiel.

Also zwei Beispiele, die ich ganz

gut zu visualisieren finde. Entweder hat man

so ein Spiel mit so Charakteren

oder man hat so ein Universum mit Planeten

und Dingen, die umeinander kreisen oder sowas.

Zwei verschiedene Sonnensysteme als

zwei Klassen. Okay, lass mir das.

Ich weiß nicht so genau, ob ich das da

irgendwie, also

mir fällt da jetzt gar nichts, also

es sind oft irgendwelche Hilfsfunktionen

oder so, die was machen,

was logisch dann in der Klasse gehört, aber

wo man nicht mit einer konkreten Instanz irgendwas zu tun

hat. Mir fällt jetzt tatsächlich

kein super tolles Beispiel

ein. Was ist denn der beste und fließende Static Method?

Was wäre das denn jetzt so als?

Ja, Static Method.

Die bekommt halt

einfach tatsächlich überhaupt nicht mal die Klasse.

Aber im Prinzip ist das nichts anderes,

außer dass sie nur nicht mal die Klasse bekommt.

Das heißt, sie könnte man auch draußen hinschreiben.

Genau.

Der einzige Unterschied bei der Static-Method ist halt,

dass sie dann im Namespace der Klasse

oder des Objekts aufrufbar ist oder so.

Ja, was ist jetzt in dem Vergleich eine Static-Method?

Okay.

Ja, also Static-Method

bekommt gar kein

automatisches Argument

mit, sozusagen.

Also das wäre dann die reine,

wäre quasi wie eine Funktion, ja. Also es ist

egal, ob man jetzt Static-Method

aufruft oder halt

eine Funktion

von draußen, genau.

Ah, richtig, jetzt

fällt mir doch wieder ein Beispiel ein zu Class-Method, wo das

wenn man jetzt

in Django zum Beispiel Modelle hat,

dann sind halt

viele Geschichten,

die jetzt ein Modell betreffen, die man von außen

aufrufen kann, ruft man halt auf der Klasse auf

und nicht auf einer Instanz, weil eine konkrete

Instanz ist ja zum Beispiel,

man hat ja die Daten für,

die Geschichten stehen halt

in der Datenbank

und jetzt eine konkrete Instanz

eines, also Django-Modelle

sind Klassen