Zen of Python: 19 Leitsätze für lesbaren Code

Das Zen of Python ist eine Sammlung von 19 kurzen Leitsätzen von Tim Peters. Sie beschreiben, wie lesbarer und einfacher Python-Code aussehen soll. Du kannst sie dir in Python jederzeit mit import this anzeigen lassen.

Was ist das Zen of Python?

Ich bin zum ersten Mal im Buch „Python Crashkurs“ von Eric Matthes darüber gestolpert und habe danach im Netz mehr darüber gelesen. Tim Peters, einer der frühen Python-Entwickler, hat die Sätze 1999 auf der Python-Mailingliste veröffentlicht. 2004 wurden sie als PEP 20 (öffnet in neuem Tab) festgehalten, eine PEP ist ein offizielles Python-Dokument. Dort ist von 20 Leitsätzen die Rede, aufgeschrieben sind nur 19. Den zwanzigsten hat Tim Peters für Guido van Rossum offen gelassen, den Erfinder von Python. Code, der diesen Sätzen folgt, nennt man oft „pythonic“.

Öffne ein Terminal, starte Python mit python3 (unter Windows python) und gib das hier ein:

import this

Ein zweites import this in derselben Sitzung zeigt nichts mehr an, weil Python ein Modul nur einmal lädt. Willst du den Text noch einmal sehen, startest du Python neu.

Die 19 Regeln

Eine offizielle deutsche Fassung gibt es nicht, die Übersetzungen hier sind frei.

Lesbarkeit

1. Beautiful is better than ugly.
   Schön ist besser als hässlich.
   Gemeint sind saubere Abstände, sinnvolle Namen und eine klare Struktur.
2. Explicit is better than implicit.
   Ausdrücklich ist besser als stillschweigend.
   Schreib hin, was passieren soll, statt es den Leser erraten zu lassen. import math und danach math.sqrt() zeigt sofort, woher die Funktion kommt.
3. Simple is better than complex.
   Einfach ist besser als komplex.
   Wenn es eine einfache Lösung gibt, nimm sie.
4. Complex is better than complicated.
   Komplex ist besser als kompliziert.
   Eine große Aufgabe darf aus vielen Teilen bestehen, solange jedes Teil verständlich bleibt.
5. Flat is better than nested.
   Flach ist besser als verschachtelt.
   Jede zusätzliche Ebene aus if oder for musst du beim Lesen im Kopf behalten. Genau damit hatte ich oft Probleme.
6. Sparse is better than dense.
   Luftig ist besser als dicht.
   Lieber drei kurze Zeilen als eine lange, in die alles hineingepresst ist.
7. Readability counts.
   Lesbarkeit zählt.
   Code wird viel öfter gelesen als geschrieben, auch von dir selbst ein paar Wochen später.

Regeln und Ausnahmen

8. Special cases aren’t special enough to break the rules.
   Sonderfälle sind nicht besonders genug, um die Regeln zu brechen.
   Ein Spezialfall ist kein Grund, alles anders zu machen als im Rest des Programms.
9. Although practicality beats purity.
   Allerdings schlägt Praxis die reine Lehre.
   Wenn die saubere Lösung nur Umwege bringt, darf die praktische gewinnen.

Fehler

10. Errors should never pass silently.
    Fehler sollten nie stillschweigend durchgehen.
    Ein Fehler, den du sofort siehst, ist leichter zu finden als einer, der später woanders Ärger macht. So meldet das frozendict aus Python 3.15 jede Änderung sofort.
11. Unless explicitly silenced.
    Außer, sie werden ausdrücklich zum Schweigen gebracht.
    Mit try und except darfst du einen Fehler gezielt abfangen. Ein except: pass, das jeden Fehler verschluckt, ist das Gegenteil.
12. In the face of ambiguity, refuse the temptation to guess.
    Wenn etwas mehrdeutig ist, widersteh der Versuchung zu raten.
    Python rechnet "3" + 4 nicht irgendwie aus, sondern meldet einen TypeError. Du entscheidest, ob du "34" oder 7 willst.

Entscheidungen

13. There should be one— and preferably only one —obvious way to do it.
    Es sollte einen, am besten genau einen, offensichtlichen Weg geben.
    Ganz eingehalten hat Python das selbst nicht: Für Text mit Variablen gibt es +, %, format() und f-Strings. Für einfache Ausgaben ist der f-String heute der naheliegende Weg.
14. Although that way may not be obvious at first unless you’re Dutch.
    Auch wenn dieser Weg anfangs nicht offensichtlich ist, außer du bist Niederländer.
    Gemeint ist Guido van Rossum, der Niederländer, der Python erfunden hat. Das sollte man wissen, sonst versteht man den Witz nicht.
15. Now is better than never.
    Jetzt ist besser als nie.
    Fang an, auch wenn die Lösung noch nicht perfekt ist.
16. Although never is often better than right now.
    Allerdings ist nie oft besser als sofort.
    Manchmal ist es besser, eine Sache erst in Ruhe zu durchdenken, statt sie sofort hinzuschreiben.
17. If the implementation is hard to explain, it’s a bad idea.
    Wenn sich die Umsetzung schwer erklären lässt, ist sie eine schlechte Idee.
    Wenn du nicht in zwei Sätzen sagen kannst, was dein Code macht, ist er wahrscheinlich zu verdreht.
18. If the implementation is easy to explain, it may be a good idea.
    Wenn sich die Umsetzung leicht erklären lässt, ist sie vielleicht eine gute Idee.
    Auch eine einfache Idee kann am Ziel vorbeigehen.

Namensräume

19. Namespaces are one honking great idea — let’s do more of those!
    Namensräume sind eine riesig gute Idee, davon sollten wir mehr machen.
    Ein Namensraum trennt Namen voneinander, zum Beispiel durch Module. math.floor() und eine eigene Funktion floor() kommen sich so nicht in die Quere. Mehr dazu steht in der Python-Doku zu Namensräumen (öffnet in neuem Tab).

Flat is better than nested: mein Fehler mit verschachtelten Abfragen

Gegen diesen Satz habe ich am häufigsten verstoßen. Ich bin bei Abfragen oft in viele Ebenen gerutscht, statt die Abfrage sauber zu bauen und am Ende mit zwei Ebenen auszukommen. Meist ging es, soweit ich mich erinnere, um Eingaben. Als Beispiel ein kleines Zahlenraten mit Zahlen von 1 bis 100:

def lies_zahl(text):
    if text != "":
        if text.isdigit():
            zahl = int(text)
            if 1 <= zahl <= 100:
                return zahl
            else:
                print("Die Zahl muss zwischen 1 und 100 liegen.")
        else:
            print("Bitte nur Ziffern eingeben.")
    else:
        print("Du hast nichts eingegeben.")
    return None

Das funktioniert, aber jede Prüfung schiebt den Code eine Ebene weiter nach rechts. Die Fehlermeldungen stehen weit weg von ihrer Prüfung, und du musst zählen, welches else zu welchem if gehört.

Heute schreibe ich lieber zwei Funktionen, als den Code unnötig tief zu verschachteln. Die erste sucht nur den Fehler, die zweite entscheidet, was damit passiert:

def fehler_in_eingabe(text: str) -> str:
    if text == "":
        return "Du hast nichts eingegeben."
    if not text.isdigit():
        return "Bitte nur Ziffern eingeben."
    if not 1 <= int(text) <= 100:
        return "Die Zahl muss zwischen 1 und 100 liegen."
    return ""


def lies_zahl(text: str) -> int | None:
    fehler = fehler_in_eingabe(text)
    if fehler:
        print(fehler)
        return None
    return int(text)


for eingabe in ["", "abc", "250", "42"]:
    print(lies_zahl(eingabe))

Du hast nichts eingegeben.
None
Bitte nur Ziffern eingeben.
None
Die Zahl muss zwischen 1 und 100 liegen.
None
42

fehler_in_eingabe() geht die Prüfungen nacheinander durch und hört beim ersten Fehler auf. Jede Prüfung steht direkt neben ihrer Meldung, und keine Zeile ist tiefer als zwei Ebenen. Eine neue Prüfung ist nur eine weitere if-Zeile. Im echten Spiel kommt text aus input(), hier teste ich vier Eingaben in einer Schleife.

Warum das Zen of Python gerade Einsteigern hilft

Für Anfänger finde ich vor allem die Sätze über das Vereinfachen interessant. Am Anfang soll der Code erst einmal laufen. Du sollst Ergebnisse sehen und ins Tun kommen, dafür stehen „Simple is better than complex“ und „Now is better than never“.

Danach lohnt es sich, die Dinge in Ruhe zu überdenken. Das ist der Satz „Although never is often better than right now“. Wenn etwas läuft, schau es dir noch einmal an und frag dich, ob du es einfacher und flacher bauen kannst.

Gilt das Zen auch außerhalb von Python?

Ich übernehme die Prinzipien, so gut ich kann, auch in GDScript. Die Sprache liest sich ähnlich wie Python, darum passen die meisten Sätze direkt. Mehr dazu steht in meinem Beitrag GDScript lernen.

Selbst im Alltag ist die einfachste Lösung oft die beste. Ich habe gelernt, Dinge nicht zu komplex zu betrachten, sondern sie in kleine Schritte zu zerlegen, die sich einfach lösen lassen. Beim Programmieren denke ich genauso.

Zen of Python und PEP 8: was ist der Unterschied?

Das Zen beschreibt eine Haltung, aber keine konkreten Regeln. Die stehen in PEP 8 (öffnet in neuem Tab), dem offiziellen Stil-Leitfaden für Python-Code. Dort ist festgelegt, dass du mit vier Leerzeichen einrückst, Funktionen und Variablen klein mit Unterstrich schreibst (spieler_name) und Zeilen höchstens 79 Zeichen lang machst. Mehr dazu in meinem Beitrag zu PEP 8.

Weitere Beiträge findest du unter Python für Anfänger.

Fehler gefunden oder eine Frage zum Code? Schreib einen Kommentar oder eine E-Mail.