Pythons wahre Superkraft
(youtu.be)Dies ist eine Zusammenfassung der Keynote „Pythons wahre Superkraft“, die Hynek Schlawack auf der PYCON UK 2025 gehalten hat.
Der Sprecher stellte zu Beginn der Präsentation kurz seinen Werdegang vor und erwähnte dabei insbesondere die „hasserfüllte Freundschaft“, die er in 14 Jahren Engagement in der PyCon-Community erlebt hat.
Der Übergang von Python 2 zu 3 (The Python 2 to 3 Migration)
- Hintergrund: Python 3.0 wurde erstmals 2008 veröffentlicht und war nicht für den allgemeinen Einsatz gedacht, sondern sollte die Ziele von Python aufzeigen und Feedback einholen. Ab Python 3.2 wurde die Nutzung empfohlen.
- Wichtige Änderungen:
- String-Verarbeitung: Python 3 änderte den Standardtyp für Strings von maschinenfreundlichen Bytes zu menschenfreundlichem Unicode.
- Entfernung impliziten Verhaltens: Viele implizite Verhaltensweisen, auf die sich Entwickler in Python 2 versehentlich verlassen hatten – etwa Vergleiche zwischen Strings und Zahlen –, wurden entfernt. Diese führten zu schwer zu debuggenden Bugs.
- Verbesserte Internationalisierung: Python-2-Codebasen waren voller Unicode-Decode-Fehler, und Python 3 verbesserte dies und machte die Sprache internationaler.
- Schwierigkeiten des Übergangs:
- Kosten für die Community: Das Portieren des gesamten Ökosystems auf Python 3 war mit enormen Kosten verbunden. Viel Software musste portiert werden, und Testabdeckung war damals noch nicht allgemein üblich.
- Entwicklung gemischter Codebasen: Ein Konsens darüber, wie man hybride Codebasen schreibt, die sowohl unter Python 2 als auch Python 3 laufen, entstand erst 2012 mit der Veröffentlichung von Python 3.3.
- Sprach-Moratorium: Zwischen Python 3.0 und 3.3 wurden kaum neue Features hinzugefügt, sodass Entwickler wenig Motivation hatten, auf Python 3 umzusteigen.
- Unsicherheit: Es war unklar, ob Python 3 zur dominierenden Version werden würde; ein Scheitern wie bei Perl 6 war ebenfalls denkbar.
- Warum Python überlebt hat:
- Zustrom neuer Nutzer: Python gewann in einer Zeit, in der andere Sprachen wie Go und Rust wuchsen, mehr neue Nutzer hinzu, als es bestehende verlor.
- Wissenschafts- und Engineering-Community: Wissenschaftler und Ingenieure nutzten Python schon lange, und seit Mitte der 2010er Jahre stieg die Popularität von Python im Bereich Data Science stark an. Heute verwendet mehr als die Hälfte der Python-Nutzer Python für Datenexploration und -verarbeitung.
- Bestehendes Ökosystem: Ein starkes Ökosystem wissenschaftlicher Rechenbibliotheken wie NumPy war bereits vorhanden.
- Einfache Interaktion mit anderen kompilierten Sprachen: Python lässt sich leicht mit anderen kompilierten Sprachen kombinieren und kann als „Klebstoff“ dienen, der High-Performance-Komponenten verbindet, die in C, C++, Fortran oder Rust geschrieben sind.
- Exploratives Programmieren: Python eignet sich sehr gut für exploratives Programmieren über die interaktive Shell (REPL) und Werkzeuge wie Jupyter Notebook.
- Gradualität (Graduality): Python bietet verschiedene Stufen von Strenge an. Entwickler können in der Experimentierphase flexibel arbeiten und in der Produktionsphase die Strenge mit Tools wie Type Hints, Lintern und Tests erhöhen. Außerdem lässt sich Python auf sehr unterschiedliche Use Cases anwenden – vom Start in einem Jupyter Notebook bis zur Skalierung zu einem Webservice.
Pythons wahre Superkraft: Gradualität (Graduality)
- Python hat nicht nur eine niedrige Einstiegshürde, sondern bietet auch mehrere hohe Obergrenzen, sodass Nutzer es je nach Bedarf flexibel einsetzen können.
- Die zwei Seiten der Gradualität:
- Positive Seite: Nutzer können das gewünschte Maß an Strenge und Komplexität wählen. Beispielsweise kann man beim Schreiben von Skripten frei ohne Type Hints coden und bei großen Anwendungen strikte Typprüfung einsetzen.
- Negative Seite: Wenn man einem System Sonderfälle oder Ausnahmen hinzufügt, schafft das kurzfristig Bequemlichkeit für einzelne Nutzer, erhöht langfristig aber die Gesamtkomplexität des Systems. Es wird betont, dass „einfach“ nicht immer „simpel“ bedeutet – und genau das zeigt sich beim Python-Packaging.
Ein Beispiel für das Packaging-Problem (Packaging Problem Example)
- Es gibt eine „ad hoc“-Methode und eine Paket-Methode, um Python-Anwendungen zu strukturieren. Die Paket-Methode ist besser definiert und bringt eingebaute Tooling-Unterstützung mit, aber aus historischen Gründen wird auch die ad-hoc-Methode weiterhin unterstützt.
- Dadurch werden Probleme wie
sys.pathschwer verständlich, und Funktionen wiepip install --userverursachen Probleme im globalen Namespace, was das Debugging erschwert. - Neue Tools wie UV unterstützten anfangs nur die Paket-Methode, mussten letztlich aber auch ad-hoc-Projekte unterstützen, wodurch die Komplexität zunahm.
- Solche „attractive nuisances“ bieten kurzfristig Komfort, verursachen langfristig aber erhebliche Kosten für die Community.
Softwarearchitektur (Software Architecture)
- Es wird darauf hingewiesen, dass es in der Python-Community zu wenig Diskussion über Softwarearchitektur gibt, was auf eine Abneigung gegen „Enterprise Patterns“ und die „Angst davor, zu Java zu werden“ zurückgeführt wird.
- Notwendigkeit: Um komplexe Softwaresysteme zu bauen und zu warten, ist die Diskussion über Softwarearchitektur – also über das Organisieren und Verwalten von Modulen, Schichten und Interaktionen – wichtig.
- Lösungen:
- Die Python-Community sollte vermeiden, Gespräche mit Begriffen wie „pythonic“ oder „unpythonic“ abzuwürgen.
- Man sollte Best Practices aus Communities anderer Sprachen lernen und anwenden, etwa Domain-Driven Design.
- Mehr Menschen sollten Wissen über Softwarearchitektur teilen, entsprechende Inhalte erstellen und sich auf Lösungen konzentrieren.
Fazit (Conclusion)
- Man sollte Python gegenüber nicht verunsichert sein, sondern die vielen Arten begrüßen, Python zu schreiben.
- Man sollte neue Stile und Tools ausprobieren, um den eigenen Denkrahmen zu erweitern.
- Optionen haben ihren Preis, daher sollte man sorgfältig bedenken, welche Auswirkungen bestimmte Features auf die gesamte Community haben.
- Neben der Arbeit daran, einfache Dinge leicht zu machen, sollte man sich stärker dafür einsetzen, komplexe Dinge möglich zu machen.
- Es braucht mehr Gespräche über Softwarearchitektur und die Bereitschaft, dogmatische Denkweisen zu hinterfragen, um Python in eine bessere Zukunft zu führen.
Diese Präsentation spannt den Bogen über Vergangenheit, Gegenwart und Zukunft der Python-Community, betont die wahre Stärke der Sprache – „Gradualität“ – und liefert tiefe Einsichten in die Herausforderungen der Community und die kulturellen Hürden, die sie überwinden muss.
Wenn Sie das Video sehen möchten, finden Sie es hier: https://youtu.be/gDvwRpl9erE
3 Kommentare
Es wäre viel bequemer, wenn ein moderner Paketmanager im Stil von
uvzum Standard würde, aber das dürfte wohl ziemlich schwierig sein..In den ersten Semestern war gerade noch Python 2 etwas weiter verbreitet, aber bis zum Abschluss waren dann alle zu Python 3 gewechselt – so erinnere ich mich jedenfalls.
Wer beruflich programmiert, beherrscht in den meisten Fällen mindestens eine weitere Sprache, selbst wenn er hauptsächlich Python nutzt.
Ich kann nicht nachvollziehen, warum man ständig Funktionen oder Eigenschaften anderer Sprachen einführen will, während man gleichzeitig sagt, Python müsse besser werden.
Es scheint dabei übersehen zu werden, dass gerade die Schwächen von Python auch ein Grund für seine Popularität waren.
Python wird zunehmend seltsam komplex und anspruchsvoll.
Es wirkt, als würden die Vorteile von Python verschwinden.
Anstatt zu versuchen, Python wie Java zu machen, könnte man doch einfach je nach Bedarf Java verwenden.
Und wenn nicht Java, gibt es ja auch noch Kotlin oder Scala.
Trotzdem glaube ich nicht, dass Python untergehen wird.
Denn eine Sprache, mit der man so unkompliziert programmieren kann, gibt es praktisch nicht.