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

vom Olli, der hat ja noch geschrieben,

Tipps für eine gute Syntax, dein Top 5 oder so.

Heute, heutzutage würde ich sagen, Black verwenden

und nicht mehr drüber nachdenken.

Also einfach Black, bumm.

Ja.

Vielleicht, also Namen vielleicht auch.

Namen sind natürlich, das ist 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 immer 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 gutem Kommentaren.

Man sollte eher 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 was schreibt,

dran denken, dass das,

wenn das jemand liest,

dann halt verständlich sein sollte, weil

Code viel öfter gelesen wird als geschrieben.

Ja.

Was ist mit sowas wie

List Comprehensions? Würdest du das bevorzugen,

gegenüber klassischen Loops.

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 einfacher 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 Comprehensions sehr, sehr schnell, sehr, sehr

unübersichtlich, wo ich dann halt irgendwie

stolz darauf war, so ein Statement hingekriegt zu haben.

Einer Zeile, Goldgolf.

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

der das

verstehen muss und das unter einem gewissen

Zeitdruck tut, dann

würde der sich wahrscheinlich irgendwie

Rot vor Rot.

Spaß zur Ärger.

Da gibt es

das Remote Strangulation Protocol,

wie zu 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-man-pages oder die

sysadmin-recovery

gab es in Newsgroup

und dann

ASR, alt sysadmin-recovery

das war die Newsgroup und dann gab es die

ASR-man-pages und Tools

ich glaube, wenn man

man-asr sagt oder man-knife

oder man-snip 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

ist da X.

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 irgendwie lustig. Und da gab es auch Protokolle und eines der Protokolle in dem Zusammenhang ist halt das RSTP, Remote Strangulation Protokoll über Fernverbindungen.

Sehr gut, 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 ein bisschen Syntax haben wir gemacht. 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 Fullstack in Python

geht gar nicht, weil man kein Frontend kann. 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, das heißt, JavaScript braucht ihr, wenn ihr Full-Tag

machen wollt. Und mit 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

die anderen Sachen wie Data und Backend so gut kann.

Naja, also wenn du eine Webseite machst, hast du

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-Version 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 ja so ein paar

Framework, ne? Grid, Materialize,

so. Naja, also ohne

JavaScript. Aber das ist ja was anderes. Ja, also Fullstack geht

gar nicht nur mit Python.

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, das wird dann JavaScript, weil das natürlich auch

gewisse Vorteile bringt. Du kannst

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.

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.

Also die Prinzipien, die man sich darauf 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, 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. Ja, das ist sozusagen einfach nur die

Art, wie man

relativ minimalistischer

Konsens darüber,

wie man Python-Code formatieren sollte

vielleicht.

Nee, wer macht das nicht, dann kommt hier in die

Python-Hölle. 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 darunter 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 Einzel 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 der, ich kann mal so 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 entziehend,

dass wir nur 89 Zeichen auf dem Bildschirm haben.

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.

es gibt natürlich, oder ich weiß nicht...

Ja, die alten, aber nur die neuen.

Weiß ich nicht, ob es dann...

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.

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.

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

Über die Konsole, über meine Shell.

Hast du dich mal an eine Konsole gestellt,

an einem Rechenzentrum, 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 und

wenn, dann sieht man da halt, muss man kurz drauf 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 Zeichen deswegen, weil man halt noch

eins braucht für einen Zeilenumbruch.

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 unheimlich und hässlich, einige Sachen.

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

das ganz komisch rum irgendwie und die

anderen darunter sehen

nicht so aus. Das ist irgendwie komisch.

Naja.

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,

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 empfinden das Rad nochmal von vorn.

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

Also die Grundlagen zu verstehen, ist gar nicht so schlicht.

Und hat man irgendwann nicht

kein mehr, der versteht, wie es irgendwann mal gebaut

worden ist, sondern 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.

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

man ist dann auch so,

wie meinte ich, über Django 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, das ist,

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, Parkway-Resonierung muss immer stimmen

und genau in 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 irgendeinem, ja.

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

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, wird halt 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 heute 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,

es ist halt ein, steht das

alles so ein bisschen auf tönernen Füßen.

Es 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. Ja, wenn man halt das Gebäude

und den Palast aus der Samtgrube baut, man kann tatsächlich noch ein paar

Stahlträger einziehen, das dann zu tun hat, könnte der Palast

nicht mehr halten. Ja, 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

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, was man auch vielleicht achten muss.

Also, falls ihr noch Fragen habt, die ich nicht beantwortet hatte, schreibt uns

wieder, wie immer, hallo at pythonpodcast.de

Wofür ist die

InitPy?

Das ist eine gute Frage.

Ja, man braucht das irgendwie,

damit es ein

Paket ist.

Ein Modul, wo es

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.

Interessante Frage 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 Foldername

oder sowas und wenn da eine Inispy drin ist, dann

kann man die Module, die da drin sind, einfach

aufrufen mit einem

Import-Teil und dann kann man

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 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, 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 Double Underscore, eigentlich auch nicht wirklich.

Also ich habe zum Beispiel diese internen Variablen

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 umfassen, fast, meine Klasse

nicht. Alles, was man selber schreibt,

machen immer anders, bevor damit eigentlich niemand anderes

anfasst. Nee, nee, 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

gecashten 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 eine Underscore irgendwie

Attribut ab. Underscore Cache.

Ja, oder Underscore

dieses, 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, ich denke, 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's

ja meistens ein öffentliches

Attribut, was man

benutzen kann und dann kann die Klasse das intern

handeln, wie sie das integriert.

Was ist denn überhaupt eine API?

Ja,

im Grunde eine Schnittstelle,

die Schnittstelle zu irgendwas.

Das gibt's 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ß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 wäre 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.

Was ist eine private und eine globale

Variable und was ist der Unterschied und wofür braucht man

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

Anfängertagen ganz oft so, dass ich irgendwie mir dachte

so ja, 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 die eigentlich

die Variablen immer privat. Nein, nein, nein,

nee, das ist eine Verwechslung, also du meinst

lokal und global.

Privat und öffentlich, das ist

halt genau diese Geschichte mit dem Double Undersquad.

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, dass das total nicht so backrest ist.

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.

Jaja, kann man

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

durchaus

praktische Anwendungsfälle

hat.

Ist jetzt nicht unbedingt immer so gut. Also es kommt halt

darauf an, was man damit machen möchte.

Man muss das

halt explizit halt dann als

global markieren, wenn man das tun möchte. Und dann gibt es

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

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

Ja.

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

überhaupt hinter Objektorientierter Programmierung,

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

irgendwie 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 Single nehmen,

beziehungsweise in Python eher Borg-Pattern.

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

Ein Singleton-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 in einem Spiel die Spielfigur

oder so, die dann bestimmte Eigenschaften hat,

eben sowas wie Lebensenergie oder so,

wenn ich garantieren möchte, dass alle,

die damit interagieren, immer die gleiche Instanz sehen.

Dass ich halt den nicht, weil es gibt nur einen

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

Naja, das ist, nee,

eigentlich, also so, weil

dann kommen wir zum Borg-Python, so wird das üblicherweise dann in Python

implementiert, ist, man macht

es einfach so, dass

jetzt muss ich mal,

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

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, bei ursprünglichen Singleton-Beschreibungen

ist es so, das wird einfach immer die gleiche Instanz returnt,

wenn man halt die...

Also das heißt nie überschreiben.

Das würde halt bedeuten, wenn es schon ein anderes gibt,

dann returnt es halt das.

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

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 und nicht, 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

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.

Was ist überhaupt State?

Das, was du

speichern musst, was sich

irgendwie ändert.

Der Status.

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

Datenbank.

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 erst die Daten anfragen oder so was.

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

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 deine 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 so das, was

dahinter steckt. Die interessante Frage ist, wie

verwaltet man diesen State?

sozusagen. Und

naiv

wäre halt, man hat

halt zum Beispiel, Held da ist halt in irgendwelchen

globalen Variablen. Man hat halt eine Liste,

die ist halt global,

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 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, da 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, 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, sozusagen, 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

irgendwelche Anarchoid 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 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 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 da 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

irgendwie einer Klasse.

Also

in einer Klasse definiert man sozusagen

irgendwie, ja,

eben eine

Zusammenfassung von irgendwie 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 sag nicht so besonders an von dem Brot, der irgendeine

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

Ja. Die nächste Frage

war, was ist Self? Self ist immer

das Objekt selbst, also wenn man in dem Objekt

auch eine, ist eine Konvention sozusagen, 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 ein

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

das

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, also wir müssen noch gleich

darüber sprechen, was ein Dekorator ist,

aber es gibt drei Dekoratoren, die Python

verwendet, die da immer so drüber

stehen. Static Method, Class Method

und

Property. Über Property hattest du eben auch schon.

Was ist denn jetzt da irgendwie

so der kleine

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

ist halt eine

eine

Methode, die eben nicht eine konkrete

Instanz, das heißt da fehlt auch

Self bei der, 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.

Das ist auch irgendwie, man kann das dann noch ein Stückchen

weitertreiben, auch dann mit dem Meta-Klassenanschluss.

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.

Ja, okay.

Ja, okay.