Heute habe ich die ersten Vorträge auf der EuroPython 2021 gehört.
Im Folgenden teile ich kurz meine Einschätzung zu den besuchten Vorträgen mit. Die Vorträge waren ausgeschrieben für Anfänger, und boten im Regelfall einen Überblick zum angebenen Thema. Daher hat man sich im Nachhinein sowieso noch eingehender mit dem entsprechenden Thema zu befassen, wenn es zum tatsächlichen Einsatz kommt. Dabei können meine Notizen, die verständlicherweise nicht den kompletten Inhalt wiedergeben können, durchaus als Stichwortgeber nützlich sind.
Meine Zusammenfassung und Einschätzung des Vortrags
„Python Versions and Dependencies Made Easy“ (von Sebastian Witowski)
Dem Vortrag konnte ich gut folgen, obwohl er in Englisch gehalten wurde. Dieser Vortrag war zum Einen eine gute Wiederholung des mir bereits Bekannten, zum Anderen gab es aber auch ein paar neue Informationen, die ich mir sicher noch genauer anschauen werde.
Meiner Meinung nach, war der Vortrag auch nützlich für Anfänger in dem Thema. Die Informationen wurden strukturiert vorgetragen und waren gut nachvollziehbar. Man hat einen guten kurzen Überblick erhalten. Die einzelnen Befehle bzw. den sinnvollen Ablauf erarbeitet man sich sowieso später im tatsächlichen Einsatz.
Meine Notizen zum Inhalt
Oft ist ein System-Python vorinstalliert, dieses sollte man niemals verwenden!
In der Entwicklung kommt es häufig vor, dass man unterschiedliche Versionen von Python, und vor allem von Packages verwendet (oder verwenden muss).
Alte Projekte nutzen z.B. noch eine alte Python 3-Version oder sogar noch Python 2. Noch unübersichtlicher wird es mit Packages, wenn man sie systemmäßig, also global installiert. Dabei sammeln sich viele Installationen an, die man im Regelfall niemals alle für das aktuelle Projekt benötigt.
Deshalb ist es sinnvoll virtuelle Umgebungen zu verwenden.
pyenv (oder pyenv-win für Windows) hilft verschiedene Python Versionen einfach zu installieren. Man kann damit die Python-Version setzen für global (für den kompletten Rechner), local (im aktuellen Verzeichnis) und shell (in aktueller shell Session).
venv ermöglicht verschiedene Package-Versionen (installiert mit pip) zu verwenden, weil eigene Verzeichnisse verwendet werden, und nicht das globale System-Verzeichnis.
python -m venv .venv (<- Verzeichnis-Name) – erzeugt eine virtuelle Umgebung (das Verzeichnis .venv im aktuellen Ordner)
source .venv/bin/activate – aktiviert die Umgebung
jetzt benötigte Packages installieren – jetzt kann man Packages installieren, und mit der Umgebung arbeiten
deactivate – beendet die virtuelle Umgebung
In Gegensatz zu venv, erzeugt virtualenvwrapper nicht in jedem Projekt ein Verzeichnis, sondern verwaltet alle virtuellen Umgebungen zentral.
virtualenvwrapper (wird mit pip installiert) speichert alle virtuellen Umgebungen in ~/.virtualenvs/
mkvirtualenv – erstellt virtuelle Umgebung
workon – aktiviert die Umgebung
lsvirtualenv – zeigt alle Umgebungen an
rmvirtualenv – löscht Umgebung
Wenn man venv oder virtualenvwrapper einsetzt, kann man pipx verwenden, um manche Packages sinnvollerweise global zu installieren (z.B flake8, pytest usw), wenn sie standaradmäßig in fast allen Projekten benötigt werden.
pipx install – installiert package
pipx inject venv – installiert Package in die angegebene virtuelle Umgebung
pipx list – zeigt alle intsallierten Packages
pipx uninstall – deintsalliert Package
pipx upgrade-all – aktualisiert alle Packages
Installiert man pipx mit pip verwendet es das System-Python.
Verwendet man ein pipx, das mit pipx-in-pipx installiert wurde, dann wird das Python übernommen, mit dem pipx-in-pipx installiert wurde.
Meine Zusammenfassung und Einschätzung des Vortrags
„Continuous Documentation for your code“ (von Anastasiia Tymoshchuk)
Beeindruckend, wie man Leuten ein „trockenes“ und ungeliebtes Thema interessant vermitteln kann. Und es lag nicht nur an der Sprecherin im Allgemeinen, sondern in der Art und Weise des Vortrags, alles in eine kleine Geschichte zu verpacken und es so anderen näher zu bringen.
Auch bei diesem Vortrag habe ich einige Punkte wiedergefunden, mit denen ich mich bereits befasst habe, und selbst die neuen Themen wie z.B. Sphinx oder ReadTheDocs habe ich schon auf dem Radar gehabt.
Meine Notizen zum Inhalt
Erstellt man Software, ergeben sich im Grunde immer folgende Fragen: Wann ist der Code gut genug? Wielange „hält“ er, ein Jahr, mehrere Jahre? Wann und wie oft sind Änderungen notwendig?
Man sollte versuchen, in die Zukunft zu blicken, und zu ermitteln, was wird benötigt, welche Bedeutung hat der Code, und was ist zu tun, um die Anwendung zu installieren, einzurichten und zu starten.
Vier Punkte sind zu beachten
problemorientierter Ansatz – Was ist zu tun? How-to Anleitung, Setup, Konfiguration (z.B. in readme.md)
lernorientierter Ansatz – Wie macht man etwas? Tutorials, allgemeiner Ablauf, z.B. Installation und Konfiguration von sphinx
verständnisorientierter Ansatz – Warum macht man etwas? Erklärung und Motivation
informationsorientierter Ansatz – Was ist wo, und in welcher Beziehung steht es? Referenz (z.B. Code Reference von Sphinx)
Beliebte Aussage der Non-Dokumentierer: Dokumentation kann nicht veralten, wenn man erst gar keine schreibt.
Warum Dokumentation?
- Leute vergessen Dinge
- Leute haben den Code zurückgelassen (sind nicht mehr verfügbar)
- neue Leute kommen hinzu
Ausführliche Informationen zum Thema unter The documentation system
Für Python kann man mit Sphinx starten, auch wenn es am Anfang etwas aufwendiger ist, sich einzuarbeiten und es zu verwenden.
Bei größeren Projekten lohnt es sich ggfs. ReadTheDocs zu verwenden.
Man kann Leute zwar nicht zwingen eine Dokumentation zu lesen, aber man sollte darauf hinwirken, dass sie eine schreiben. Oft gehört es nicht zur Team-Kultur, in dem Fall sollte man versuchen in kleinen Schritten ein Umdenken einzuleiten.
Meine Zusammenfassung und Einschätzung des Vortrags
„Pydon’ts“ (von Rodrigo Girão Serrão)
Meiner Meinung nach war dies ein weiterer nützlicher Vortrag für Python-Anfänger. Die Präsentation war gut nachvollziehbar und übersichtlich. Man hat einen guten Einstieg erhalten, wie man Code überarbeiten und eleganter gestalten kann. Es wurde eine kleine Funktion mit ein paar Zeilen Code mit for-Schleife und if-Konstrukt umgewandelt in einen Einzeiler.
Meine Notizen zum Inhalt:
Eleganz ist kein überflüssiger Luxus, aber der Faktor zwischen Erfolg und Scheitern.
Es gibt so viele nützliche Frameworks in Python, deshalb lernen viele Leute oft nicht mehr die Basics.
Anhand einer Übungsaufgabe wurde die Code-Verbesserung besprochen und erklärt:f("abcdefg")
>>> 'AbCdEfG'
vorher:
def myfunc(a):
empty=[]
for i in range(len(a)):
if i%2==0:
empty.append(a[i].upper())
else:
empty.append(a[i].lower())
return “”.join(empty)
nachher:
def alternate_casing(text):
return “”.join([
char.lower() if idx % 2 else char.upper()
for idx, char in enumerate(text)
])
Code style matters, denn damit wird es einfacher, den Code zu lesen.
Code wird häufiger gelesen als geschrieben.
PEP behandelt an vielen Stellen Whitespaces. Man sollte genügend Space verwenden, denn das gibt dem Code mehr Luft „zu atmen“.
Naming matters. Sinnvolle Namen für Variablen und Funktionen zu vergeben, ist mit das Schwierigste in der Programmierung.
Man sollte immer wieder eigenen Code lesen, und nachdenken über den Inhalt, was man verbessern könnte.
import this um „Zen of Python“ zu erhalten, die 19 Gebote von Python.
Im try-except nur den notwendigen Code einbringen, sonst wird evtl. mehr abgefangen, als beabsichtigt war.
Nesting vermeiden, es erzeugt semantische Abhängigkeiten. Je weniger, desto besser. Es kann daher sein, dass man sogar ein paar Zeilen Code mehr schreibt, aber dafür ist es lesbarer.
Truthy and Falsy, man sollte wissen, welchen bool-Wert Python-Objekte zurückgeben. So sind z.B. immer False: 0, 0.0, None, „“, [], {}, tuple(), set()
Weitere Stichworte zur Code-Vereinfachung: enumerate, conditional expression, list comprehensions
Fazit
Nach dem ersten Tag kann ich nur feststellen, dass sich die Python-Talks für mich gelohnt haben. Durch den bisherigen Einsatz von Python habe ich sicherlich bereits ein gutes Basiswissen, so dass ich den Vorträgen gut folgen konnte, es fehlt eben nur die Erfahrung durch den täglichen Einsatz.
Auf der anderne Seite waren die Vorträge eben auch für Anfänger gedacht. Ich habe zwischendurch mal bei anderen Vorträgen (intermediate) hineingeschaut, und da wurde ich natürlich sofort von Fachbegriffen überfahren. Da ich mir alle Kurse im Archiv anschauen kann, komme ich vielelicht später auf den ein oder anderen Vortrag zurück.
Es war für mich beeindruckend, und ich bin angenehm überrascht, dass es noch Leute gibt, die es schaffen in ca. 25 Minuten anderen Leuten Informationen verständlich beizubringen. So war z.B. der letzte Talk der erste öffentliche Vortrag des Sprechers überhaupt auf einer Konferenz gewesen, und da kann sich mancher ein Beispiel daran nehmen. In den letzen 20 Jahren bei aktuellen Tätigkeit habe ich nicht annähernd so brauchbare Beiträge erlebt.
Ebenso spürt man bei den Leuten, die die Vorträge halten, eine Begeisterung fürs Thema. Das sind Pythonistas. Obwohl sie teilweise bereits etliche Jahre beruflich Python verwenden, lassen sie sich trotzdem noch dazu herab, und erklären Anfängern die elementaren Dinge in einfacher Weise. Da hat man sofort das Gefühl, mit den Leuten möchte man zusammenarbeiten. Etwas, das ich bei der aktuellen Tätigkeit mittlerweile vermisse. Insofern hat die Konferenz bisher für positive Eindrücke und Ergebnisse gesorgt, und mich in meinem Entschluss weiter bestärkt auf Python zu setzen, und nach einer neuen interessanten Aufgabe zu suchen.