Im Vortrag „Faceoff Fun with Python Frameworks: FastAPI vs Flask“ (von Tonya Sims) (noch vom Vortag) wurden die beiden Frameworks gegenübergestellt und in einzelnen Punkten verglichen. Am Ende war es ein Kopf-an-Kopf-Rennen. FastApi hat bereits nützliche Packages „eingebaut“, bei Flask sind sie zusätzlich zu installieren. Je nachdem was man machen möchte, wählt man das passende Framework aus.
Ein paar Kriterien sind z.B. für
Flask
kampferprobt (battle tested)
schneller Prototyp (quick prototype)
einfache Webanwendung (simple web application)
FastAPI
Geschwindigkeit (speed)
reduziert Fehler und Bugs (reduces errors and bugs)
API-Entwicklung (API development)
Die Referentin würde derzeit eher FastAPI bevorzugen. Es ist aktueller, und bringt bereits verschiedene Funktionen mit, die bei Flask zusätzlich zu installieren wären. Andererseits hat Flask mit der aktuellen Version 2.0 nachgezogen, so dass keine eindeutige Empfehlung gegeben werden kann.
Im Vortrag „Thoughts on the Future of Python“ (von Marc-Andre Lemburg) hat der Referent seine persönliche Einschätzung und Meinung vertreten.
Python ist seit rund 10 Jahren unaufhörlich auf dem Vormarsch. Sehr viele verschiedene Communities arbeiten an und für Python. Viele große Firmen verwenden bereits Python. Speziell im Bereich Data Science ist Python mittlerweile nicht mehr wegzudenken. Im übrigen Business Bereich führt noch Java, denn „Nobody ever got fired for choosing Java.“
Im Trojan Horse-Ansatz sieht der Referent eine gute Möglichkeit, um damit in Bereichen wie z.B. ERP, MDM, BI, ETL oder ECM Fuß zu fassen, und Python weiter zu etablieren.
„Python Anti-Patterns“ (von Vinicius Gubiani Ferreira) gehen in Richtung Clean Code, und es wurde auf Punkte hingewiesen, die man möglichst vermeiden sollte. In der Kürze des Vortrags wurden nur ein paar Anti-Pattern erläutert.
Eine kleine Auswahl von Anti-Pattern:
- es ist kein Exception Type spezifiziert
- es wird kein Context Manager für die Dateiverabreitung verwendet (-> with open)
- es wird mehr als ein Variablentyp in Funktionsaufrufefn zurückgegeben (z.B. return None, und an anderer Stelle return „String“)
- es wird ein Potected Member von außerhalb der Klasse aufgerufen (also eine _-Methode)
- es wird auf eine build-in Funktion zugewiesen (z.B. list = [1, 2, 3])
- es werden Tabulatoren verwendet, oder Tabs mit Spaces gemischt
- es wird für eine for-Schleife kein else in passenden Fall verwendet (es gibt tatsächlich ein for – else)
- es wird kein get() verwendet, um ggfs. den Default-Wert von einem dict zu erhalten
- es werden Wildcard Imports verwendet
- es wird das global Statement verwendet
- es werden einzelne Buchstaben verwendet, um Variablen zu benennen
- es wird in Vergleichen der falsche Weg verwendet, um auf True zu prüfen (z.B. is not type, anstatt isInstance())
- es wird kein NamedTuple in Funktionen zurückgegeben
Eine ausführliche Liste mit Anti-Pattern findet man im „The Little Book of Python Anti-Patterns“
„Writing Better Documentation for Developers“ (von Meredydd Luff) war eine Ergänzung zum Vortag von gestern. In diesem Fall ging es speziell um Dokumentation für Entwickler (Developer).
Bei der Betrachtung zum Thema Dokumentation solte nicht vergessen werden, welches Projekt dokumentiert wird. Ein Open Source-Projekt erfordert sicher eine andere „öffentliche“ Dokumentation als ein firmeninternes Projekt. In diesem Vortrag ging es eher um eine Dokumentation, die auch für die Öffentlichkeit zugänglich ist. Denn als Einstieg wurden folgende Punkte genannt, was man mit der Doku erreichen möchte:
Wir wollen, dass Software-Entwickler
unser Projekt finden. -> docs are content marketing
entscheiden, dass es ist nützlich. -> docs define your product
lernen es zu benutzen. -> docs are your user interface
Probleme auf dem Weg lösen.
Zu den bisher vier erwähnten Dokumentation kommen nach Meinung des Referenten noch zwei weitere Bereiche. Die Reference teilt sich auf, in eine Referenz und in API Docs. Zusaötzlich komt der Bereich Q&A hinzu.
Die Referenz beschreibt die Software selbst: APIs, Klassen, Funktionen und so weiter
API-Dokumente sind keine Referenzdokumente! API-Dokumente beschreiben Code-Objekte.
Referenz
beschreibt Systeme
erzählt eine Geschichte
ist logisch strukturiert
API-Dokument
beschreibt Code
ist stand alone
wird automatisch generiert
Hinzu kommt die Kommunikation mit den Nutzern: Fragen sind Fehlerberichte – Antworten sind Patches. Daraus ergibt sich der Q&A-Bereich in der Doku.
Your docs are your
- user interface
- marketing
- definition of your product
Act like it!
In „Finding Magic in Python“ (von Anna-Lena Popkes) wurden ein paar Python-Basisthemen vorgestellt.
Anhand eines kleinen Software-Beispiels gab es eine kurze Einführung in OOP. Es wurde die init-Methode, Vererbung und der Unterschied der Methoden (Instanz, Klasse und Static) vorgestellt. Außerdem wurde die Möglichkeit gezeigt, dass man auch in Python Abstrakte Klassen erstellen kann (import abc).
Es wurden noch Beispiele für DefaultDict, Tuple / NamedTuple und Decorator gezeigt.
Die Themen konnten in der Kürze der Zeit nur kurz vorgestellt und angerissen werden, gerade das OO-Thema ist sehr umfangreich, so dass es sich hier nur um eine kleine Präsentation handelte, um zu zeigen, was auch mit Python möglich ist.
Fazit
Auch der zweite Tag war gut geeignet, um ein paar Punkte wieder in Erinnerung zu rufen, so wie ein paar neue Erkenntnisse zu sammeln.
Es zeigt sich, dass es sinnvoll ist, sich zuvor das Angebot anzuschauen, und die auf den ersten Blick wichtigsten Vorträge herauszusuchen.
Im Regelfall gehen die Vorträge über 25 Minuten, mit weiteren 5 Minuten für Fragen und Antworten. Hier zeigt sich, dass die Faustformel, nach der sich Menschen im Idealfall ca. 20 – 25 Minuten konzentrieren können, stimmt. Je nachdem wie viel Informationen neu für den Zuhörer sind, merkt man schnell, dass man nach einem Vortrag ein kleine Pause braucht. Mehrere Vorträge hintereinander zu verfolgen, erfordert einen hohen Aufwand an Energie und Konzentration, vor allem dann, wenn man sich noch ein paar Notizen machen möchte während des Vortrags.
Etwas entspannter wird es, wenn man ein entsprechendes Ticket erworben hat, mit dem die Möglichkeit besteht, sich im Nachhinein die Videos noch einmal in Ruhe und bei Bedarf anschauen zu können. Dann hat man auch den Vorteil, dass man sich Vorträge anhören kann, die man verpasst hat.