Transkript: PP01 - Die erste Sendung

Ja, hallo liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast.

Allererste Folge, allererste Episode.

Wir wollen euch heute ein bisschen führen und folgende Fragen beantworten.

Was machen wir eigentlich und warum?

Wie finde ich einen Einstieg in Python?

Also, wenn ich Anfänger bin, wie kann ich damit anfangen?

Und geben ein paar Anfänger-Tipps.

Und dann wollen wir noch ein bisschen erklären, wie Python funktioniert, ein paar Mythen über Python klären und so weiter.

Wenn ihr Fragen, Anmerkungen zu dem Podcast habt, Kommentare, alles was Gutes, was Schlechtes, dann sendet doch einfach eine E-Mail an hallo.pythonpodcast.de.

Und ja, links und zusätzliche Shownotes zur Sendung findet ihr natürlich in den Shownotes.

Ja, was machen wir eigentlich?

Kleine Einführung.

Ja, genau, vielleicht können wir uns einfach kurz uns vorstellen oder so, dass wir.

Ja, also wir

sind auf jeden Fall Düsseldorf aus dem wunderschönen Wintergarten von Jochen, den ihr gerade kurz gehört habt.

Wer sind wir denn?

Hallo Jochen.

Hallo Dominik, genau.

Also ja, mein Name ist Jochen, der die wirklich wunderschöne Anmoderation gerade kam von Dominik.

Und genau, ja, wir benutzen beide Python und ich höre auch sehr viele Podcasts und im englischsprachigen Raum gibt es da durchaus einige ganz gute Podcasts, die man da hören kann.

Aber jetzt so deutschsprachige gab es immer mal wieder Versuche, aber letztlich momentan, soweit ich weiß, jedenfalls keinen, der kontinuierlich aktualisiert wird.

Und ja, da dachte ich, dann gut, wenn es niemand macht, dann kann man das ja vielleicht einfach selbst mal probieren.

Und ja, dann habe ich so ein bisschen rumgefragt, ob es Leute gibt, die das vielleicht auch gerne machen würden.

Und ja, so sind wir dann zusammengekommen.

Und ja.

Wie kamst du zu Python?

Ja, das ist jetzt auch schon eine Weile her.

Irgendwann so 2000, Anfang der Nullerjahre sozusagen.

Ich war ursprünglich da eher so auf der auf der Pearl-Seite und dann war aber die, ich habe damals bei Web.de gearbeitet und die Firmensprache da war dann halt aber Python und dann wurde mir nahegelegt, auch ein paar Dinge, die ich da gemacht habe, irgendwie doch eher in Python zu machen als in Pearl.

Und dann habe ich das erst so ein bisschen gedacht, ja, naja gut, ob ich das wirklich toll finde, aber habe ich relativ schnell, war ich da ziemlich begeistert von Python und mache seitdem eigentlich nur noch Python und kein Pearl mehr.

Ich bin ja schon ein ziemlich alter Hase, wenn ich das so sage.

Ja, alter Sack, ja.

Genau, und ja, in unterschiedlichen Bereichen habe ich das jetzt schon so verwendet.

Und daher, ja, denke ich, ist es vielleicht auch ganz, kann ich da auch so ein bisschen was zu erzählen, was da so ein Python alles machen kann.

Bist du da Jochen, also ich gehe davon aus, dass du mir alles erklären kannst, was ich an tollen Fragen habe.

Ich möchte nämlich noch jede Menge wissen.

Genau, und wie bist du zu Python gekommen?

Ja, ich bin ein Zümmchen Rucki noch.

Ich bin jetzt insgesamt anderthalb Jahre irgendwie bei Python dabei und interessiere mich vor allem für, ach noch, vielleicht ein paar Buzzwords, Data Science und Digitalisierung, was man damit so machen kann.

Ich habe zwar auch schon damals in der Schule angefangen mit ein bisschen programmieren und war seit 1996 in der Internet AG.

Das war damals ganz besonders fancy und habe Webseiten da gebastelt und so einen Krams.

Hab dann aber einen ziemlich längeren Umweg gemacht über die Volkswirtschaftslehre, bis ich mich dann tatsächlich vor anderthalb Jahren dazu entschlossen habe, irgendwie nochmal einen ganz neuen Weg zu gehen.

Ein Umdrehen von vorne beginnen.

Und das zu tun, was mir wirklich am Herzen liegt.

Eigentlich wollte ich nur ein paar Daten analysieren und bin dann über ein Python-Tutorial gestolpert.

Und nach ungefähr 20 Minuten hat es mich dann irgendwie ziemlich vom Hocker gehauen und erwischt und ich wusste, dass es genau das ist, was ich in Zukunft machen will.

Und so bin ich bei Python gelandet.

Ja, von einfach mal nur ein paar Daten analysieren zu neuberuflicher quasi.

Oh, da klopft jemand an die Tür.

Es hat ein Spielzeug in der Hand.

Nun gut, ich hoffe, das stirbt nicht so weiter.

Ja, das ist auf jeden Fall ein schneller Einstieg gewesen, wenn das nach 20 Minuten schon geschnackelt hat.

Mätz ein bisschen länger gedauert, aber ja, das ist auf jeden Fall eine gute Sache, glaube ich.

Das war wirklich so.

Ich kam da rein, hab den ersten Code geschrieben, habe gedacht, ja genau, das wollte man sagen, das wollen wir machen.

Das stimmt.

Hammer.

Also liegt bestimmt auch vielleicht an der Einfachheit der Sprache, aber da kommen wir vielleicht ein bisschen später zu, was für Features Python alle hat.

Ja, vielleicht fangen wir nochmal an, warum machen wir das eigentlich?

Für wen ist denn dieser Podcast genau?

Was guckst du?

Für eigentlich jede, der sich für Python interessiert?

Ja, ich denke schon.

Also das ist halt auch so ein Ding, dass Python momentan halt sehr viel an Popularität gewinnt.

Also ich meine, das hat es schon immer getan.

Also es war schon immer recht populär, aber in letzter Zeit, gerade eben über Data Science und verwandte Themen, Machine Learning, Deep Learning, Dinge, die halt auch sonst sehr stark gehypt werden, ist Python sehr, sehr groß geworden.

Und mittlerweile hat es halt irgendwie Ausmaße angenommen, die dazu führen, dass es jetzt eine ganze Menge Leute gibt, die das gerne lernen würden oder sich dafür interessieren.

Und aber wenig Angebote sozusagen, die diese ganzen Leute irgendwie abzuholen.

Und ich denke, da können wir auf jeden Fall eine Menge Hörer ansprechen, sozusagen.

Aber ich würde das nicht unbedingt auf Anfänger beschränken, sondern einfach mal so quer durch alle größeren Themen oder so, die es gibt.

Wir hatten uns ja auch schon so ein bisschen Gedanken zu gemacht, was man da alles mal, worüber man, über welche Dinge man mal so eine Sendung machen könnte.

Und da haben wir auf jeden Fall genug Stoff zu senden und da können wir auch gerne mal so richtig fies ins Detail gehen.

Ja, genau.

Also ich glaube, bevor wir euch erzählen, was wir heute denn genauso machen, wir haben ja einen kleinen Einschild schon gegeben, gibt es tatsächlich diese ganzen vielfältigen Python.

Und wir wollen uns tatsächlich in mehreren Episoden das ganz interessante mal so ein bisschen berichten.

Über Django, über Datenbanken, über Python Performance, über Machine Learning und ein bisschen Data Science, MicroPython.

Es gibt ziemlich einiges, was wir jetzt hier auf dem Titel haben.

Könnte also auch ein bisschen gespannt sein, was wir es auch so machen.

Ja, was machen wir heute?

Das ist der Einstieg in Python.

Genau, einfach mal so eine Übersicht.

Genau, und dazu haben wir vielleicht erstmal ein paar kleine Fakten über die Geschichte.

Dann kann Jochen bestimmt noch viel mehr zu erzählen als ich.

Aber soweit ich weiß, hat Guido van Rosshom die Sprache entwickelt in den frühen 90ern.

Und zwar aus Amsterdam das heraus entwickelt.

Ja, also ist schon gute, wie lange?

Fast 30 Jahre alt, so tatsächlich.

Würde man gar nicht denken.

Python 3, das wir alle nutzen, bis seit 2008.

Und falls irgendwelche Nafragen kommen, ja, wir verwenden nur noch Python 3.

Ich glaube, das hat sich mittlerweile so eingebürgert.

Die neueste Version ist jetzt erst im Oktober erschienen, 3.7.1.

Und für nächsten Herbst ist glaube ich 3.8 geplant.

Also wir sind im Jahr 2018 für alle Menschen, die das irgendwann sprechen.

Ja, also Jochen, im Laufe Jahre hat ja ziemlich viel getan in der Sprache, oder?

Ja, wobei erstaunlich viele Dinge auch recht ähnlich geblieben sind.

Also ich meine, das ist halt auch möglicherweise einer der Unterschiede zu Sprachen wie, jetzt sehen wir mal, JavaScript oder so, wo sich halt in letzter Zeit sehr viel getan hat.

Und man dann immer, also ich mache in letzter Zeit auch irgendwie ganz schön viel JavaScript und oft muss ich dann, wenn ich jetzt irgendwas machen, so wie iteriert man denn jetzt nochmal über irgendwie quasi die Keys und die Values irgendwie in einem Hash oder so.

Wenn man danach guckt, dann findet man halt zu jedem Jahr quasi und zu jeder neuen ECMA-Skript-Version eine andere Art, wie man das am besten jetzt tun sollte.

Und da ist Python eigentlich sehr, sehr stabil geblieben.

Das ist heute noch, ja gut, da haben sich auch an der Stelle hat sich auch tatsächlich was geändert, aber sehr moderat und mehr oder weniger so Vorschleifen.

Das ist halt von Anfang an so, wie es jetzt heute auch noch ist.

Also seit 30 Jahren im Grunde nicht großartig geändert, wobei es da auch nicht so wirklich Bedarf gibt für eine Änderung, weil es war einfach von Anfang an, dann hat es quasi gefragt.

Das ist ja auch ein paar implementiert.

Ja, ich glaube, ja genau, 1991 ist das irgendwie gestartet und ich weiß gar nicht, ob ich da so wahnsinnig viel zu erzählen kann, weil damals war ich auch noch nicht dabei.

Das habe ich auch alles nicht so richtig auf dem Schirm, was da passiert ist.

Ich habe irgendwann angefangen, also die erste Python-Version, an die ich mich erinnern kann, mit der ich irgendwie Dinge gemacht habe, war so, glaube ich, 1.5.2 oder so.

Das muss irgendwann Ende der 90er gewesen sein.

Habe ich aber kaum mit Python, also da habe ich nicht wirklich Python gemacht, um Python zu programmieren, sondern ich habe es halt verwendet in irgendwelchen Skripten und so.

Oder irgendwelche Skripte angepasst und dann später so wirklich angefangen, damit größere Dinge zu programmieren.

Habe ich glaube mit Python 2.1 oder so.

Das war so, das war die Version, in der ich die erste größere Geschichte geschrieben habe.

Was würdest du sagen, war so der größte Unterschied zu heute?

Der Umfang der Standardbibliothek?

Ja, nee, ja, natürlich.

Also da ist einiges dazugekommen, aber das ist gar nicht so.

Also was halt, ja, so diverse Sprachfeatures, also Generatoren, ich glaube, die kamen irgendwie mit 2.2 oder so.

Das ist heute doch etwas, was man viel mehr benutzt, als man das damals getan hat.

Überhaupt, ja, diverse Keywords Yield, aber ja, das stimmt, aber das ist auch schon relativ lange da.

Also ich weiß nicht, wann 2.2 rauskam, müsste irgendwann 2002-3 irgendwann gewesen sein oder so.

Was heute eine große Rolle spielt und damals war das halt alles noch gar nicht da, ist alles, was irgendwie mit Async.io oder irgendwie ja.

Und wann kann das anfangen?

Version 3 erst?

Nein, das

ist die Syntax dafür, also das ist jetzt erst ein 3.5, glaube ich, mit dazugekommen.

Und es hat sich auch nochmal was zu 3.6 geändert.

Gab es da vorher ein externes Modul für?

Ja, es gab schon immer irgendwie externe Module, mit denen man solche Dinge machen konnte, sowas wie Twisted oder G-Event, habe ich auch eine ganze Zeit lang verwendet.

Ist auch toll, aber das Problem ist, dass man ja quasi, wenn man dann auf eine dieser Bibliotheken aufsetzt, halt in seiner eigenen Welt mehr oder weniger gefangen ist.

Und wenn jetzt jemand anders was geschrieben hat, das auf Twisted, ganz viele Leute haben Twisted halt als Basisbibliothek für ihre Netzwerkkram benutzt.

Aber man kann das dann halt nicht einfach so verwenden, weil wenn man jetzt selber auf was anderem aufsetzt, dann geht das halt alles nicht.

Und das war kein so wirklich schöner Zustand.

Es war auch nicht total furchtbar, das ging alles.

Und man konnte irgendwie mit Threads konnte man auch eigentlich quasi das schon immer machen.

Irgendwie so I.O.

Multiplexen, das ist halt das, was man vor allen Dingen macht, wenn man jetzt irgendwie quasi so asynchronen Dinge tun will.

Aber so wirklich schön war das alles nie.

Und jetzt inzwischen ist es aber, gibt es da halt eine nette Syntax für und das ist eigentlich ganz toll und das machen ganz viele und genau, das war damals alles noch ganz weit entfernt.

Ja.

Dann, achso, auch damals, was dazu gekommen ist, New-Style Classes, das?

New Style Classes.

New Style Classes.

Die Klassen waren etwas anders davor und ja genau, wenn ich jetzt müsste ich nachlesen, was da genau die Unterschiede waren.

Ich glaube, also eigentlich weiß ich nur, dass man halt quasi dann immer nicht Doppelpunkt, also Leerzeichen, Klassenname, Doppelpunkt geschrieben hat, sondern irgendwie eine ganze Zeit lang hat man immer Klammer auf Object geschrieben, damit es halt von Object erbt und man Newsile-Classes automatisch verwendet, was man jetzt halt auch schon eine ganze Zeit lang nicht mehr tun muss.

Ich habe jede Klasse automatisch von Object dann, oder?

Ja, genau.

Und dann gibt es natürlich noch diverse Meta-Programmierungsgeschichten, Meta-Classes und so.

Ich weiß gar nicht, wann die dazugekommen sind.

Das gab es, glaube ich, am Anfang auch nicht.

Ja, dann, achso, auch eine neue Syntax, die sehr praktisch ist.

Es ist halt so, sind so so, also es gibt List-Comprehensions, glaube ich.

Die gab es auch nicht.

Seit wann?

Die gab es zwei 1,5 noch nicht.

Gab es zwar zwei, einzeln die, glaube ich, dazugekommen.

Also jedenfalls, als ich angefangen habe, war das so, dass das eine neue Geschichte, die dazugekommen ist.

Dann kam, glaube ich, mit, dann weiß ich ja nicht, wann die Generator-Expressions dazu kamen, wo man halt nicht eine List-Comprehension hat, sondern dann quasi runde Klammern schreibt und dann das Ganze ein Generator ist.

Das könnte sein, dass das erstmal zwei, vier war oder so.

Und jetzt gibt es auch irgendwie so Syntax für diktmäßige Objekte.

Also man kann halt auch geschweifte Klammer auf und dann V Doppelpunkt K vor K, V in Diktpunkt-Items sagen.

Und dann würde sich das.

Also kann man sich seine Diktioners generieren

umdrehen, ja, genau.

Und muss dafür nicht extra irgendwie nochmal dickt aufrufen oder so.

Ja, das ist jetzt, das ist aber dann relativ spät dazugekommen.

Ich glaube, das ist erst mit Python 2.3 oder äh, Python 3 dazugekommen jetzt.

Wofür nutzt man denn jetzt eigentlich Python heute?

Vielleicht machen wir das nochmal als Frage für unsere Hörer, die das so genau wissen wollen.

Genau, also am Anfang war es vor allen Dingen eine Skriptsprache zum Verbinden von irgendwelchen Systemen.

Man hat das halt so, ja, man nannte die Dinge auch Glue-Languages und so, weil man halt, weil es schön einfach ist, diverse andere, ja, in anderen Sprachen programmierte Libraries anzubinden und die dann halt irgendwie miteinander zu verbinden.

Hast du halt verschiedene Servermodule mit Python-Kleister zugeklebt?

Ja, irgendwie sowas wie, man hat eine, man hat Image Magic oder so, so eine Bibliothek, die jetzt auch Bildern irgendwas macht und hat dann halt irgendwelche Bindings, die das in Python verfügbar machen.

Und dann hat man irgendwie eine Bibliothek, die irgendwie Mails macht oder dann kann man irgendwie E-Mails mit Bildern oder so dann irgendwie verkluseln und dann irgendwie E-Mails mit Bildern drin verschicken oder sowas.

Solche Sachen hat man ja halt in Python vor allen Dingen gemacht.

Okay, das ist ja auch nicht.

Und man hat einmal eine E-Mail in der Hand und Python gibt dann ein Kleber, dass man ein E-Mail mit Bild.

Genau, ansonsten, wenn man jetzt, keine Ahnung, irgendeine Bibliothek hat, die in C geschrieben ist oder so, wenn man da jetzt irgendwie E-Mail-Support einbauen will oder irgendwie eine andere Bibliothek, die mal aus Adrum geschrieben ist, die einbinden will, das ist halt sehr schwierig.

Und mit Python kann man das alles sehr schön integrieren.

Also für sowas hat man es vor allen Dingen verwendet, aber auch für Webentwicklung von Anfang an eigentlich schon, soweit ich weiß.

Welche Frameworks haben wir der groß?

Also ich kenne ja zum Beispiel Flask, habe ich in einem Tutorial gedacht und natürlich Django.

Ja, die kamen allerdings noch?

Die kamen alle sehr viel später.

Also, sag mal so, es wurde zwar, also es wurde halt auch als CGI verwendet.

Es gab ganz früher.

Das ist schon fast ein bisschen Opa als hält vom Krieg-Sektionen.

Ja, bitte, deswegen sind wir hier.

Es gab das Common Gateway Interface, das war halt eine Methode, wie Web-Server sozusagen Skripte aufrufen konnten, die dann irgendwie, also am Anfang gab es nur, am Anfang waren statische Seiten, wo halt ein Webserver irgendwie eine Datei ausgeliefert hat.

HTML-Pur.

Ja.

Und das ist aber ein bisschen wenig, wenn man jetzt also sowas hat wie eine Webseite mit einem Gästebuch, sowas gibt es heute auch alles nicht mehr, aber damals war das halt so.

Da musste man das haben, muss man irgendwie einen Counter haben, der irgendwie.

Man hatte sein Gästebuch, wo man reingebließt.

Ich war bei dir im Internet.

Genau.

Ich habe da was reingeschrieben, ich habe es benutzt.

Ja, und das geht natürlich mit statischen Seiten irgendwie nicht.

Also wenn ich jetzt so ein Gästebuch habe und ich habe da ein Feld, wo ich irgendwas eingeben kann und dann soll das halt irgendwo gespeichert werden, dann muss sozusagen der Text, der da in dieses Feld geschrieben wurde, irgendwie durch ein Skript durch und das musst du es irgendwo hinschreiben.

Und damit solche dynamischen Sachen gehen, gibt es halt dieses, damit quasi irgendwie der Webserver mit einem Skript kommunizieren kann, dass dann halt irgendwie diesen Kram liest und wegschreibt, gibt es halt das Common Gateway-Interface und das hat das dann so gemacht, hat dann halt das Skript geschartet, also weggeforgt und dann irgendwie da per Umgebungsvariablen irgendwie die Daten übertragen.

Das geht, aber es ist halt furchtbar langsam und alles nicht so richtig schön.

Aber so war das damals.

Und da, ich erinnere mich auch, dass man dadurcha Python-Skripte, also meistens hat man Perl verwendet, aber das ging auch mit Python schon.

Hatte halt so ein bisschen das Problem, dass die meisten Hoster irgendwie kein Python installiert hatten und deswegen man keine Python-Skripte als CGI-Skripte irgendwie da angeben konnte.

Aber musste man selber hosten, wenn man Python hatte.

Ja, ja, genau, genau.

Insofern war das halt nicht so populär.

Ja, die ganzen anderen Geschichten, es kam alles viel schön.

Was war denn so das erste Framework, was so mit hochkam, wo man die ersten Seiten vernünftig mit.

Das gab es für Python, gab es da eigentlich fast nichts.

Also es gab also, da gab es eigentlich nur PHP.

Also da gab es Mod PHP für ein Apache.

Es gab auch ein Mod Python, aber das war ziemlich furchtbar.

Das habe ich mal versucht zu verwenden.

Oder ich habe es sogar eine ganze Zeit lang verwendet, aber das war alles ziemlich scheußlich.

Hatte Memory Leaks, war alles irgendwie ätzend, dauern so komische Sachen passiert.

Also Memory Leak heißt dann der Server shut up, wenn die Leute benutzen, einfach wenn Leute auf dem

Server sind.

Man weiß nicht genau warum und irgendwann ist er halt weg und dann muss man halt nachgucken, was da schief gelaufen ist.

Alles nicht so schön.

Das Mod PHP war auch nicht so toll, aber das hat halt so schon irgendwie ganz gut funktioniert.

Und ja, das war so die, auch am Anfang der Nula ja war so die große Zeit des sogenannten Lamp-Stacks, so Linux, Apache, MySQL PHP.

PHP, genau.

Und das hat so halbwegs funktioniert.

Und ja, Python haben zwar Leute auch quasi als Web-Anwendung verwendet, aber dann immer.

Also ich glaube, das hat doch jetzt.

Das erste, was Leute tatsächlich da in Python gebaut haben, war Soap.

Soap.

Ja, oder Soapy, ich weiß gar nicht genau, wie man das ausspricht.

Das gibt es bis heute und das ist bis heute irgendwie eine ganz tolle Community irgendwie.

Und da gab es dann auch so ein Content Management System oder irgendwie so ein Ding, was drauf aufgesetzt hat, das nannte sich Plone.

Also daran erinnere ich mich auch.

Das muss irgendwie 2004 gewesen sein, dass ich das zum ersten Mal ausprobiert habe.

Das war alles sehr nett.

Es war nur furchtbar langsam, aber ansonsten war es alles sehr schick.

Und ich glaube, das waren so die ersten, die so irgendwie komplexere Webanwendungen in Python möglich gemacht haben.

Wie gesagt, manche Leute benutzen das bis heute.

Dieses Projekt hat ein großes Problem mit dem Umstieg von Python 2 auf Python 3.

Ich glaube, da ist noch eine ganze Menge Code nicht umgestellt.

Und ja, jetzt am 1.

Januar 2020 läuft ja irgendwie der Support für Python 2 aus.

Ja, das ist nicht mehr so wirklich viel Zeit.

Und keine Ahnung.

Also vielleicht haben sie das auch mittlerweile geschafft, dass sie da umgestiegen sind, aber ja, das ist ein bisschen blöd für dieses Projekt.

Ja, aber das waren so die ersten, genau.

Und dann kamen halt mehr dazu, als es eine standardisierte, schöne Schnittstelle gab.

Also es gab dann diverse Schnittstellen, die auch besser funktioniert haben als CGI, es gab Fast CGI.

Fast CGI?

Ja, genau.

Das war dann schneller.

Das war schneller, da musste der Server das Skript nicht forken, sondern da waren da schon so ein paar Skripte gepreforked.

Dann konnte man das irgendwie, dann wurden die Daten da halt irgendwie per Interprozesskommunikation irgendwie hingeschoben und das war alles deutlich besser.

Das ging halt dann relativ schnell.

Aber es war auch alles noch ziemlich hässlich.

Und es gibt dann, ich weiß nicht, wann das passiert ist.

Seitdem gibt es irgendwie Mod, gibt es halt Whisky sozusagen als Schnittstelle zwischen Webserver und Applikation.

Also sich das so halbwegs standardisiert hat.

Hört sich nach etwas ziemlich holzigem zu trinken an.

Ja, also wird aber BSGI geschrieben.

Es wird nur lecker ausgesprochen.

Es ist nicht so lecker, wenn man es sich dann tatsächlich anguckt, aber genau.

Und damit ist dann eigentlich auch schon eine große Zeit von Apache als Webserver irgendwie so ein bisschen vorbei.

Da gibt es dann tauchen dann plötzlich so andere Server auf, die man halt dann als Applikationsserver häufig verwendet.

Beziehungsweise man trennt dann eigentlich zwischen Applikationsservern und irgendwie den Servern, die halt statisch Files nach außen ausliefern oder die so ein bisschen Reverse-Proxy halt vor den Applikationsservern sind.

Da nimmt man meistens auch nicht Apache, sondern dann sowas wie Nginx oder am Anfang gab es dann Light HTTPD und so.

Und heute vielleicht für heute nimmt man dann irgendwie sowas wie, na, wie heißt er noch?

CADI.

Ein Go geschriebener Web-Server, der sich schön auch mit Let's Encrypt irgendwie verbindet.

Und dann hat man halt irgendwie ordentliches SSL nach draußen, irgendwie automatisch, muss er nicht irgendwie, also bei Nginx, also ich habe mich ja beschäftigt, Nginx so weit zu kriegen, dass es halt irgendwie beim Test von SSL-Labs irgendwie überall grün und okay ist.

Und es hat mich irgendwie so zwei Tage gekostet und war irgendwie echt aufwendig.

Und bei Caddy geht das einfach so.

Muss man.

Okay, das ist schon super.

Also den verwende ich jetzt mittlerweile auch meistens vor den Applikationsservern.

Applikationsserver sind sowas wie GUnicorn, den verwende ich meistens, oder Mü VSGI oder UBSGI heißt ein anderer.

Oder Werkzeug oder da gibt es einige, die man halt verwenden kann.

Und die sind sozusagen dafür zuständig, dass halt die Applikation läuft und die Requests, die halt sozusagen nur von der Applikation beantwortet werden können.

Die gehen halt dann an dieses Server und die rufen dann halt eben quasi die Applikation mit dem entsprechenden API auf.

Also ich wollte jetzt gar nichts unterbrechen.

Ich finde das finde ich auch super interessant.

Ich glaube, wir machen vielleicht sogar eine eigene Web-Folge.

Wir sind ja heute, das wollte ich nicht vergessen, ich hoffe, die Anfänger sind jetzt nicht alle schon ausgestiegen, in der Anfängerfolge.

Da müssen wir noch ein bisschen mehr eingehen darauf, welche Funktionen man mit Python vielleicht noch machen kann.

Also wir haben jetzt vielleicht einen kleinen Anstieg schon mal euch gegeben, was es so an coolen Möglichkeiten heute so gibt mit Python und Web-Frameworks.

Was machen wir noch?

Genau, das ist heute auch ein, ja genau, WebWeb ist ein wichtiger Teil.

Blue ist auch noch immer ein wichtiger Teil.

Ich habe jetzt letztens, also um vielleicht kurz Werbung zu machen für einen anderen, für einen englischsprachigen Python-Podcast, das war Talk Python to me, glaube ich.

Doch ja, Talk Python to me.

In der letzten Folge, da ging es um Python 3 bei Facebook.

Und da erzählt jemand, der halt Python bei Facebook irgendwie macht, dass die ganzen Backend-Systeme, die halt irgendwelche Services machen oder irgendwie Sachen hoch runterfahren, Sachen deployen, das ganze quasi Facebook-Management-Zeugs, das ist halt alles Python.

Also Frontend ist zwar PHP, aber alles, was sozusagen Services miteinander verbindet oder halt irgendwie interne Geschichten macht, das ist halt bei Facebook alles in Python.

Also auch YouTube ist ein Python oder so.

Ja, genau, YouTube ist ein bekannter.

NASA macht viele Sachen mit Python

habe ich.

NASA, ja.

Walt Disney zum Filme produzieren und.

Ja.

Pinterest auch ist, glaube ich, weiß nicht genau, ob die, die waren sogar Django irgendwie.

Aber auch halt Python hauptsächlich.

Instagram ist komplett Python eigentlich von der Web-Applikation her.

Also ja, das gibt auch durchaus im Frontend einige, die da Python verwenden, aber es ist halt im Grunde überall.

Und ja, also dieses Gluting ist auch immer noch eine sehr, sehr wichtige Geschichte.

Aber dann gibt es halt einen neuen Bereich seit einigen Jahren, der halt auch sehr, sehr populär geworden ist.

Das ist halt so ganze Data Science, Machine Learning Gebiet.

Daten Sensor, Datenerfassung.

Scientific Computing, dieser ganze Bereich.

Also das, was früher, was man früher mit MATLAB gemacht hat, würde ich sagen.

Ja, oder Mathematiker auch, Mathematiker hat ja dieses schöne Konzept entwickelt von diesen Notebooks.

Also das kennt man vielleicht, wenn man jetzt im wissenschaftlichen Bereich ein bisschen unterwegs war.

Es gibt so Labortagebücher oder so, man aufschreibt, was man irgendwie tut und so.

Python die Jupyter-Notebooks, die es gibt.

Genau, die gibt es in Python und bei Mathematik hatte das tatsächlich zuerst sozusagen dieses Feature, dass man halt solche Notebooks halt dann ausführen kann und dann halt nachvollziehen kann, was da passiert ist, weil wie man zu einem bestimmten Ergebnis gekommen ist.

Sehr, sehr gute Idee halt.

Hat sich nie so richtig durchgesetzt, weil Mathematiker ist halt proprietär und teuer und ist auch eine sehr exklusive Community irgendwie und hat die irgendwie nie so richtig abgehoben, obwohl es eigentlich schon eine sehr schicke Idee war und dann wurde die halt aufgegriffen von den Leuten, die irgendwie so ein Interpreter oder man nennt das irgendwie so REPL, weiß gar nicht wofür diese Abkürzung, also diese Shell, die man bekommt, wenn man jetzt Python eingibt.

Ja, ja, die haben halt sozusagen das da mit reingebaut und das nannte sich dann iPython Notebook.

Also iPython hatte schon einen ganzen Teil der Funktionen, die man dafür braucht, wenn man sowas implementieren will.

Und iPython Notebook hat dann halt quasi sozusagen die Ideen von diesen Mathematiker-Notebooks irgendwie aufgegriffen.

Und ja, das war ein toller Erfolg.

Man hat das dann auch für andere Sprachen gemacht, für R und für Jupyter, äh, für Julia.

Und dann war irgendwie klar, dass es halt iPython Notebook ein blöder Name dafür ist, weil wenn es halt nicht mehr Python ist, sondern auch andere sehen, dann wurde das halt unbedingt in Jupyter, wobei das halt nicht Jupiter wie der Planet geschrieben wird, sondern mit PY halt wie für Python, weil es Julia, Python, R quasi, also die drei Sprachen, die da halt hauptsächlich irgendwie verwenden.

Das sieht ja ganz schick aus, habe ich tatsächlich auch schon ein paar Mal gesehen.

Das kann man tolle Sachen mitmachen und auch live den Code direkt testen, aushören, was man damit macht.

Genau, genau.

Das ist halt super praktisch.

Das ist natürlich jetzt schwer, so das zu umschreiben, jemanden, der das nicht kennt, quasi warum das toll ist.

Es ist halt nur so, dass wir gerade bei so Spaß.

Na, ihr stellt euch vor, ihr könnt ein Buch lesen und habt ja irgendeine statistische Tabelle, die ihr anguckt und ihr könnt live da die Daten eintragen, ändern und auch im Schaubild verändert sich direkt mit den neuen Datensätzen das, was ihr da braucht und was ihr programmiert habt, der Algorithmus, um das darzustellen, könnt ihr direkt live sehen, was da passiert.

Ja, das ist eine der schönen Geschichten, aber was für mich vor allen Dingen, also ich mache auch viele Data Science-Geschichten, dass das für mich sozusagen das Top-Feature ist, ist halt irgendwie so viele der Schritte brauchen eine Menge Zeit.

Also wenn man große Datenmengen hat oder so, kann es sein, dass manchmal, wenn man irgendwas macht, dauert das halt eine Stunde.

Sozusagen, und dann hat man das Ergebnis, irgendeine Berechnung, genau, die man macht.

Man trainiert irgendein Modell oder so und das rechnet dann halt irgendwie so mal eine Stunde vor sich hin.

Und wenn man das jetzt alles in einem Skript hat, so wie man das normalerweise hat, jemand erzeugt dieses Modell, dann macht man da irgendwelche Evaluationen drauf, dann visualisiert man das Ganze, dann macht man da irgendwelche Tests oder macht man möglichen.

Man kann erstmal die ganze Arbeitsschrittkette durchgehen, bis man wieder an dem Punkt ist, den man gerade geändert hat.

Genau, man kann das natürlich dann irgendwie schlau cachen, das habe ich früher dann so gemacht.

Da habe ich dann irgendwie Dekoratoren benutzt, die dann halt den Kram immer irgendwo hingeschrieben haben in ein Verzeichnis und dann sozusagen immer wieder nur Remap die Arrays, die dabei entstehen, halt wieder zurück.

Aber das ist halt alles nicht so.

Also, das kann man machen, aber diesen Aufwand treibt man auch nur dann, wenn man sich sicher ist, dass man das wirklich braucht und dann verändern will.

Und jetzt möchte man halt am Schluss dieser Kette, die halt irgendwas erzeugt, eine Funktion schreiben, die irgendwas mit den Daten macht.

Und jetzt baut man da irgendeinen blöden Fehler rein oder so.

Und das passiert einem tatsächlich, wenn man das jetzt so, wie ich das auch früher gemacht habe, passiert einem das relativ häufig, dass man dann halt den Fall hat, dass es irgendwas schief geht.

Man sieht einen Trace weg und denkt sich schon so, oh nein, was für ein blöder Fehler.

Und das Ergebnis von irgendwie einer Stunde Berechnung oder so ist weg und man muss halt im Grunde nochmal eine Stunde warten.

Aber selbst wenn man nur ein paar Minuten warten muss, ist es halt voll blöd.

Man ändert irgendwas, probiert es aus.

Zyklus halt, wenn da viel Latenze drin ist, dann wird man sehr langsam.

Und dieses Problem löst Jupyter eigentlich, lösen die Jupyter-Notebooks komplett, weil da ist es halt so, dass man jede Zelle getrennt ausführen kann.

Und wenn man jetzt eine Funktion geschrieben hat, die einen Fehler enthält und führt die halt aus auf den Daten, die man jetzt da irgendwie eine Stunde lang berechnet hat.

Und es geht schief, dann ändert man die Funktion, führt sie nochmal aus und alles ist gut.

Und das Ergebnis ist halt nicht weg.

Und das ist halt so.

Ja, das ist halt gut.

Gerade wenn man sowas arbeiten möchte, ist das, glaube ich.

Genau, und das macht einen halt viel, viel schneller und das ist das ist halt total toll.

Also ist das auch für Anfänger sehr gut geeignet, musst du sagen, auch zum Lernen der Sprache, ja.

Ja, ja, weil es halt so schön interaktiv ist.

Man kann einfach eine ganze Menge ausprobieren, ohne dass man jetzt irgendwie Editor lernen muss und ohne dass man irgendwie quasi wissen muss.

Also das, ja, man kann halt einfach direkt was ausprobieren, wenn es halt schief geht, dann ändert man die Zelle und führt sie nochmal aus und dann ist es okay.

Ja, das bringt es, glaube ich, direkt zu unseren Anfänger-Tipps.

Ich glaube, das ist ja gar nicht so schlecht.

Also wenn ihr Fragen habt, natürlich direkt irgendwie an hallo.pythonpodcast.de einfach stellen.

Dann erklären wir euch auch alles, was ihr gerade vielleicht noch nicht verstanden habt oder was euch ein bisschen zu schnell ging.

Gleich mit ein paar Tipps anfangen.

Ich glaube, also ganz wichtig ist natürlich die offizielle Dokumentation.

Aussage des Tools zum Lesen.

Ich glaube, da findet man so die meisten Erklärungen für die Standardbibliothek, wie das alles so funktioniert, außerhalb von den Tutorials, die es jetzt gibt.

Ich habe zum Beispiel mit Python the Hardway angefangen und das Buch von Seltor gelesen.

War ein ganz guter Einstieg.

Wenn man sich da so durcharbeitet, kommt man relativ tief in die Materie rein.

Es gibt noch Automated Boarding Stuff with Python.

Geht es auch auf Deutsch ein Buchtuch, das kostet dann leider Geld, ansonsten ist das ein kostenlos Tutorial.

Ja, die ganzen Tutorials gibt es sonst, weiß ich nicht, auf Datacam, Udemy, Udacity, unzählige Kostenlose.

Ja, du hast ja gerade gesagt, anfangen vielleicht mit Jupyter Notebook oder auch einem einfachen Text-Editor.

Also ich kann jetzt nicht empfehlen, direkt mit einer großen Entwicklungsumgebung zu starten.

Das hält dann erstmal so ein bisschen auf.

Gibt ja dann irgendwann später ganz viele tolle Editoren.

PyCharm, Idle, Pause Code, VI, Atom, MX.

Was benutzt du?

VI.

Ja, das ist, ich benutze aber auch PyCharm zum Beispiel mittlerweile, weil ich mich nervt, dass das halt doch relativ langsam ist.

Und ja, das ist halt, das ist mal über diesen, also eigentlich ist das schön, also diese ganzen IntelliJ-EDEs, das ist alles schon sehr nett gemacht, die können auch sehr viel, aber die reagieren nicht so instantan.

Also es ist immer, wenn man irgendwo drauf drückt oder so, dann muss man erstmal zu langsam.

Es ist einfach zu langsam.

Es ist nicht so, es fühlt sich halt nicht so snappy irgendwie ordentlich an, wie sich halt so ein Profi-Werkzeug anfühlen sollte, sondern es fühlt sich halt immer so an wie, keine Ahnung, wie diese, die, weiß ich nicht, also ich meine, gut, das ist ein böser Vergleich, aber wenn so ein Fahrkartenautomat bei der Bahn steht und drückt er drauf.

Ich kann nicht gegentreten, bevor da irgendwas kommt.

Und dann passiert einfach nichts und dann drückt man nochmal drauf, aber dann macht es irgendwie so.

Hättet ihr, wenn ihr euch ja gerade so neuen Schokoriegel aus dem Automaten ziehen wollt und dann bleibt er irgendwo da oben hängen.

Ja, und das ist halt, das ist halt schon sehr so ein bisschen nervtötend und deswegen benutze ich das eigentlich nicht so gern.

Obwohl manche Features halt durchaus so nett sind, dass ich es halt auch immer wieder verwende, aber wenn ich BI verwenden kann, dann verwende ich eigentlich der.

Also ich wim, da hat sich ja auch einiges getan.

Wie hast du denn Python gelernt?

Hast du da irgendwie Tutorials gemacht oder war es da direkt dran?

War das so basics, dass man selber beigen musste?

Nee, ja, aber damals gab nicht so viele Bücher damals.

Es gab ein paar.

Die waren aber auch alle nicht so wirklich hilfreich.

Also das ist auch doch, es gab ein Buch, das war hilfreich.

Ich weiß aber nicht, ob das immer noch eine gute Empfehlung ist, das war das Python Cookbook.

Das war ganz gut.

Ansonsten waren die meisten Bücher nicht so toll.

Und ja, wie habe ich es gelernt?

Also ich hatte halt das Glück, dass ich da neben jemandem gesessen hatte, der das schon konnte.

Und der mir das dann gesagt hat.

Ja, das war etwas Luxuriöses.

Das war relativ praktisch.

Ja, da kann ich euch tatsächlich auch empfehlen.

Also versucht nicht mit einem stillen Kämmerlein zu sitzen und euch selber durch den Kram zu quälen.

Also es geht bedeutend schneller und ihr kommt auch bedeutend schneller weiter, wenn ihr tatsächlich jemanden habt, der euch so ein bisschen zeigt, wie das Ganze geht.

Danke noch.

Deswegen sitze ich hier und stelle dir die ganzen doofen Fragen.

Ja, also genau, man könnte auch zu Meetups durchaus gehen, sich da mit Leuten austauschen hilft.

Die tägliche Arbeit musste man natürlich dann trotzdem machen, aber ich glaube, mittlerweile kommt man da ganz gut angeleitet auch in die Essen-eigenen Projekte so rein.

Ja, wie funktioniert Python eigentlich?

Also was ist das Ding?

Also wo kann man das machen?

Also ich habe jetzt hier zum Beispiel auf meinem großen Zettel stehen, simple Prototyping kann man machen und recht umfangreiche Bibliotheken und

ja, also bei Python selbst ist halt eine.

Einfach.

Ja, ist das einfach?

Es ist es, es ist ziemlich, es ist, ja, es verbindet halt zwei Dinge, die eigentlich ein bisschen widersprechen.

Es ist halt sehr einfach und es ist halt trotzdem sehr mächtig.

Das macht es halt sehr schön.

Auf der anderen Seite bedeutet das halt, dass es nicht so einfach ist, das irgendwie in Binärcode zu kompilieren oder so.

Also das ist halt mit einer Sprache, die halt wesentlich einfacher sozusagen ist, ist das halt simpler.

Also wenn man C nimmt, C kann man, also mehr oder weniger Makro-Assembler, da kann man das dafür einen Compiler zu sprechen.

Aber muss man denn überhaupt etwas in Binärcode kompilieren?

Also fragen wir.

Wenn es ein Computer direkt ausführen können soll, dann muss das irgendwie Maschinencode sein.

Nullen und Einsen.

Genau.

Genau, genau.

Wenn das so etwas ist, dann kann es halt direkt ausgeführt werden.

Also die meisten Programme, die man so kennt, sind das halt auch.

Also so wie früher, wenn ich mir das so vorstelle, da hat man ja die ganzen großen Rechner gehabt, die Lochkarten gelesen haben für Nullen und Einsen.

Das braucht der Computer heute noch, damit er versteht, was er da überhaupt machen muss.

Ja, genau.

Und dann läuft halt dieses Programm direkt irgendwie auf dem Prozessor und ja, aber das geht halt, das ist halt etwas, was dann nicht mehr geht mit Python, weil für Python-Compiler zu schreiben, ist halt dann nicht mehr so einfach.

Oder eigentlich immer so ziemlich unmöglich, weil es halt alles dynamisch und zur Laufzeit kann sich eine Menge ändern.

Das geht halt nicht so richtig.

Das ist halt dann der Preis, den man zahlt, dass man es nicht mehr kompilieren kann.

Es wird dann halt interpretiert.

Also es wird schon so ein bisschen verändert.

Es wird in einen Bytecode verwandelt und der Bytecode wird dann interpretiert von einer virtuellen Maschine.

Das sind dann die Py-C-Dateien, die man findet, nachdem man irgendwas gelaufen kann.

Genau, genau.

Also C ist das, was dann denen das Ganze benutzt, um das dann für die Maschine schreibt, lesbar zu machen.

Ja, ne, aber für die Maschine ist das nicht lesbar.

Also man braucht immer noch den Python-Interpreter, der das dann ausführen kann.

Also, ja, genau.

Also der Python-Interpreter ist halt genau diese bestimmte Maschine und genau, der kann das dann halt ausführen.

Und ja, das hat dann auch so einige andere Nachteile.

Also das macht es halt auch schwer, Sachen zu installieren oder so, weil man kann jetzt nicht einfach irgendwo ein Binary runterladen oder schon.

Ich glaube, wieso?

Es gibt auch PIP.

Ja, genau.

Dann muss man eben zu so Paketmanagern greifen, mit denen man irgendwelche Dinge installieren kann.

Aber man kann halt jetzt nicht irgendwie auf dem USB-Stick jemandem irgendwie Python-Programm geben und der startet das dann halt.

Wenn ich das richtig verstanden habe, PIP ist halt dieser Paketmanager, der über die Seite PyPy oder wie ist das, über den Serverprogramm läuft und dann da Pakete installiert, die andere dort bereitgestellt haben, die schon damit veröffentlicht sind.

Das heißt, wenn ihr eure eigenen Pakete baut, müsst ihr die entweder so veröffentlichen oder tatsächlich ex in der Bibliotheken nehmen, um Installar zu bauen oder sowas.

Genau, also gibt es auch, es gibt Pi-Installer, es gibt diverse Geschichten, die das dann halt versuchen, irgendwie in Binary zu packen.

Und das funktioniert auch manchmal.

Du kannst kurz zwei, drei Installer nennen, die man versucht für verschiedene Systeme, einmal vielleicht für Linux, für OS oder für Windows, oder?

Das ist die Nachbarung, ich benutze das selber nie, daher.

Pi2X für Windows gibt es da irgendwie was?

Bei Linux braucht man es, glaube ich, nicht groß.

Nee, da gibt es glaube ich, ich weiß nicht,

baust du ein Paket, machst du Shell-Install-Setup, Pi, was?

Nee, aber da gibt es auch, also unter Linux gibt es auch so ein Ding, was halt quasi den Interpreter mit reinpackt in Binary.

Kann sein, dass es Pi Installer ist.

Und das, wenn man so ein bisschen aufpasst, dann geht das sogar relativ, kriegt man den Interpreter relativ klein.

Also wenn man es einfach naiv macht, dann kann es sein, dass das irgendwie so 15 MB sind oder 10, ich weiß nicht genau.

Aber man kriegt auf irgendwie zwei, drei runter, wenn man das irgendwie, wenn man sich da ein bisschen Mühe gibt.

Und dann ist es eigentlich, ich meine, heutzutage ist das eigentlich sowieso alles nicht mehr so wild.

Dann ist es halt so, es gibt natürlich Leute, die sagen würden, wenn ich das mit C mache und dann gut, und nicht gegen die Lip C-Linke oder gegen die G-Lip C, sondern halt irgendwie so eine Diätlip C oder irgendwas anderes kleines.

Es hört mir gerade kurz wieder, Lib C-Lib Cleines, irgendwie, das sind die Standardbibliotheken und die C so bereitstellt für die viele, die dann das Ganze größer machen, wenn man das kompiliert.

Genau, da ist noch ein bisschen Standardbibliothek dabei, aber eigentlich wofür die da sind, ist die Kommunikation mit dem Kernel, mit dem Betriebssystem.

Und das kann man natürlich auch beliebig komplex gestalten, aber wenn man halt nur die ganz simplsten Dinge haben will, dann muss das nicht so groß sein, weil das Problem ist, es muss halt irgendwie dagegen gelingt sein, damit irgendwie der Prozess überhaupt irgendwas machen kann, wie Eingabe, Ausgabe und so.

Aber wenn man das schlau macht, dann kriegt man das halt auf, weiß ich nicht, ein paar hundert Byte oder so runter.

Und das ist natürlich was ganz anderes, als wenn ich jetzt irgendwie megabyte-weise Zeugs.

Das könnte auf

Mikrocontroller packen.

Ich glaube, man kriegt das sogar in so einen Bootsektor rein.

Wie ich habe so einen Bootsektor 512 Bytes oder sowas.

Also natürlich ist es nicht so klein, wie es gehen könnte, wenn man das wirklich drauf anlegt.

Und das wird auch nie gehen mit Python so richtig, aber heutzutage sind ja auch ein paar Megabyte eigentlich nicht mehr wirklich viel.

Luxus.

Früher war das schlimm heute Hand

zurückspulen oder sowas, ja.

Genau, und daher ist das eigentlich auch alles nicht mehr so wild.

Aber man muss auch sagen, dass dieses Thema so ein bisschen vernachlässigt wurde.

Ich habe gerade auf Windows und so, wo kann man ja auch nicht davon ausgehen.

Also bei den meisten Linux-Systemen wird halt einfach ein Python-Interpreter vorinstalliert sein.

Vielleicht ein Uralter, aber immerhin.

Aber bei Windows ist halt Python nicht vorinstalliert und dann, wenn man irgendjemanden ein Python-Skript schickt oder so, kann der halt nichts damit anfangen.

Das ist ein bisschen ein Problem.

Das ist halt auch ein bisschen ein Preis, den man dann halt zahlt, dafür, dass es halt einfach ist, aber trotzdem sehr mächtig.

Und ja, also

die Binaries kriegt ihr natürlich trotzdem auf der Python rumschläge, direkt für die jeweiligen Systeme und wenn das.

Der Python-Interpreter selber ist natürlich wieder quasi so ein Binary.

Also einige Leute empfehlen auch Anaconda, das ist irgendwie so ein Paket, womit man ganz viel tolle Datensachen machen kann, wo es vorinstaliert ist.

Also ich persönlich hatte da nicht so die beste Erfahrungen mit.

Das war immer sehr verwurschtelt mit den Paketen, an die Firma was nicht, wenn es irgendwie ein Update gab und du hast eine Python-Version.

Die haben auch einen eigenen Paketmanager, dann Conda irgendwie.

Und deswegen würde ich das für Anfängen jetzt nicht unbedingt sofort empfehlen, obwohl viele das machen.

Aber das könnt ihr ja selber schauen.

Ja, ja, Anaconda ist ein bisschen verwirrend, weil also eben, es ist eben kein Paketmanager und auch nicht, also Anaconda ist eine Distribution sozusagen von Paketen.

Aber Conda ist der Paketmanager und es gibt auch noch ganz viele andere Pakete, die jetzt nicht in der Anaconda-Distribution drin sind.

Und das ist so ein bisschen, alles, eigentlich ist das alles ein bisschen furchtbar.

Man muss sagen, das schön wäre ja, sozusagen in der idealen Welt hätte man das ja gerne, dass man sozusagen einen Paketmanager für alles verwendet, ja, sozusagen.

Also es gibt auch so ein bisschen die Utopie wird so ein bisschen gelebt bei NixOS, versuchen Leute, das tatsächlich noch umzusetzen.

Oder eigentlich waren auch die Linux-Distributionen mal so quasi gedacht, dass man halt, man hat einen Paketmanager, mit dem installiert man halt irgendwie alles, was man irgendwie haben möchte.

Und ja, also das geht ja auch jetzt noch, wenn man jetzt ein Debian hat beispielsweise, dann kann man auch ein NumPy oder so, was ja quasi ein Modul ist für Scientific Computing-Modul für Python, kann man durchaus per Debian-Paket installieren, also über die Distribution.

Es ist halt nur so, dass man das nicht tun sollte, weil dann bekommt man eine Version, die nicht optimiert ist, wo der Maintainer, also ich meine, vielleicht ist es auch gut, ich weiß keine Ahnung, aber die Wahrscheinlichkeit ist hoch, dass es eben dann nicht schnell ist.

Weil es ist halt nicht gegen MKL, diese Mathe-Bibliothek von Intel gelingt beim Kompilieren.

Also man muss, es ist halt tricky, das zu kompilieren, da ist viel Core-Tranzeugs dabei.

Das ist alles nicht so einfach und ja, überfordert möglicherweise halt ein Debian Methana auch so ein bisschen.

Also du würdest auch immer alle Pakete über Pip installieren?

Naja, nee, ich würde sagen, es kommt drauf an.

Also leider haben wir nicht, also am schönsten wäre es, wir hätten einen Paketmanager für alles.

Hat zum Beispiel Pip oder dein Distributionsmanager.

So ist wie Apt oder genau oder weiß ich nicht, was es da bei Yam für Red Hat gibt oder was noch.

DF ist mittlerweile, glaube ich, auch bei Red Hat, also zumindest bei Fedora.

Ja, ich bin da auch gar nicht mehr so auf dem Laufen.

Aber genau.

Wenn man einen Paketmanager hätte, mit dem man alles installiert und dann sich relativ sicher sein könnte, dass das halt irgendwie funktioniert.

Das wäre schön.

Aber es hat sich jetzt aber eher so entwickelt, dass jede Programmiersprache so ein bisschen ihren eigenen Paketmanager mitbringt.

Also bei Python ist es halt erstmal Pip.

So wie bei Ruby sind das dann halt diese Ruby Gams, bei Perl ist es Cepan bzw.

ich weiß gar nicht, was jetzt das Ding ist, mit dem man die Dinger installiert.

Dann bei JavaScript ist es halt NPM oder JAN oder was auch immer man da gerade verwendet.

Und das ist dann natürlich nicht mehr so toll, weil das Problem ist, dass wenn man die jetzt benutzt, die Sachen, wenn man die jetzt quasi einfach so ins Root-File-System installiert, dann überschreiben die natürlich Sachen, die die Distributionen dafür machen.

Dann schreiben sie doch gegenseitig, wenn man verschiedene.

Überschreiben sich gegenseitig.

Alles nicht so schön.

Da hat niemand darauf aufgepasst, dass die Sachen auch alle miteinander klarkommen.

Das heißt, es können die komischen Dinge passieren.

Das ist halt nicht so toll.

Was macht man denn da?

Dafür gibt es ja eine.

Ja, dafür versucht man das dann irgendwie zu isolieren und installiert halt Dinge nur in Environments.

Also in virtuellen,

virtuelle Umgebungen, genau.

Oder für seinen einen User, also zum Beispiel Pip Install, Paketname, minus, minus User, wird halt das für den aktuellen Nutzer nur installieren.

Genau, das kann man auch machen.

Und das sind halt so ein bisschen krückige Lösungen für dieses Problem.

Aber es ist leider sogar noch schlimmer.

Es ist jetzt nicht nur so, dass jeder Programmiersprache einen eigenen Paketmanager hat, sondern es sieht so ein bisschen aus, also jedenfalls bei Python ist es halt leider so, dass da auch jede Community sozusagen ihren eigenen Paketmanager nochmal.

Die ganze Web-Community verwendet eigentlich überwiegend Pip, während die ganze Data Science-Community überwiegend Conda verwendet.

Wo man sagen muss, Conda ist ein bisschen mächtiger als Pip.

Man kann damit nicht nur Python-Pakete installieren, sondern halt auch diverse andere Binärpakete.

Manchmal muss man das halt dummerweise auch, weil viele der Sachen, die man da verwendet, sind halt Fortran-Bibliotheken oder irgendwelche C-Bibliotheken oder CPA.

Warum verwendet man denn Fortran oder C oder C<unk>-Bibliotheken in Python?

Ja, genau, das ist halt auch, weil wenn man jetzt zum Beispiel Matrizen miteinander multiplizieren will oder so, dann könnte man das natürlich auch in Python machen, indem man einfach Vorloops ineinander schachtelt.

Also man speichert die Dinger einfach quasi als zweidimensionale Listen oder so.

Man hat einfach eine Liste von Listen und dann, also man hat quasi eine Liste von Spalten oder Zeilen.

Oder mit

NumPy, glaube ich,

genau so.

Ja, ja, genau.

Aber man könnte es direkt in Python machen, dann macht man halt irgendwie so eine dreifach verschachtelte Vorloop und iteriert über die Dinger und rechnet das dann halt aus.

Das kann man machen, ist halt dann sehr, sehr langsam.

Wenn man jetzt so eine Bibliothek benutzt wie NumPy oder so, dann haben dann halt einen speziellen Array-Type sozusagen und wenn man da jetzt sagt, multipliziere mal A und B, dann nutzt NumPy unten drunter halt quasi, weiß ich jetzt gar nicht, was man in der Modul zu tun hat.

Das muss man jetzt gerade so auszumalen, wie das dann so aussieht in einem Schaubild, um mir das irgendwie so ein bisschen vorzustellen, warum das jetzt schneller geht.

Also wir benutzen drunter einen

optimierte Fortran-Bibliotheken, die genau.

Also, oder es ist, ich weiß gar nicht mal, ob es fortran ist unbedingt.

Also es ist halt irgendwie, die haben halt damals angefangen mit Blas, La Pak, Atlas, das sind so die Dinger, die da unten drunter liegen.

Und das sind, es gibt, glaube ich, irgendwie so eine definierte Schnittstelle für solche Matter, für diese ganzen Operationen.

Und dann sind das irgendwie Implementationen davon und ja, Magic.

Genau, Magie, ja.

So Fortran ist halt irgendwie als Sprache ist es immer noch deswegen so wichtig, weil da Sachen sich quasi mehr oder weniger automatisch vektorisieren lassen.

Das halt bedeutet, dass man nicht loopt über Sachen, sondern dass der Prozessor das quasi übernimmt.

Also das ist, also wenn man das einfach in C, könnte man dann natürlich auch eine Loop hinschreiben, wäre schon viel schneller als in Python, wahrscheinlich so tausendmal schneller oder so.

Aber selbst das wäre deutlich langsamer als das, was quasi die Bibliotheken, die unter NumPy liegen, halt machen.

Imagine.

Genau.

Hat so ein bisschen den Nachteil, dass man halt den Code anders strukturieren muss.

Man kann eben dann keine Vorschleife mehr verwenden, sondern man macht eher solche Sachen wie man auf den Objekten, die man als erzeugt hat, wie zum Beispiel irgendwelche Arrays oder so, ruft man dann halt irgendwie eine Funktion auf und übergibt dir ein Callback oder so.

Weil Vorschleifen gehen halt nicht mehr.

Das ist also ein bisschen komisch, aber es ist halt dafür schnell.

Mir ist halt so ein Trade-off, kann man sich überlegen, ob man sich das angewöhnt hat, dass man es gerne macht oder ob man sagt, hey, wir nehmen jetzt das ein bisschen kaufen.

Python ist ja immer erst langsam verschrien, aber wenn wir die auch schnell bekommen, ja, okay, dann machen wir vielleicht mal einen kleinen Umweg.

Genau, genau.

Ja, kommen wir vielleicht gleich noch zu, wenn es um die Mythen geht, aber das ist, man kann damit auch sehr schnell Dinge tun.

Und dafür muss es halt auf Bibliotheken basieren, die das halt auch schnell machen können.

Und für Scientific Computing-Zeugs ist es halt fortan oft.

Ja, genau.

Ja, also vielleicht nochmal genau zu diesen ganzen Bibliotheken, die man machen kann.

Du hast gesagt, glaube ich, Data Science kann man ganz viel machen und Web kann man ganz viel machen.

Und für diesen Glue, also den Klebstoff zwischen einzelnen Modulen kann man ganz viel machen, so zum Skripten.

Fällt dir noch irgendwas ein, so einer der USB?

Ja, ja, ja, was ich, was ich ein bisschen vernachlässige, genau, auch ein Bereich, der momentan sehr interessant wird.

So Home Automation Zeug, Smart Home.

Ich glaube, der hat der Raspberry Pi, der macht ja ganz, ganz viel.

Ja, genau, Raspberry Pi wird da oft verwendet und überhaupt Raspberry Pi und Python haben viele schöne Anwendungen, da kann man viel drauf machen.

Home-Automet, du hast hier, glaube ich, ganz viele schöne Sachen.

Ja, ich habe auch einen Raspberry Pi irgendwo im Schrank stehen, der zum Beispiel Temperaturen ausliest, indem man.

Also ich habe so ein DVB-T-Modul daran gesteckt, die gibt es jetzt irgendwie günstig, weil es gibt keinen DVBT-Markt.

Ich wollte gerade sagen, das ist doch gerade abgeschaltet worden.

Richtig, jetzt kann man die Dongel kriegt man relativ willig.

Und da ist so eine Antenne dran und dann habe ich hier irgendwie so Sensoren und die funken halt auf den Frequenzen, ihre Werte halt so alle paar Sekunden oder so.

Und dann muss man die eigentlich dann nur einsammeln und dann an.

Es gibt eine Software, die nennt sich Home Assistant schicken.

Also das ist ein bisschen komplizierter.

Ja, dann machen wir auch noch eine eigene Folge von der Frage.

Ja, genau.

Aber solche Sachen.

Also man zum Beispiel.

Also ich sehe jetzt aber zum Beispiel keine Schläuche in den Pflanzen, die du hier in deinem schönen Wintergarten stehen hast.

Also das heißt, das musst du auch selber geben.

Genau, ja, furchtbar.

Da muss unbedingt automatisiert werden.

Ich weiß noch nicht, wie ich den Wassertransport automatisieren soll.

Das ist ein bisschen gefährlich.

Eine Pumpe irgendwie und dann einmal einfach.

Und eine Anpflichtversicherung.

Ja, wäre eine Idee tatsächlich vielleicht.

Genau.

Ja, aber in dem Bereich ist Python halt auch, glaube ich, also sehr, sehr stark unterwegs.

Und da, gerade wenn man jetzt, also einmal auf der Serverseite, sozusagen, also das Ding, was diese ganzen smarten, mehr oder weniger smarten Geräte halt sozusagen managt und mit denen da irgendwas macht, irgendwelche Sensordaten ausliest, die Seite ist Python, aber halt auch die Sensoren selber.

Also man kann zum Beispiel, es gibt da so kleine Boards, kosten ein paar Dollar und da ist ein Chip drauf mit ein wenig, ja, kann ist nicht so schnell und hat auch wenig Speicher, aber da läuft MikroPython zum Beispiel drauf, sodass man da halt.

Nächste Folge?

Ja, genau.

Das heißt, man kann auch da Python drauf laufen lassen und dann irgendwie Sensordaten damit schon irgendwas machen oder die umgekehrt.

Da müssen wir wieder aufpassen, dass wir die Module so nehmen, dass sie möglichst klein werden.

Genau, da muss man wieder ein bisschen aufpassen und so.

Aber ja, also in dem Bereich ist Python halt auch sehr stark vertreten.

Ja, ich glaube, also was noch dazu kommt, vielleicht ist so Rapid Prototyping jetzt mal nochmal als Baswirt reingeschmissen.

Man kann relativ schnell irgendwelche Prototypen bauen von Dingen, die man benutzt, sei es jetzt im Web oder bei Daten, die dann auch funktionieren, die kurz sind.

Wenn man jetzt zum Beispiel die Sprache vergleicht, ist ja auch sehr einfach, deswegen eignet sich das besonders gut.

Ist vielleicht am nächsten am Pseudocode dran, nur von dem, was ich so gesehen habe.

Das heißt, man kann relativ einfach die Syntax formulieren und hat direkt ein lauffähes Programm, was wenigstens so grob das tut, was es sollte, später.

Ja.

Das ist noch so einer großen Vorteil der Sprache, wo man jetzt von außen drauf guckt.

Ja, vielleicht wäre es ganz interessant, das mal so ein bisschen zu differenzieren gegenüber den anderen Sprachen, die es halt in diesen Bereichen auch gibt.

Mit denen man auch diese ganzen Dinge tun kann.

Also Python ist halt, würde ich sagen, gehört so zur Familie der Skriptsprachen irgendwie.

Also man könnte sagen, sowas ähnliches wie Ruby oder wie Perl oder auch ein bisschen wie JavaScript.

Aber unterscheidet sich halt, oder PHP unterscheidet sich von denen aber.

Also wie zum Beispiel JavaScript und PHP, die sind halt dynamisch getypt und schwach getypt.

Dinge können ihren Typ ändern oder man weiß nicht, was sie sind, sozusagen von Anfang an.

Python auch so?

Ist in Python auch so.

Aber in Python, Python ist halt streng getypt auch.

Es ist dynamisch unstreng.

Das heißt, wenn ich jetzt sage, irgendwie eine Zahl plus irgendwie einen String oder so, dann kriege ich bei Python kriege ich dann halt ein Type-Error, also ein Typ ein Fehler.

Also ein Typ.

Da haut mir Python halt auf die Finger, während ein PHP oder ein JavaScript passiert dann halt irgendwas.

Was passiert denn da?

Das ist eine Magite.

Oder ist das keine dunkle Magite wahrscheinlich?

Es ist eher dunkel und man weiß nicht so genau, was dann passiert.

Es kommen die komischen Sachen, aber es gibt einen schönen Vortrag für JavaScript, da ist mal jemand, es ist ein bisschen veraltet, aber hat das mal jemand aufgeschrieben.

Ich glaube, wenn man danach sucht JavaScript-Talk und dann Watt, WRT, dann findet man das und dann, wo er dann so eben solche Dinge macht wie irgendeine Zahl plus Leerstringen und dann kommen halt die seltsamsten Dinge dabei raus.

Der Server hüpft und blinkt und.

Ja, am Schluss kommen irgendwie Zeichenketten dabei raus und Batman erscheint.

Also es ist halt wirklich, man muss aufpassen, was man da tut, ansonsten passieren ganz, ganz furchtbare Dinge.

Klingt so, als könnte man das gut ausnutzen.

Ja, und es passieren halt auch regelmäßig wirklich, wirklich schlimme Sachen.

Die Welt geht unter.

Ja, ja, so ungefähr.

Und das kann aber Python halt nicht so weit passieren.

Das ist schon mal ganz schön.

Also insofern ist es halt in der Welt, also es ist halt ein schöner, also ich finde, was man über Python sagen kann, ist, es macht halt die richtigen Trade-offs.

Also es ist halt immer, es ist halt so eine Sache.

Möchte man jetzt, es hat ja natürlich auch Vorteile.

Man kann Dinge vielleicht abkürzen oder so, wenn man das schwach getypt wird, wenn man das nicht so streng überprüft.

Man kann das teilweise ausnutzen, um Sachen eleganter zu machen, aber man zahlt halt einen Preis dafür.

Und Python hat so die Tendenz, immer diese richtigen Trade-offs zu machen.

In der neuen Version, ich weiß jetzt nicht gar nicht, was bei 3.7 kam oder bei irgendeiner 3.6-Version, dann kann man diese Typen jetzt so schön annotieren noch.

Kann man für Funktionen oder für Variablen direkt und sieht dann das direkt, dass beispielsweise in seinem Linter oder sowas, also das, was den Code unterstreicht, wenn ein Fehler da ist, dass der Typ falsch ist.

Also wenn man jetzt, ich sag mal, Standard-Typen R haben möchte oder feste Typen und keine dynamischen.

Dass man zumindest weiß, was halt stehen sollte, obwohl das Python immer noch versucht zu sprechen.

Ja, also, aber das Schöne ist halt, dass es halt optional, man kann das daran schreiben.

Also klar, natürlich.

Das ist auch einer der Vorteile, die in so einer Sprache wie Java oder so, die ist halt statisch getypt, also nicht dynamisch.

Da kann man hinterher, wenn ich eine Variable habe, dann die ändert sich nicht einfach so in was einen anderen Typ.

Das geht da halt gar nicht.

Und das kann auch nicht sein, dass halt hinterher der Typ erst festgelegt wird zur Laufzeit, sondern das muss halt zur Compile-Zeit sozusagen, wo der Source-Code in Bytecode verwandelt wird, muss das halt feststehen.

Eine schöne Geschichte, die man dann halt bauen kann, ist halt Unterstützung in den IDEs dafür.

Also wenn ich halt weiß, dass diese Variable halt den Typ hat, dann kann ich die Idee mir schon auf die Finger hauen, wenn ich versuche, damit etwas zu machen, was halt nicht geht.

Also das bringt auf jeden Fall nach einem interessanten Trade-off, weil als Anfänger würde ich mir jetzt erstmal so denken, dynamisch klingt ja voll cool, dann kann das immer was Verschiedenes sein und dann kann ich ganz tolle Sachen mitmachen.

Und du sagtest gerade, der Starter ist natürlich auch voll toll, weil man kann das irgendwie nicht verwechseln und man kommt keine unbekannten Fehler.

Naja, der Nachteil dabei ist halt, dann muss man viel mehr schreiben.

Was auch nicht so ein Problem ist, wenn man eine Idee verwendet, weil die schreibt das dann für einen so ein bisschen.

Aber man braucht dann halt eine komplizierte Idee, die irgendwie Dinge tut und dann auch nicht mehr so schnell sein kann.

Also ja, das ja, also man kann damit auch programmieren, so schlimm ist es nicht, aber es ist halt so ein bisschen, ich mag es nicht so.

Ich mag lieber, man schreibt wenig und schreibt das dann halt aber selber und das Tool, was man da verwendet, ist halt schnell.

Als die Idee schreibt das, aber die ist so ein bisschen laggy und man muss ein bisschen auf die warten.

Ja, gut, aber das geht auch.

In Python hat man das jetzt halt so nicht, das ist alles dynamisch.

Man kann aber auch Typ Annotationen jetzt seit, das ist auch eine sehr neue Geschichte, da kann man halt zwar dazu schreiben und dann könnte einem die Idee, oder vielleicht PyCharm und so können das möglicherweise auch schon, die kann einem dann dabei helfen und auch sagen, wenn irgendwas nicht geht.

Ich glaube, also zum Beispiel in Listen kann man auch verschiedene Datentypen benutzen.

Seider, man benutzt jetzt LumPy Arrays, wo das dann auch wieder fällt.

Ja, genau.

Aber ja, das ist glaube ich auch ganz interessant, weil es halt sein kann, wenn man durch nur eine Liste iteriert und man macht irgendeine Multiplikation oder sowas, dann fliegt einem was um die Ohren, weil das der falsche Datentyp ist.

Das ist halt, das ist genau einer dieser Geschichten, wo halt statisch getypte Sprachen große Schwierigkeiten mit haben.

Oder als Programmierer das Leben halt schwer machen.

So diese ganzen Containerdatentypen, die sind da halt knifflig.

Oder man kann halt im Grunde immer nur Container haben, die halt dann irgendwie Dinge von einem Typ enthalten.

Weil man muss ja irgendwie sagen, welchen Typ der ID Variable hat, die man da reintut.

Und das ist halt, also gut, geht mittlerweile auch.

Es gibt Generics und sind inzwischen auch in Java angekommen.

Man kann da auch so Sachen machen, aber das ist alles dann nicht mehr so richtig einfach.

Und ein Ding, was man dann halt oft sieht, was Leute dann machen, ist, sie haben halt, naja, also um diese Unzulänglichkeiten, sag ich mal, so könnte man das sehen in der Sprache, zu kompensieren, überlegen sie sich dann halt irgendwie Patterns, wie man bestimmte Probleme, auf die man dann stößt.

Wenn man nicht mehr einfach quasi beliebige Dinge irgendwie in ein Ding, was halt über Sachen iteriert packen kann.

Also so ein Python-Iterator ist halt, der iteriert halt über Sachen und da kann halt beliebiges Zeug drin sein.

Wenn das halt nicht geht, dann macht man halt dann muss man sich halt so Patterns überlegen, wie man Dinge tun kann.

Und für viele Situationen ist es dann halt, kann man das halt nicht einfach so hinschreiben, was man machen möchte, sondern dann muss man halt, dann gibt es ein ganze Gang-of-Four-Buch, irgendwie.

Bitte was?

Das ist ein ganz bekanntes Buch von, wie heißt das, das wird immer ein Gang-of-Four-Buch genannt.

Ja, das musst du unbedingt auch nicht shown auspacken.

Ja, ich glaube, das Ding heißt auch immer Design Patterns oder so.

Und da sind halt, ich weiß nicht, wie viele, das sind 100 oder irgendwas in den Dreh.

Typische Designpatterns, die man halt jetzt so statisch getypenprogrammiersprachen vor allen Dingen verwenden kann, wenn einem solche Probleme halt plagen, wie man damit umgeht und die das dann halt hübsch lösen, sozusagen.

Und wenn man dieses Buch durchgeht und sich dann überlegt, wie würde ich das in Python machen, dann stellt man halt oft fest, ich brauche da gar kein Pattern, ich kann in Python kann ich das einfach so hinschreiben.

Da muss ich mir kein kompliziertes Ding ausdenken, mit dem ich halt irgendwie da jetzt Architekturdingen, mit dem ich da mit diesem Problem fertig werde, weil ich habe das Problem gar nicht.

Und das ist halt schon sehr nett, dass man halt quasi eine große Klasse von Problemen, die halt, ja, also auch dieses Buch würde halt gefeiert, als das kann man irgendwie so programmieren in die Hand geben und dann kriegen sie das halt alles hin, wo sie sie vorher abgebrochen haben.

So in Python hat man einen Großteil dieser Probleme hat man einfach nicht.

Also loslegen machen.

Ja.

Und das ist halt schon sehr schön.

Das ist ein großer Vorteil.

Ja, also da würde ich sagen, ist halt auch eine der Stärken von Python, dass man halt quasi irgendwie einen Großteil der komplizierteren Programmierpatterns nicht braucht, weil man kann es einfach so hinschreiben.

Ich meine, klar, natürlich auch in Python gibt es Sachen, die kompliziert sind und nicht alle Patterns sind überflüssig, deswegen.

Also es gibt durchaus Sachen, die man da auch brauchen kann.

Aber es macht das Leben schon irgendwie leichter.

Ja, das wäre so der Unterschied statisch getypt, äh, dynamisch getypt.

Genau.

Den strengen Schwach hatten wir jetzt auch schon im Vergleich zu den anderen Programmiersprachen.

Was wir auch noch haben, ist quasi binär kompiliert, das hatten wir aber auch eben schon ein bisschen abgehangelt.

Ah ja, dann gibt es natürlich Sprachen, in denen man quasi das Memory Management selber macht, so C zum Beispiel.

Da muss man immer so einen Zeiger durch einen Speicher schicken, der genau sagt, wo man gerade ist.

Ja, also genau, also man luziert halt irgendwie Speicher, dann kriegt man einen Zeiger drauf zurück und dann macht man damit irgendwas und muss halt da hinterher dran denken, dass man diese Strukturen wieder freigibt, wenn man sie nicht mehr braucht.

Oder ja, wenn man Dinge freigibt, die man, die eigentlich mal noch brauchen, so passieren schrecklich Dinge.

Also das ist.

Wie muss man das in Python?

Hat man damit nichts zu tun?

Das ist sozusagen, das macht Python für einen selbst.

Es sei denn, man schreibt wieder so Low-Level-C-Module oder so, die irgendwelche Dinge tun, dann muss man das auch wieder selber machen.

Aber wenn man einfach sich in Python bewegt, dann hat man damit eigentlich nichts zu tun, weil das passiert dann automatisch.

Also Python verwendet da ein System, nennt sich Reference Counting.

Also es gibt da auch dann wieder einen Unterschied, also in einer Sprache wie Java ist es ja auch so, da muss man sich auch eigentlich nicht drum kümmern, das macht halt auch der Interpreter.

Und dann gibt es halt noch Sprachen, die machen einen Garbage Collector.

Wie Python?

Nee, ja, also Python hat auch einen Garbage Collector, aber ja, es ist ein bisschen kompliziert, leider.

Aber hauptsächlich ist es ein Python Reference Counting, sozusagen.

Das heißt, erzählt, wie oft ist irgendwas irgendwo da und wenn es nicht mehr da ist, dann schmeißt es weg.

Genau, wenn irgendwo eine neue Referenz entsteht, dann wird das halt hoch, wird der Reference-Counter hochgezählt und irgendwie ansonsten, wenn eine Referenz verschwindet, gelöscht wird, dann wird es runtergezählt und wenn es bei null angekommen wird, wird das Objekt abgeräumt.

Und das hat den großen Vorteil.

Es ist ziemlich schnell zur Laufzeit.

Und es ist sozusagen auch sehr einfach.

Also kann nicht viel schief gehen.

Es sorgt für vorhersagbare Latenzen.

Es hat aber auch einen großen Nachteil.

Okay.

Der große Nachteil ist, man kann dann nicht mehr parallel Dinge machen.

Oh Gott, oh Gott.

Also auf unterschiedlichen Prozessoren.

Das geht im Grunde nicht mehr.

Also das könnte man tun, dann muss man halt, wenn man es naiv machen wollte, müsste man dann für jede Operation, die jetzt irgendwie so einen Reference-Counter hoch oder runter zählt, dann müsste man irgendwie so einen Lock drauf machen und sagen, so jetzt mal alle, stopp.

Wir erhöhen jetzt diesen Reference-Counter und dann können alle wieder weitermachen.

Wenn man das tut, wird alles ungefähr 40 Mal so langsam.

Und das geht alles einfach nicht mehr.

So, ich glaube, Leute haben irgendwie lange dran gefallen, wir sind jetzt auf Faktor 20 oder so runter, wo man gar nicht gedacht hätte, dass es überhaupt möglich wäre.

Das heißt, du brauchst 20 Kerne, damit du dann den einen Kern.

Die Performance von einem Kern hinfickst, genau.

Das ist natürlich irgendwie nicht so richtig effizient.

Also das ist natürlich ein großer Nachteil.

Und dafür gibt es halt bei Python auch den Global Interpreter Log.

Den Mitte was?

Ja, Gil oder Global Interpreter Lock, das ist sozusagen ein Ding, was dafür sorgt, dass quasi ein Python-Prozess nur auf einer CPU läuft und nicht ein Python-Prozess auf mehreren CPUs laufen kann.

Das ist halt so.

Also das ist auch der Grund, warum Java das nicht macht.

Java hat einen Garbage Collector und hat dann dieses Problem nicht.

Das kann dann halt auf mehreren Prozessoren laufen, problemlos.

Oder naja, problemlos, aber geht.

Und sozusagen muss dann halt ab und zu mal aufräumen.

Dafür ist dann dieser Garbage Collector.

Das heißt, auf einmal gibt es eine Pause, nee, der Müll ist voll, jetzt muss er ein Müllauto, muss erstmal alles einsammeln und wegfahren.

Genau, das Problem ist, man weiß halt nie genau, wann der zuschlägt.

Und das bedeutet halt, dass man, wenn man einen Server laufen hat, dann kann es halt sein, dass man irgendwie plötzlich, es ist halt alle Requests sind super schnell und dann plötzlich einer dauert lang.

Also jetzt um bei dem Mülllautobeispiel zu bleiben, kann man nicht einfach messen, also wie voll der Müllcontainer ist und dann irgendwie den Müllwagen so gut fahren lassen, dass der ein Routenmanagement macht und da richtig vorbeifällt und die Sachen rechtzeitig lädt, bevor die voll gelaufen sind?

Ja, aber das Problem ist halt, du musst irgendwann.

Du weißt ja halt, wie Leute die Müll essen und wie viel Müll die wegschmeißen immer, oder?

Ja, ja, ja.

Also da wird auch eine ganze Menge gemacht und es funktioniert auch alles irgendwie so ganz okay, aber das Problem wirst du im Grunde nicht los.

Du hast immer das Problem, dass wenn der Müll weggebracht werden muss, musst du allen sagen, so jetzt mal Stopp.

Jetzt muss erstmal eine Müll weggebracht werden.

Die schmeißen alles in dieselben Mülltonne.

Ja, und dann, ja, selbst wenn das sehr schnell ist, kann es halt sein, dass es, weiß ich nicht, 200 Millisekunden dauert oder sowas.

Könnte man ja mal kleinere Mülltonne machen, also für jeden so eine kleinere Mülltonne, als wenn man seine große hat.

Ich weiß es nicht.

Aber dieses Problem ist nach wie vor da, also nach wie vor kämpfen da Leute mit.

Sag mal, das ist halt einer der Trade-Offs, wenn du halt einen Garbage Collector hast, dann hast du halt, dann kannst du halt irgendwie Sachen auf mehrere Prozessoren verteilen, aber du hast halt den Nachteil, dass deine Latenz so ein bisschen unvorhersagbar wird.

Ja, das ist halt blöd.

Und ja, das sind halt, man kann sich halt überlegen, was man irgendwie lieber mag, sozusagen.

Und auch da finde ich, dass Python dann eine ganz gute Wahl getroffen hat mit dem Reference-Counting.

Und auch da gibt es halt den Garbage Collecting, gibt es halt vor allen Dingen dafür, dass wenn jetzt so zirkuläre Referenzen irgendwie, also wenn das ein Objekt hat, das auf ein anderes verweist ist, auf ein anderes verweis ist eine Referenz auf ein drittes hat und das wieder auf das erste oder so.

Ja, dann werden die durch Reference-Counting nicht weggeräumt und dann muss man auch Python ab und zu mal einen Garbage Collector anschmeißen, um solche Sachen zu finden und dann rauszuwerfen.

Aber den Garbage Collector kriegt man bei Python mit sowas wie Import-GC dann oder so?

Ja, genau.

Und der macht manchmal auch blöde Sachen und auch da hat man dann halt manchmal so die Probleme, die man von anderen Programmiersprachen kennt, dass man zum Beispiel, ich weiß nicht, ob das heute noch so ist, aber früher war das immer so, wenn man größere Datenmengen importiert hat, per CSV oder weiß ich nicht.

Also ich habe früher irgendwie viel so Import-Export-Skripte auch geschrieben und da war halt so einmal einer der Tricks, dass man quasi bevor man halt so ein paar Millionen Zeilen irgendwie lesen hat und die irgendwo reingeschrieben hat in der Speicherdatenstruktur, einmal den Garbage Collector ausgeschaltet hat, dann hat man den ganzen Scheiß importiert und dann hat man ihn wieder angeschaltet.

Weil ansonsten schlägt er halt alle paar tausend Zeilen oder so zu und blockiert alles.

Und das macht es halt dann irgendwie ein paar Faktoren schneller oder so.

Aber heute kann sein, dass heute alles nicht mehr nötig ist und es besser geworden ist.

Ich müsste mir vielleicht auch mal rausfinden, ob das wirklich noch so ist.

Wenn man das wirklich immer machen muss, dass man einen Müllwagen sagen muss, nee, heute nicht.

Ja, genau.

Also wenn man weiß, was passiert, wenn man sagt, so, ich hole jetzt die ganze Zeit Zeug einen Hauptspeicher, ich weiß, dass es so ist und es ist richtig so, da muss nicht geguckt werden, ob das irgendwie jetzt, ob davon was weg kann, weil davon kann noch nichts weg, weil ich habe noch nichts anderes gemacht, dann kann ich halt sagen, okay, da soll jetzt momentan nicht, muss der Müllwagen nicht rumfahren.

Das ist erst danach.

Aber es ist natürlich schon hässlich.

Mit solchen Dingen will man sich eigentlich als Entwickler ja gar nicht so beschäftigen müssen, weil das ist natürlich irgendwie für die meisten Leute alles.

Ja, ich

glaube auch, unsere Anfänger haben wir gerade vielleicht wieder ein bisschen abgehängt.

Ich hoffe, wir holen die noch wieder ein bisschen ein.

Ich hoffe, ihr findet das alles so interessant wie ich.

Vielleicht kommen wir dann noch ein bisschen wieder zurück zu dem, was wir jetzt durch hatten.

Ich glaube, wir haben jetzt so ein bisschen erklärt, wie Python jetzt funktioniert.

Ich weiß nicht, ob wir dazu noch ein bisschen was sagen möchten.

Lass uns gerade überlegen.

Ja.

Nö, also im Grunde sind das so die wesentlichen Unterschiede zu anderen Programmiersprachen.

Ja, ja, okay.

Also das heißt, die Unterschiede haben wir jetzt so ein bisschen erklärt, was man also machen kann.

Vielleicht müssen wir auch noch drauf eingehen, was so die Mythen dieser Sprache sind.

Also ich habe jetzt total einfach.

Das ist immer so einer der Sachen.

Fand ich jetzt tatsächlich auch, also von der Syntax her, dass es sich gut las, dass du nicht irgendwie da standst und hat es irgendwie wie ein C, so ein Hello World, wo es dann irgendwie über mehrere Zeilen geht oder wen Java, wo dann erstmal gucken muss, wo geht denn jetzt diese Funktion hin, steht ja Print Hello World fertig.

Genau, genau.

Bei Java muss man dann erst irgendwie komische, erst eine Klasse definieren und dann irgendwie Public Setting Void Main oder sowas hinschreiben, wo es halt so irgendwie so magische Worte, damit irgendwas passiert.

Aber in Python schreibt man einfach Print hin.

Wenn man printen möchte, das ist schon ein Zenet.

Ja.

Also bleibt Python denn so einfach, wenn man das.

Ja, ja.

Also, was man damit machen will.

Ja, ja, ja, man kann da auch

Netzwerkkram damit machen, das fanden wir noch.

Und ja, genau, und asynchrone Dinge und überhaupt, ja, da kann es auch dann relativ fies werden.

Das Dumme ist nur, dass es halt dann, wenn man fiese Probleme hat, dann kann man da nicht viel dran tun.

Dann muss man leider manchmal den sauren Apfen beißen.

Aber ich meine, es ist ja auch schön, wenn quasi schwierige Probleme möglich, äh, schwierige Sachen möglich sind.

Einfach einen bemächtigen Tauberstab, ja, also noch mehr Magie, ja.

Aber es gibt tatsächlich auch Situationen, wo man dann halt auch komplizierte Dinge tun kann, beziehungsweise muss.

Und ja, wo es manchmal auch nicht so richtig offensichtlich ist, was Python da tut.

Ja, und es gibt halt auch so Ecken, die halt einfach nicht schön sind.

Das muss man natürlich auch sagen.

Wenn ihr jetzt einfach irgendwelche Daten von irgendwelchen Sensoren packen wollt in eine Datenbank, was ihr dann relativ macht.

Ja, für die meisten Sachen geht das.

Handson und genau.

Genau, ja, also mit Mythos ist es einfach so, es ist, es ist, würde ich sagen, tatsächlich sehr, sehr einfach.

Es ist schön, wenn man irgendwie auf Stack Overflow schaut oder einfach googelt nach irgendwelchen, wie mache ich denn jetzt dies oder jenes, dann ist es toll, weil das funktioniert halt meistens immer noch, selbst wenn die Antwort, die irgendjemand gegeben hat, 15 Jahre alt ist oder so.

Es gibt tatsächlich auch relativ viele Antworten mittlerweile für Python, das ist auch sehr angenehm, weil fast für alles, für jedes einzelne Problem, was man irgendwo hat, irgendjemand das schon mal hatte und irgendwie so eine Musterlösung findet oder auch das Problem dann von mehreren Seiten angucken kann.

Ja, aber ja genau, also das ist das Python einfach ist, würde ich sagen, ist so ein Mythos, der durchaus irgendwie mehr Wahrheit als Mythos ist.

Ja, eine andere Geschichte wäre halt irgendwie, oh, dieses Significant Whitespace, das ist ja total furchtbar, das kann da, ich kann so nicht arbeiten.

Significant White Space, und für alle Leute, die das jetzt gerade zum ersten Mal in der Sprache zuhören, bedeutet das tatsächlich, man darauf achten muss, wo was in dem Code steht von Python.

Ja, dass man halt nicht quasi den Code beliebig formatieren kann, sondern dass halt Whitespace halt auch zur Syntax gehört.

Also das, wenn ich jetzt.

Ja, also wenn ich eine Zeile, die im gleichen Block ist, anders einrücke als die andere, dann geht das halt schief.

Also das, was ein guter Programmierer von vornherein formatieren sollte in seinem Code, das sagt Python, wenn du es nicht machst, dann stürzt du ab und sagt, nee, nee, nee, du aber nicht.

Ja, genau.

Ja.

Das ist natürlich doof, wenn man sich so ein anderes Schema angewohnt hat, irgendwann mal gemacht.

Genau, und man kann das halt nicht beliebig einstellen.

Oder wenn man jetzt Tabs und Spaces mixt oder so, überhaupt, man kann Tabs auch verwenden zum Einrücken, aber das sollte man nicht tun, das ist böse.

Immer schön Spaces verwenden lassen.

Vier Leerzeichen pro Ebene.

Und die meisten IDEs hier bauen die das auch irgendwann um.

Das heißt, ihr könnt das so bauen, dass ihr dann vier Spaces pro Tab bekommt.

Da könnt ihr wieder im Tab arbeiten, aber es wird umgewandelt und ansonsten habt ihr tatsächlich manchmal Probleme.

Wenn ihr irgendwelchen Code Freunden schickt oder Code von Freunden bekommt, die haben Tabs benutzt und ihr Leerzeichen, dann funktioniert das nicht mehr und ihr seht nicht genau warum, weil irgendwo irgendwelche Leerzeichen dazu führen, dass da unterschiedlich interpretiert wird und dann stürzt das ganze Programm ab.

Hässlich.

Gerade für Anfänger manchmal stehen davor und denken sich so, was?

Warum?

Geht nicht.

Ja.

Also ich würde sagen, so ein bisschen was ist ja da ja drin.

Also ich dachte auch am Anfang, also ich kam ja dann zu der Zeit, wo ich mich mit Python angefangen habe zu beschäftigen, auch von Pearl her, wo man das halt nicht hat, wo man das kommentieren kann, wie man will und so.

Und ich dachte auch so, oh, das ist aber blöd, dass man da jetzt irgendwie das darauf achten muss.

Aber das waren halt ein paar Tage und danach war es super und fand das nie wieder problematisch.

Aber ich kann so ein bisschen verstehen, dass es blöd ist, wenn man das selber dafür sorgen muss, dass die quasi Formatierung so ist, dass die Syntax stimmt.

Ich würde aber auch sagen, dass man das heute eigentlich nicht mehr macht.

Also andere Sprachen machen ganz viele Klammern oder Semikolon oder sowas.

Das ist halt der Preis, den man dann zahlen muss, wenn man halt quasi eben nicht die Formatierung Teil der Syntax als Teil der Syntax hat, sondern sagt, okay, du kannst formatieren, wie du willst, dann muss man halt irgendwie anders signalisieren, wo einen Block anfängt und aufhört.

Und dafür benutzt man halt typischerweise Klammern.

Und das heißt, man hat halt sehr viele Klammern.

Kannst du mal zählen, fünf Klammern auch, sechs haben wir zu

halt auch nicht so richtig schön.

Python ist diese Frage halt nie so, muss ich da jetzt noch eine Klammer zu?

Doch, man hat sie auch an anderer Stelle, aber jedenfalls nicht beim Schließen von Blöcken, so muss ich da jetzt noch eine Klammer zu machen oder nicht, sondern nee, wenn ich den jetzt eingerückt habe und aufhöre, dann ist dieser Block vorbei.

Das ist halt viel einfacher.

Ja.

Und genau, heutzutage auch schon gar nicht mehr so ein Problem, weil heute würde ich sagen, sollte man Code eigentlich gar nicht mehr unbedingt selber formatieren, sondern man schreibt es halt irgendwie hin, dass man denkt, dass es halbwegs passt.

Und dann nimmt man halt sowas wie Black.

Das ist jetzt ein Ding, was halt Black Schwarz.

Genau.

Das ist so ein Kommandozeilen-Utility, man kann das, das gibt es aber auch SWIM-Plugin für einen Editor oder so.

Und in dem sagt man einfach nur, okay, reformatiere alle so, dass es irgendwie dem Standard entspricht und dann formatiert das den Code halt um.

Aha.

Und dann muss man da selber nichts mehr machen.

Muss man das importieren oder ist das ein Kommandozeilento-Tool?

Das ist ein Kommandozeilentool, aber wie gesagt, es gibt für die meisten Editoren Plugins, die das dann halt automatisch haben.

Diese muss ich mir direkt mal aufschreiben, ja, wieder was zu lernen.

Genau.

Ja, also ich würde sagen, heutzutage sollte man eigentlich nicht mehr von Hand formatieren müssen, das macht man einfach nicht mehr.

Genau, damit ist das im Grunde alles kein Problem mehr, weil man hat ja als Mensch gar nicht mehr damit zu tun, man muss sich keinen Gedanken mehr drücken.

Man muss einen Code in eine Zeile schreiben, es funktioniert weiterhin wunderbar.

Man kann tatsächlich relativ viel in eine Zeile schreiben, aber dann in Python muss man das dann auch signalisieren, dann schreibt man ein Semikolon, wenn man Statements voneinander dran möchte.

Ja, das Semikolon gibt es auch in Python.

Man muss es normalerlich nicht hinschreiben, weil der Zeilenumbruch das ist halt quasi gleiche.

Wenn man es hinschreibt, tut man.

Aber wenn man es hinschreibt, dann kann man auch alles in eine Zeile schreiben, ja, das geht.

Nicht, dass man das wirklich tun sollte, aber.

Das sieht ziemlich argie aus.

Aber für so ein Telepromp oder so.

Ja, genau.

Ja, also das ist eine Geschichte, die halt immer wieder als, oh, das ist ja total schrecklich angebracht wird, aber ich würde sagen, einmal, sie ist nicht so schrecklich und zum zweiten heutzutage nicht mehr kein Problem mehr eigentlich.

Ich hätte gerade

gepiept, muss man eine Pflanze gießen jetzt?

Nee, meine, ich habe vergessen, meine Uhr zu sagen, dass das gerade nicht, dass sie nicht stören, dass sie nicht rumhaften sollen.

Ja, und deswegen piept es bei mir.

Ich mache das gerade nicht auf Lot los.

So.

Und eine andere Geschichte ist, ja, genau, Python ist langsam.

Das ist auch immer etwas, was man halt hört.

Oh mein Gott, nein!

Was tue ich jetzt?

Ja.

Ich bin viel schneller mit in der hier.

Ja, man muss irgendwann das in Go neu schreiben oder in, keine Ahnung, oder in C oder C<unk>, viel besser, weil viel schneller.

Und ist es langsam?

Ja und nein.

Also es kommt halt tatsächlich, also man kann, solche pauschalen Urteile sind halt immer falsch eigentlich deswegen, weil man das, ja, man muss halt immer quasi konkret sagen, was man damit meint, wenn man jetzt sagt, es ist schneller oder langsam und halt einen bestimmten Kontext geben und dann kann man das halt sagen.

Also ich könnte zum Beispiel sagen, also wenn ich Methoden aufrufe in Python, dann ist das halt deutlich langsamer als jetzt in C<unk> zum Beispiel.

Das ist tatsächlich so, oder wenn ich eine Funktion aufrufe in C, ist es viel schneller als in Python.

Also wenn ich halt eine Vorschleife mache und dann tausendmal eine Methode aufrufe auf einer Klasse oder so, dann ist das in Python viel, viel langsamer als in C oder in C<unk>.

Insofern, in diesem Kontext wäre Python tatsächlich sehr langsam.

Aber die Frage ist halt, was ein Programm so tut.

Und wenn ich jetzt zum Beispiel irgendwie große Matrizen miteinander multipliziere und ich mache das halt irgendwie mit zwei NumPy-Arrays in Python, wo die Syntax sehr schick ist und ich das in einer Zeile tue, and jemand anders überlegt, sich hat gehört, Python ist langsam und macht das halt in C mit so einer dreifach verschachtelten For loop über halt irgendwelche Datenstrukturen, weil ich nicht irgendwie so ein Type Memory View oder what Cannes.

And that könnte jetzt für manche Leute überraschend sein, weil wenn quasi sich jemand die Mühe gemacht hat, irgendein Problem, also wirklich da so das letzte Quäntchen, Performance rauszuoptimieren, und es eine Bibliothek gibt, die halt dieses Verfahren dann benutzt, sozusagen in Python, und man das in Python benutzen kann, dann ist das halt auch in Python sehr schnell.

Und gerade diese ganzen Berechnungsgeschichten, Scientific Computing-Zeugs, das ist halt alles sehr schnell in Python.

Ja, das C-Types, oder?

Nein, nein, nein, nein.

Das ist doch nicht anderes halt.

C-Types ist nochmal eine andere.

Da habe ich irgendwas durcheinander geworfen.

Entschuldigt bitte.

Es ist auch so, dass man, dass man quasi relativ einfach eine Geschichte, mit der man dann halt gut optimieren kann, ist auch sowas wie Seiten zum Beispiel.

Also C-Types ist nochmal eher zum Anbinden von irgendwelchen C-Bibliotheken, aber es gibt sowas wie, ach das hatten wir, das haben wir vergessen.

Das müssen wir vielleicht gleich nochmal, es gibt nicht nur den Python, den C Python-Interpreter, es gibt nur andere Python-Interpreter.

Und es gibt halt auch so Dinge wie Seiten, die Python bzw.

Python-ähnlichen Code nehmen und den in C verwandeln.

Ja, also das haben wir ja gar nicht vergessen, dann erklären das doch einfach jetzt.

Genau, genau.

Wenn ich jetzt irgendwas schnell machen möchte, dann gibt es halt die Möglichkeit, okay, ich schreibe das halt einfach in C und muss mich da ein paar Konventionen halten, dann kompiriere ich das und dann quasi importiere ich, kann ich das halt in Python auch wieder importieren, als wäre es ein Python-Modul oder so und dann halt verwenden.

Aber ich schreibe einfach C-Code und dann wird das in Python geladen, ich benutze die Python-Syntax und bin schnell dabei.

Ja, ja, ja, so ungefähr.

Das ist halt ein bisschen Arbeit, aber das geht.

Und das ist vor allen Dingen halt auch so ein bisschen, man muss sich wieder einlesen, wie man das, wie man so ein C-Modul schreibt und so.

Aber was man auch machen kann, ist, man schreibt halt das, was man, was man auch nochmal machen möchte, in einem Python-ähnlichen Dialekt, wo man halt auch, man kann einfach so Python hinschreiben.

Python-ähnlicher Dialekt, jetzt haben wir ja schon ganz viel Programmiersprache, es gibt sogar noch Dialekte, das wird ja immer besser.

Man kann da zum Beispiel, also der wesentliche Unterschied ist, dass man dazu schreiben kann, was die Typen sind, dass man zum Beispiel schreibt, also dies ist jetzt ein Integer oder das hier ist ein Float und so.

Also man schreibt halt quasi noch Typen mit zu den Variablen.

Wie wir das eben schon hatten, also dass mit der neuen Version jetzt schon so drin ist, genau.

Type-Anotation, aber die sind halt leider nochmal was anderes.

Das funktioniert nicht mit Type-Annotation.

Okay, das heißt nochmal ein bisschen umwendig.

Könnte man vielleicht irgendwann auch machen, das gibt es aber noch nicht.

Jedenfalls, wenn man das jetzt so hingeschrieben hat, in diesem Dialekt, der sehr einfach ist und aussieht wie Python quasi, mit Typen dran, dann kann man das in C kompilieren und zwar in C, dass halt man dann hinterher wieder so kompilieren kann, dass es ein C-Modul ist, das man dann wieder importieren kann.

So dass man halt das eigentliche C nie sieht.

Man muss eigentlich nur Python ein kleiner Dialekt schreiben und schon ist es C und dann wird es schnell.

Genau, genau, genau.

So schnell wie C.

Und ist dann so schnell wie C.

Problem gelöst, würde ich sagen.

Genau, und das ist halt schon sehr cool.

Das kann man sogar in Jupyter-Notebooks als Cell-Magic schreibt einfach Prozent-Prozent-Seiten, schreibt dann halt irgendwie die Funktion rein mit Annotation der Typen und dann hat man etwas, was halt so schnell wie C ist halt direkt, so ohne dass man das irgendwie neu starten muss oder so, wusch.

Einfach so da.

Und das ist halt schon sehr, das ist ein, ja, also ich meine, wenn man solche Sachen zeigt, wie sagen Python ist langsam, dann kann, wenn man es drauf anlegt, kann man sehr schnell werden.

Auch in diesen Geschichten kann man halt auch diesen Global Interpreter-Log deaktivieren.

Dann kann man halt sagen, so, okay, ich weiß hier genau, was ich tue, ich deaktiviere das Ding.

Also da ist das alles nicht mehr so relevant.

Also da kann ich dann auch mit mehreren Kernen rechnen.

Genau, da kann ich dann auch quasi das, was ich tun möchte, auf mehrere Prozessoren verteilen.

Passiert auch.

Also wenn ich jetzt irgendwie, keine Ahnung, eben eine Matrizenmultiplikation, das weiß ich gar nicht, ob das mit einem, aber wenn ich irgendwelche Dinge auf Lumpe-Arrays mache oder in Pantas mache, manchmal, ja nicht immer, verteilt es dann halt den Kram automatisch halt auf alle Prozessoren, die ich da habe.

Ja, ansonsten gibt es auch jede Menge schöne Bibliotheken, die man da benutzen kann.

Für Data Science-Geschichten ist da halt zum Beispiel Dask sehr zu empfehlen.

Dask.

Data Ask.

Ich weiß gar nicht genau, wofür das steht.

Task, nur D, ja.

Da ist ein Task.

Ja, ein Task überst du.

Ja, genau.

Und ja, es gibt auch so, da gibt es noch diverse andere Geschichten.

Es gibt zum Beispiel Number.

Das ist halt ein Dekorator, den schreibt man drüber und dann macht das halt so Just-in-Time-Kompilierung, wie man das halt auch von Java vielleicht kennt.

Das kann Dinge auch total beschleunigen.

Da muss man gar nichts ändern.

Also auch da kann man dann natürlich Typen dazu schreiben oder so.

Aber auch da oft ist es so, man schreibt es einfach drüber und die Funktion wird viel, viel schneller.

PiPy oder sowas habe ich noch.

PyPy, genau, das ist dann ein anderer Interpreter, den man verwenden kann.

Der hat dann diverse Probleme nicht hat, der hat dann macht auch so Just-in-Time-Kompilierungsgeschichten und so.

Und ist dadurch schnell.

PyPy ist ein bisschen problematisch.

Das hat irgendwie immer so auf der aktuellsten Version von Python.

Und das ist so ein bisschen leidet darunter, dass da nicht so genug Leute dabei sind.

Es gibt auch Stackless-Python, also es gibt noch diverse andere Interpreter.

Es gibt nicht nur den C-Python-Interpreter.

Aber man muss schon sagen, der C-Python-Interpreter ist natürlich eigentlich derjenige, den die Leute so verwenden und den man halt kennt.

Und auch halt auch die Referenzimplementation.

Aber wenn man jetzt in einem bestimmten Szenario mehr Performance braucht, dann kann es durchaus sinnvoll sein, da halt sowas wie PyPy zu verwenden oder so.

Ich traue niemals dem Mensch magst, die dich selbst gefällt hast.

Ja, genau.

Ja, das ist auch so einer der Mythen.

Irgendwie Python ist langsam.

Was haben wir denn noch so?

Ja.

Also wir wissen, dass Python einfach ist, wir wissen, dass Python nicht langsam ist.

Nicht langsam sein muss.

Wir wissen, dass man für Python ja trotzdem ganz viele mächtige Werkzeuge benutzen kann, wenn man dann irgendwann mal gelernt hat, wie.

Ja.

Fällt dir noch was ein?

Nö, dazu gerade gucken.

Warum hat Python so lange gebraucht, bis es sich so durchsetzte?

Was glaubst du?

Das ist eine gute Frage.

Also ich hätte damit auch gar nicht gerechnet, dass es jetzt passiert.

Also wenn ich jemand quasi am Anfang meiner Python-Begeisterung gefragt hätte, ob ich glaube, dass sich das mal so durchsetzt, dann hätte ich gesagt, ja, auf jeden Fall.

Und ich hätte wahrscheinlich geschätzt, dass es viel weniger lang dauert.

Und jetzt angekommen ist, sagst du, es gibt auch gar keine Alternative.

Also auch Go sagst du, das ist ja zwar ganz fancy Stuff, aber.

Nein, das ist auch alles schön.

Also ich meine, ich finde Go auch toll, ich finde auch Rust toll.

Das hat alles schon so auch, das sind halt vor allen Dingen andere Trade-offs und ich meine, gut, das sind auch alles manchmal so sehr viel modernere.

Also ich würde sagen, Go ist stark, auf der Go-Syntax ist sehr stark inspiriert von Python.

Die, die also, ja, sind teilweise sehr, sehr viel, also sowohl Go wie auch Rust sind halt sehr viel jünger als als Python, insofern ist es halt auch vielleicht nicht unbedingt direkt miteinander vergleichbar.

Aber Go ist halt halt ein schmaleren Einsatzzweck, würde ich jetzt mal so denken.

Vielleicht ändert sich das auch noch irgendwann an.

Und wahr?

Also wofür würdest du jetzt Go benutzen?

Naja, Systemprogrammierung und halt Sachen, wo man quasi viel I.O.

hat und viel CPU braucht.

Das ist, also wenn man jetzt zum Beispiel sowas wie ein Datenbankserver schreiben will oder so.

Wobei ich nicht weiß, ob Go da wirklich, also ich weiß auch nicht, ob das jemand schon mal gemacht hat, aber das könnte man eventuell tun.

Also viel Sachen machen muss, heißt tatsächlich Input-Output die ganze Zeit.

Input-Output plus irgendwie viel CPU braucht.

Also wenn nur Input-Output machen muss und I.O.-Multiplexen, das geht in Python auch total super.

Nennt man Async IO oder die neuen Frameworks, die es da gibt, weiß ich nicht, Trio da oder was auch immer.

Trio von David Beasley, Bürgerschef in der EuroPython, das war auch sehr toll.

Aber ich glaube, das ist nur ein Dialekt von Async.

Ja, genau, das ist ein bisschen, die sind auch relativ kompatibel irgendwie zueinander.

Das ist, genau, damit geht das auch alles total super.

Dafür brauche ich jetzt nicht, da ist der Gill nicht unbedingt ein Problem.

Der Gribble Interpreter-Log, ja.

Genau, genau.

Ich kann auch mehrere Prozesse starten oder so.

Aber wenn ich jetzt sowas habe wie eine Datenbank oder so, dann ist das mit mehreren Prozessen unter Umständen blöd, wenn ich jetzt.

Also da könnte es sein, dass es sinnvoll ist, ja.

Also dass ich halt einen Prozess habe, der halt auf vielen Prozessoren läuft und dann auch IO-mäßig irgendwie ganz viel nach draußen macht.

Und da wäre Go wahrscheinlich super.

Ja, oder Rust hat halt auch schöne Eigenschaften, dass halt da irgendwie diverse Sachen garantiert sind zur Compile-Zeit.

Das ist halt toll.

Ja.

Aber Moment, jetzt musst du nochmal kurz erklären, es sind bestimmte Sachen garantiert zur Compile-Zeit, da die bei Python nicht sind.

Da musst du jetzt ganz kurz nochmal versuchen, das so zusammenzufassen.

Das habe ich jetzt nämlich noch nicht so ganz durchblickt.

Ach, ich weiß nicht.

Vielleicht führt das auch ein bisschen zu weit, also weil bei Rust ist es halt so, dass man quasi garantieren kann, dass es keine Speicherelecks gibt und so.

Bei Python sollte das jetzt auch nicht passieren, wenn man das schafft, außer dadurch den Speicher wirklich zu verbrauchen, also wenn man einfach nur irgendwas macht und irgendwas erzeugt, irgendwas wieder wegschmeißt und trotzdem quasi der Prozess, der Speicher des Prozesses, den man da halt geschaltet hat, immer größer wird, dann hat man halt einen Bug gefunden.

Also gibt es natürlich auch immer wieder.

Sollte aber auch nicht passieren in Python.

Aber es gibt da nicht so harte Garantien.

Und man kann es auch kaputt machen, wenn man das darauf anlegt.

Irgendwelchen Unsinn anstellen.

Gabisch-Pollektor importieren, dann drauf referenzieren, auf die Objekte, die man da findet.

Ja, man kann da beliebig kaputte Sachen natürlich machen.

Genau.

Ja, aber diesen Anwendungsfall, dass man viel IO und viel Prozessor gleichzeitig braucht, den haben, glaube ich, glaube ich, gar nicht so viele Leute.

Insofern ist es halt auch so, dass ich finde, das ist der richtige Schritt sozusagen.

Oder ich finde, das ist ein sehr netter Punkt quasi.

Wenn man jetzt Reference Counting in Python hat, man hat halt gute Single-Thread-Performance, man hat sehr gutartiges Latenzverhalten, das ist alles, verhält sich alles sehr schön.

Gut optierbar damit dann auch

damit halt, dass es auf mehreren Prozessoren laufen kann.

Aber den Fall, dass man jetzt Software hat, die tatsächlich auf vielen Prozessoren laufen muss, den haben die meisten Programmierer gar nicht.

Denn dieser Anwendungsfall trifft ja nur einen kleinen Teil.

Spieleprogrammierer.

Spieleprogrammierer und Unterbeständen, ja, Leute, die Datenbank-Server schreiben oder irgendwie einen Web-Server nicht mal.

Oder ich weiß es gar nicht, mir fällt es sogar tatsächlich schwer, mir dazu zu bauen, die das irgendwie erfordern.

Insofern ist halt diese Beschränkung halt nicht so schlimm, wie sie aussieht.

Und in Java, das sieht total toll aus, auf dem Papier.

Kann auf vielen Prozessoren laufen.

In der Praxis ist es aber blöd.

Die Single-Shread-Performance ist nicht gut.

Und also das, was halt die meisten Leute interessiert, wenn sie jetzt irgendwie irgendwas starten, ein Programm starten und das tut dann irgendwas, wenn es halt, das ist halt langsamer.

Das ist halt genau der Grund, warum, wenn ich jetzt in so einer IntelliJ-Idee auf den Kopf drücke, dass es sich halt irgendwie sich alles so zäh anfühlt, weil ja Single-Shread-Performance nicht so toll ist.

Das ist und Latenz nicht vorhersagbar, klingt nicht so schlimm, ist aber in der Praxis doof, weil manchmal zur falschen Zeit irgendwie, wenn was mehr Latenz braucht, kann halt sein, dass es halt unter Umständen sehr teuer wird.

Je nachdem, was man da für Services betreibt.

Und ja, das ist eigentlich, das sind Dinge, die hören sich harmlos an, sind aber ziemlich schlimm.

Während in Python, das hört sich ziemlich schlimm an, ist aber gar nicht so furchtbar.

Und wenn man dann tatsächlich so eins von diesen Problemen hat, dann kann man halt da drumherum arbeiten, oft, indem man dann halt viele Prozesse startet.

Gut, dann muss man irgendwie dazwischen kommunizieren, muss irgendwie vielleicht Chat Memory haben oder solche Sachen, aber es geht.

Selbst wenn man jetzt in einer Sprache ist, wo es theoretisch möglich ist, das alles in einem Prozess zu machen, ist es auch oft nicht so eine gute Idee.

Weil das dann oft sehr kompliziert wird und man halt auch ordentlich locken muss und ja, wirklich sich vorzustellen, was passiert, wenn ein Prozess auf mehreren CPU parallel unterschiedliche Dinge tut, das ist einfach für auch ein Programm, ich würde sagen, die allermeisten Programmierer überfordert das total, zu mich überfordert das total.

Du kannst nicht einfach multidimensionale Matrizen in deinem Kopf schummieren.

Ja, also das ist so, und wenn man jetzt sozusagen etwas, was zu schwierig für die meisten Leute ist und selten gebraucht wird, halt sagt, das ist etwas, auf das optimieren wir hin, dann ist das irgendwie einfach, naja, ich weiß nicht, ob das so sinnvoll ist, aber ja.

Wenn ihr anderer Meinung seid, schreibt eine E-Mail an Handwagen.

Wahrscheinlich www.de.

Ja, also ich finde das jetzt nicht die reine Wahrheit sozusagen, sondern es ist natürlich sehr gefärbt.

Ich mag halt Python, aber ja, ich finde, die haben da einfach einen sehr schönen Sweetspot quasi.

Klingt, dass das eine Sprache, die auch zukunftsträchtig durchgeht.

Genau ist, ja.

Achso, hatten wir das, hatten wir eigentlich das Zen auf Python schon?

Nein, das haben wir noch nicht gemacht.

Das wäre jetzt tatsächlich am Ende der Mythen noch

der Punkt.

Vielleicht sollten wir das nochmal kurz.

Senden auf Python.

Das hört sich ja sehr philosophisch an, so ein bisschen nach fernöstlicher Philosophie.

Ihr rufen es gerade auf und möchtest du es tatsächlich zitieren?

Ich denke schon, tatsächlich.

Also man kann sich das auch selber angucken, wenn man einfach so Pythet, einfach Python eingibt und dann sagt Import this, dann erscheint das und es bringt halt so ein bisschen zum Ausdruck, was so Python besonders macht oder wie man Dinge in Python tut und wie sie vielleicht ein bisschen anders sind, als man das normalerweise vielleicht gewohnt ist.

Und ja, da sind halt eben solche Dinge drin.

Ich weiß nicht, nee, stimmt, also die alle durchgehen muss man einem vielleicht nicht.

Das ist halt hübsch besser ist.

Ja, ich glaube, da steht auch am Anfang von der PEP-Version, kann das auch sein, also von dem Style-Guide, den es für Python auf der offiziellen Seite gibt.

Ja, ich weiß nicht, so kann gut sein.

Ja, dann halt solche Sachen wie explizit ist besser als implizit, ja.

Das ist halt auch, also man merkt auch dem Ding an, dass es so ein bisschen sich halt in viele Punkte sind, so eine Abgrenzung Richtung Pearl, glaube ich.

Also, einfach ist besser als komplex, ja.

Komplex ist besser als kompliziert.

Ja, flach ist besser als verschachtelt.

Ja, Spaß, was ich jetzt gar nicht jedes im Kontext übersetzen soll, aber es ist halt sozusagen Spaß ist better than dance.

Sozusagen lieber übersichtlich als.

Also nicht alles in eine Teile backen.

Genau, genau, sozusagen.

Ja, Lesbarkeit zählt.

Also zwischendurch mal leer zahlen lassen, gut, Lesbarkeit ungemein.

Ja, das ist überhaupt eines der Designziele bei Python gewesen, dass man das halt, weil Code einfach viel öfter gelesen als geschrieben wird, dass es vielleicht Sinn macht, das darauf zu optimieren, dass man das gut lesen kann.

Also wenn euer Nachbarn in den Abend aus dem Weg klingelt, dann noch lesen kann, was er da von Wahl geschrieben hat, dann seid ihr vielleicht bei Python besser aufgehoben als bei anderen Sprachen, ja?

Ja.

Genau, ja.

Spezialfälle sind nicht speziell genug, um die Regeln zu brechen, aber Pragmatismus besser oder Practicality ist besser als die reine Lehre als Purity.

Wie lange schreibst du deine Teil?

Ich habe das letztens erst geändert, glaube ich, auf 130.

Ich glaube, ich glaube 79, 130, 150 irgendwie.

Ich hatte es ganz lange, also bis vor kurzem habe ich tatsächlich auch 79 verwendet.

Also das für die Leute, die alte Monitore verwenden, die konnten auch nicht mehr lesen oder die halt gescherte Terminals verwenden mit mehreren Seiten, dass da 79 Jahren.

Ja, Terminals sind vor allen Dingen, genau.

Dann ist halt bei 80 Zeichen Schluss und genau, das wäre natürlich, deswegen habe ich das auch ganz lange gemacht, aber tatsächlich ist es so, dass heutzutage hat man diese Anwendungsfälle fast nicht mehr und die Monitoren.

Also sieht besser aus auf dem eigenen Monitor, oder?

Ja, es ist vor allen Dingen auch, es gibt halt viele Fälle, wo es halt schwierig wird, wenn man dann immer quasi nach der Anzahl Zeilen umbrechen, Zeichen umbrechen muss, dann muss man halt komisch rumformatieren.

Und dann lieber schön.

Und dann lieber schön und das bricht halt dann diese Begrenzung.

So gerade bei Tests finde ich, es ist sehr schwer, das einzuhalten, weil oft muss man halt lange Testnamen haben oder wenn das irgendwie sprechend sein soll und gut lesbar sein soll, dann.

Im gleichen Namen noch umgebrochen.

Oh, ja.

Ja, genau, dann kann man eigentlich nicht mehr umrechnen, dann wird es halt einfach lang.

Also daher bin ich jetzt, ich weiß nicht, glaube ich 130, wie die konkrete Zahl ist.

Vielleicht rede ich auch Unsinn.

Ich benutze das halt, ich formatiere meinen Code auch mit Black, also ich nehme das, was Black sagt.

So und kümmere mich nicht mehr drum.

Ich hoffe, die haben das sich irgendwie gut überlegt und ja.

Genau, was haben wir noch?

Ja, genau, Fehler sollten nicht einfach so still weggeworfen werden, sondern sollten immer sichtbar sein.

Also wir haben ja auch ein Python Assertion oder sowas.

Ich weiß nicht, ist das ein besonderes Feature oder gibt es das von anderen Spatten auch alles?

Assert, das ist ein, ja, das ist ein Keyword-Sprache, mit der man halt überprüfen kann, ob irgendeine Bedingung oder irgendwas wahr ist, was sein sollte.

Und wenn es halt nicht so ist, dann wirft das halt ein Fehler.

Kann man ganz gut testen.

Kann man einen Tests schreiben.

Genau.

Ja, Fehler sollten irgendwie nie schnell weggeworfen werden, außer man bringt sie zum Schweigen irgendwie explizit.

Ja, wenn man irgendwie mehrere Dinge zur Auswahl hat, sollte man irgendwie der Versuchen widerstehen, irgendwie einfach zu raten.

Es sollte nur einen und möglichst nur einen einzigen offensichtlichen Weg geben, wie man Dinge tun sollte.

Und das ist natürlich ganz klar, irgendwie ein Ding gegen Pearl, weil Pearl ist halt das Gegenteil davon.

Es gibt irgendwie Pearl ist auch, ich weiß, da gibt es auch irgendeinen, ja, du kannst es halt irgendwie so machen, es gibt viele Wege zum Ziel.

Du kannst es halt so machen, wie es dir am besten gefällt, was halt dann in der Praxis dummerweise dazu führt, dass es jeder irgendwie anders macht.

Und dass die Lesbarkeit natürlich extrem, weil jeder schreibt dann halt sozusagen sein Pearl-Idiom.

Und man kann halt nicht mehr so gut, also weil bei manchen Leuten war es so, wenn man das sich angeguckt hat, dann was ist das überhaupt?

Ich meine, teilweise ist das sehr schön.

Ich habe auch mal, ich habe das mal ein Buch gelesen von Damien Conway, ich weiß nicht genau, Higher Order Pearl oder sowas.

Auch ganz viele verrückte Sachen gemacht.

Und sowas habe ich dann mit Begeisterung verwendet und fand das total toll, was man alles für komplexe Geschichten irgendwie da in wenig Zeichen irgendwie unterbringen kann.

Aber ich glaube, ich würde das heute wahrscheinlich nicht mehr lesen können und meine Kollegen damals oder kurz danach konnten das wahrscheinlich auch nicht mehr lesen.

Oder du selber so zwei Stunden später.

Naja, zwei Stunden später ist halt dann vorbei.

Und das ist nicht ganz so gut, also es ist nicht optimal, dass es irgendwie da ist.

Da kann man noch was verbessern.

Solange ihr nachgearbeitet, dann steht man morgens wieder auf und dann so, oh, was habt ihr gestern da gemacht?

Ja, also das heutzutage.

Also dokumentiert immer schön euren Code, an Python könnt ihr damit sogar Doc-Tests machen, ne?

Das heißt, er testet dann selber auch das, was er dokumentiert.

Ja, weiß ich aber nicht, ob das so ein schlauer.

Also ob das so eine gute Idee ist, kann man machen, aber.

Ja, ich würde eher explizite Tests schreiben.

Und ich würde auch Py-Tests nehmen.

Es gibt halt auch das eingebaute Test-Framework von Python, das sich stark an J-Unit, glaube ich, einem Unit-Test Ding von Java irgendwie orientiert hat.

Ich weiß gar nicht, wie das heißt.

Und das ist komisch, weil es ist halt nicht so richtig pythonisch, weil es sind halt halt so die Dinge wie Konventionen, per Konvention sind halt die Methodennamen Camel-Case und nicht mit Underscore.

Normalerweise Underscore und da ist aber Camel-Case so mit Java und das ist halt, sieht komisch aus.

Und diverse andere Dinge sind auch eigenartig.

Das fühlt sich oft eher an, als würde man Java schreiben als Python und das ist halt eigentlich nicht schön.

Und deswegen würde ich eben nicht das eingebaute Ding nehmen, nicht das eingebaute Unitest-Framework, sondern wobei von den Features her, die können quasi das gleiche.

Du Doc-Testest ja jetzt nicht, oder?

Weil die DocTests ja einfach in den Dokumentationen dann irgendwie Funktionen testen.

Ich weiß gar nicht, ob das wie die ausgeführt werden oder welche Testrunner die dann halt ausführt.

Wenn man denen einstellen kann oder so, das kann auch alles gut.

Aber ich würde halt eher als Testrunner eigentlich mal eher Py-Tests verwenden.

Ja, ja, ich glaube, Py-Test nimmt auch die Doc-Tests damit an oder so.

Das kann gut sein.

Ich habe noch nie Doc-Tests gemacht.

Aber das ist auch alles nur geraten.

Keine Ahnung, muss man sich mal angucken.

Vielleicht ist es auch alles gut.

Aber ich würde auf jeden Fall, wenn man, das ist halt auch so eine unaufensichtliche Geschichte, wenn man vielleicht anfängt, dann denkt man sich so, ach, ich nehme mich ja das eingebaute Unitest-Framework.

It's a bad idea.

Deswegen werden wir send-off.

Also ihr seht schon.

Wenn wir jetzt irgendwie anfangen rumzustammen, dann ist das alles totale Grütze, was sie da gebaut haben, natürlich.

Ja.

Ja, now is better than never.

Ja, also das Do it, ne?

So ein bisschen das Nike-Prinzip, also einfach anfangen, machen, Prototyping.

Ob schon, niemals vielleicht oft besser sein könnte als genau jetzt.

Wenn die Implementation schwer zu erklären ist, ist es eine schlechte Idee.

Wenn die Implementation leicht zu erklären ist, könnte es sein, dass es eine gute Idee ist.

Ja, Namespace ist eine total tolle Idee.

Sollte man irgendwie mehr von machen.

Was ist an Namespace?

Vielleicht müssen wir es nochmal kurz sagen.

Sozusagen ein, ja, wie kann man das generell, also

korrekte Übersetzung, der Namensraum, also wenn man seine Variable genauso nennt wie die Nachbarvariable, dann ist es relativ schwierig, die dann irgendwann auseinanderzuhalten, weil wenn man das eine Kind ruft, kommen entweder beide oder nur eins von beiden oder gar nichts mehr.

Und dann kann man das mit einem Namensraum prefixen, sozusagen, in dem dann halt ein Name eindeutig ist.

Was so ein bisschen, ich weiß nicht, ob da ist eine gleiche Ironie, fürchte ich drin, weil bei Beheiten ist es halt nicht so schön getrennt.

Und wenn man jetzt zum Beispiel vom irgendein Modul Importstern sagt, dann überschreibt einem das gnadenlos halt irgendwie Dinge, die man selber definiert hat vielleicht.

Oder aus anderen Modulen oder so.

Man kann auch übrigens die ganze Standardbibliothek überschreiben, wenn man einfach die Namen verwendet.

Ja, ja, kann man alles machen.

Es gibt auch Leute, die dann, um das zu umgehen, sagen, die dann irgendwie Import dieses, vom das als irgendwie was ganz anderes, damit sie sich auf keinen Fall irgendwie sich Dinge überschreiben und so.

Ja, das ist alles so ein bisschen.

Aber im Grunde gibt es natürlich schon Namensräume in Python und das funktioniert eigentlich auch ganz gut.

Ja.

Wir sehen, auf Python haben wir jetzt so ein bisschen den Toolrennen auch noch näher gebracht.

Also was man darunter so ein bisschen versteht, wie man, ich sag mal, ganz besonders entspannen Python-Code schreibt und wie man da richtig rangeht.

Also tatsächlich müsst ihr es nicht zu komplex machen.

Ich glaube, wenn man die einfache Lösung ist besser.

Keep it short and simple.

Das ist, glaube ich, immer eine gute Idee.

Auch unabhängig von Python.

Aber dadurch wird es halt sehr lesbar und sehr korrigierbar.

Ihr könnt auch sehr gut damit kooperativ arbeiten mit anderen, weil ihr, glaube ich, relativ schnell verstehen werdet, was sie da denn so getan haben.

Ich meine auch da gibt es Ausnahmen, aber

das kann auch sein, dass das die immer gut ist, wenn man schnell versteht, was andere da getan haben.

Das könnte auch so, ja, wie das bei Douglas Adams oder so, irgendwie, als der Babelfisch eingeführt wurde und alle sich plötzlich verstanden haben, dass es gab den schlimmsten Krieg ever oder keine Ahnung.

Ja, der Metier hat das verlustige Sachen eingeführt, die ich letztens gesehen habe, irgendwie mit Lesen von Gesichtsmuskulatur und sowas, dann die Worte deines inneren Gedankens aufschreiben kann und so, das ist, ja.

Aber, naja.

Ja, alter Ego heißt das Ding.

Ach, okay.

Ja, da wird auch noch eine Menge interessante, werden noch eine Menge interessante Dinge passieren, glaube ich.

Jo, aber ansonsten, ich weiß nicht genau, sind wir so ein bisschen durch, ne, mit der Einführung, glaube ich.

Ja, ich würde tatsächlich sagen, wir sind langsam am Ende der ersten Folge angekommen.

Wir haben es quasi fast geschafft.

Also was haben wir jetzt gerade schon gemacht?

Wir haben das dann auf Python kennengelernt, kleines bisschen an die Einführungstools gegeben, so ein bisschen die Features der Sprache angeschaut.

Irgendwie, ja.

Ja, wie kann man einen Einstieg finden?

Wofür wird das eingesetzt?

Also falls ihr Fragen habt, wie gesagt, schreibt uns gerne an unsere E-Mail-Adresse.

Da kriegt ihr alles nochmal erklärt.

Ihr findet mit Sicherheit auch ganz viele im Internet, in Tutorials.

Es gibt ja unzählige schöne, spannende Seiten.

Die Suchbegriffe werdet ihr bestimmt schon finden dafür.

Ja.

Und genau, dann würde ich sagen, in den nächsten Episoden gehen wir dann halt mal so oder da machen wir halt so irgendwie ein Thema pro Episode und gucken einfach mal, dass wir das ein bisschen näher beleuchten.

Genau, nicht so der ganz allgemeine Schwank, sondern vielleicht tatsächlich irgendwie was Spezielles, irgendwie eine Module-Libliothek oder eine Technik oder irgendwie eins der Topics, die noch spannend sind.

Wenn ihr Vorschläge habt, wenn ihr irgendwas Besonderes hören wollt, kommt gerne.

Sagt davon was.

Der Jochen wird euch bestimmt was dazu erzählen können.

Und ich stelle Ihnen blöde Fragen.

Also so ist das.

Ja, und vielleicht schließen wir noch ein bisschen mit Veranstaltungshinweisen, Motornie.

Wir sind jetzt in Düsseldorf, also wenn ihr selber Veranstaltungshinweise habt, dann sagt doch bitte gerne Bescheid.

Dann können wir auch eure Veranstaltungen jetzt im deutschsprachigen Raum gerne promoten und hier vorstellen.

Bei uns ist nächste Woche, nächstes Wochenende jetzt hier Python Sprint.

Das ist immer eine tolle Gelegenheit, so ein bisschen Leute kennenzulernen.

Ich glaube, der ist diesmal schon voll und auch die Warteliste schon voll.

Aber er ist, glaube ich, zweimal im Jahr.

Gibt es bei Meetup oder bei Pi.df, also die Düsseldorf PiDF.

Super tolle Leute, immer ganz viele spannende Vorträge.

Schaut euch das auch einfach mal an und ja, tatsächlich zweimal im Jahr.

Also schaut einfach mal vorbei.

Ja, also wenn ihr die Events in eurer Nähe promotet, schickt ihr auch per E-Mail einfach an, hallo.pythonpodcast.de.

Ansonsten genau, was faszinierend geht, es gibt einmal die Python-User Group Düsseldorf PyDDF, die halt auch diese Sprints organisiert.

Es gibt einen Python-Fuh, das ist im lokalen Düsseldorf-Rikerspace im Karlsdorf.

Das ist einmal wöchentlich, das ist deutlich kleiner.

Es sind mehr so immer die gleichen Leute, die da hingehen.

Genau.

Aber ich finde, ist auch ganz toll.

Irgendwie sollte man sich nicht von abschränken lassen, dass es halt so ein bisschen, dass man so reinkommt und denkt, düster jetzt irgendwie oder ist es oder ist gerade irgendwas anderes.

Das sind alles sehr nette Leute.

Dann, aber genau, vielleicht wenn man gerade mit Leuten mal persönlich irgendwie ein bisschen mehr reden will, das ist vielleicht ein bisschen besser, weil so PyDDF ist eher vortragsorientiert und immer ein bisschen etwas größer haben.

Dann gibt es das Data Science Meetup in Düsseldorf, das ist auch mal sehr gut besucht, wo es häufig um Python-Themen auch geht.

Quantfinance bei Jesen Statistics, ja.

Schön fortgeschrittene Themen auch, ja.

Genau, und dann gibt es die Python-User Group Köln, apikeologen.

Einmal im Monat gibt es da ein Treffen, das ist auch immer meistens so 20, 30 Leute und gibt immer interessante Vorträge, danach geht man irgendwo Essen.

Ja, ach, bei PyDDF ist es auch so.

Also mehr im Umfeld, wie gesagt, wenn er irgendwo aus, weiß ich nicht, schieß mich tot, Wien, München, von der Ostsee, an der Bürgermark, irgendwas finde, dann sagt Bescheid.

Stelle mich hier gerne auch vor.

Ja.

Ich kann nur sagen, Jochen vielen Dank.

Ja, danke doch.

Ein bisschen schlau geworden.

Tja.

Und euch.

Ich hoffe, die Hörer haben auch ein bisschen Spaß gehabt.

Dann bis zur nächsten Folge.

Bis zum nächsten Mal.

Tschö.