Lektionen aus dem Zen of Python

Was ist das Zen of Python? 

Das Zen of Python ist eine Sammlung von neunzehn Aphorismen, die als Leitprinzipien für das Design von Python dienen. Eigentlich sollten es zwanzig sein; doch Guido van Rossum, der Erfinder von Python, hat den letzten Aphorismus, wie von Tim Peters (dem Urheber des Zen of Python) vorgesehen, bis heute nicht hinzugefügt. Guido sagte Berichten zufolge, der fehlende zwanzigste Aphorismus sei „ein bizarrer Insiderwitz von Tim Peters“.

Trotz des fehlenden zwanzigsten Aphorismus wurde das Zen of Python 2004 als PEP 20 standardisiert, da es die Arbeitsweise von Python-Programmierern stark beeinflusst. Dem Zen of Python zu folgen ist nicht zwingend, aber es zu kennen und im Hinterkopf zu behalten, ist ratsam. Falls du die Leitsätze einmal vergisst, kannst du dein Gedächtnis ganz einfach auffrischen, indem du im Python-Interpreter import this ausführst. 

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

In diesem Artikel gehen wir jeden Leitsatz im Detail durch. 

#1 Beautiful is better than ugly 

Wenn du programmierst, bist du zweifellos hochqualifiziert. Probleme mit Code zu lösen ist keine leichte Aufgabe, aber als Pythonista wird noch mehr von dir erwartet. Schöner Code ist besser als hässlicher. Pythons rasanter Aufstieg liegt unter anderem an seiner Zugänglichkeit: Es ist einfach, gut lesbar und elegant. Als Python-Entwickler hast du die Verantwortung, diesen pythonischen Standard zu wahren, indem du schönen Code schreibst. 

Was ist schöner Code? Das ist natürlich subjektiv – Schönheit liegt im Auge des Betrachters. Eine einfache Faustregel, die dich auf Kurs hält: Schreibe sauberen, gut lesbaren Code, den andere Entwicklerinnen und Entwickler leicht nachvollziehen können. Zum Beispiel: 

"""
Initial code was created by Vishal Sharma
See:  https://towardsdatascience.com/the-zen-of-python-a-guide-to-pythons-design-principles-93f3f76d088a
"""
def collatz(num):
    if num % 2 == 0:
        return num // 2
    else:
        return 3 * num + 1

number = input("Enter a number: ")

while number != 1:
    number = collatz(int(number))
    print(number)

"""
Enter a number: 5
16
8
4
2
1
"""

Der obige Code funktioniert einwandfrei, ist aber nicht unbedingt schön. In unserer collatz-Funktion gibt es eine unnötige else-Verzweigung, die wir wie folgt entfernen können: 

def collatz(num):
  if num % 2 == 0:
      return num // 2
 
  return 3 * num + 1

Wenn du also zwei funktionierende Varianten hast, entscheide dich für diejenige, die einfacher, lesbarer und leichter zu verstehen ist. 

#2 Explicit is better than implicit

Einen Aphorismus als „selbsterklärend“ abzutun, ist ein großer Fehler – auch wenn man es immer wieder hört. Der Kern von „Explizit ist besser als implizit“ ist, dass ausführlicher Code indirektem Code vorzuziehen ist. Tu alles dafür, dass die Funktionalität deines Codes nicht hinter kryptischer Sprache verborgen bleibt. Jemand ohne Vorwissen zu deinem Programm sollte trotzdem begreifen, was im Code passiert. 

#3 Simple is better than complex

Du würdest probably lachen, wenn dein Kumpel nach dem Abendessen einen Hochdruckreiniger auspackt, um das Geschirr zu spülen. Das ist nicht nur eine ziemlich unsinnige Lösung, sondern die Teller könnten auch Schaden nehmen. Genauso ist es unpraktisch, auf ein einfaches Programmierproblem eine übermäßig komplexe Lösung anzuwenden. Mach es nicht komplizierter als nötig – selbst wenn du denkst, es lasse dich schlauer wirken. Du richtest damit eher Schaden an, und in Python kommt das nicht gut an. 

Sieh dir diese Funktion an, die einen String umkehrt: 

def reverse_string(string):
    if len(string) == 1:
        return string
    else:
        return reverse_string(string[1:]) + string[0]


string = "kurtis"

print(reverse_string(string))

"""
sitruk
"""

Der Code löst das Problem, ist aber unnötig komplex. Mit solidem Python-Verständnis weißt du, dass man einen String per Indexing umkehren kann. 

string = "kurtis"

# anonyme Funktion
reverse_string = lambda x: x[::-1]

# Funktionslösung
def reverse(string):
    return string[::-1]

print(reverse_string(string))
print(reverse(string))

"""
sitruk
sitruk
"""

#4 Complex is better than complicated 

Geschirr mit einem Hochdruckreiniger zu waschen, ist unpraktisch: Mit fließendem Wasser geht es einfacher. Aber wie sieht es aus, wenn ein 4x4 Range Rover gereinigt werden soll? Die beiden letzten Leitsätze erinnern uns daran, dass einfache und komplexe Techniken je nach Problem sinnvoll sind. Einen 4x4 Range Rover zu reinigen, ist kein einfaches Problem, und zu versuchen, dieselben Methoden wie beim Abwasch zu nutzen, mag funktionieren, ist aber umständlicher als ein Hochdruckreiniger. Bevorzuge also Einfachheit vor Komplexität, aber wo Einfachheit unpraktisch ist, greife lieber zu einer komplexen Lösung – kenne die Grenzen der Einfachheit. 

#5 Flat is better than nested 

Programmierer lieben es, Dinge in Kategorien, Unterkategorien und Unter-Unterkategorien zu ordnen, um Funktionen zu trennen. So ordentlich das klingt, eine solche Struktur kann mehr Verwirrung stiften als Ordnung schaffen. 

Es spricht nichts dagegen, deinen gesamten Code in einem Modul der obersten Ebene zu organisieren: So musst du nicht etwas wie from spam.foo.bar.john.doe import chicken schreiben, um auf eine bestimmte Funktion zuzugreifen. Je mehr Ebenen du einführst, desto komplizierter wird dein Code. Halte die Struktur nach Möglichkeit flach.

#6 Sparse is better than dense

Programmierer gelten als sehr intelligent – du musst das nicht durch übertrieben ausgefuchste Hacks betonen. Ein Klassiker sind „Wie man [irgendeine komplexe Aufgabe] in 1 Codezeile erledigt“-Posts. Manchmal sind One-Liner gerechtfertigt, aber vermeide es, die Lesbarkeit zu opfern, nur um alles in eine Zeile zu quetschen. 

Nimm dieses Codebeispiel: 

"""
Code source Al Sweigart
See: https://inventwithpython.com/blog/author/al-sweigart.html0
"""
print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))
"""
1 bytes = 8 bits which has 255 possible values.
2 bytes = 16 bits which has 65535 possible values.
4 bytes = 32 bits which has 4294967295 possible values.
8 bytes = 64 bits which has 18446744073709551615 possible values.
16 bytes = 128 bits which has 340282366920938463463374607431768211455 possible values.
32 bytes = 256 bits which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values.
64 bytes = 512 bits which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values.
128 bytes = 1024 bits which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values.
"""

Der Code funktioniert, ist aber extrem schwer zu verstehen: zu gedrängt und schlecht lesbar. 

Schauen wir uns dieselbe Logik in lockerer, gut lesbarer Form an: 

# Lockeres Beispiel
bytes_and_bits = {j: j*8 for j in (1 << i for i in range(8))}

for bytes, bits in bytes_and_bits.items():
    print(f"{bytes} bytes = {bits} which has {256**bytes-1} possible values")

"""
1 bytes = 8 which has 255 possible values
2 bytes = 16 which has 65535 possible values
4 bytes = 32 which has 4294967295 possible values
8 bytes = 64 which has 18446744073709551615 possible values
16 bytes = 128 which has 340282366920938463463374607431768211455 possible values
32 bytes = 256 which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values
64 bytes = 512 which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values
128 bytes = 1024 which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values
"""

Das ist deutlich leichter zu lesen und macht exakt dasselbe wie der One-Liner.

#7 Readability counts

Falls es noch nicht klar ist: Lesbarkeit zählt in Python. Deinen Code schreibst du einmal. Gelesen wird er dagegen oft. Deshalb sind abgekürzte Variablen- und Funktionsnamen keine gute Idee: Wenn du zwischen create_lst und create_list wählen kannst, nimm die zweite Variante. 

#8 Special cases aren’t special enough to break the rules

Python – und Programmieren insgesamt – kennt eine Reihe bewährter Praktiken. Es ist besser, dich daran zu halten, statt dein eigenes Ding zu machen. Andernfalls entsteht schnell inkonsistenter, schlecht lesbarer Code. 

#9 Although practicality beats purity

Leitsatz neun baut darauf auf. Ja, Best Practices sind sinnvoll. Aber sich krampfhaft an jede Regel zu klammern, kann ebenfalls zu schlechter Lesbarkeit führen. Jede Regel kann Ausnahmen haben. Wenn deine Lösung praktischer, lesbarer und verständlicher ist, darfst du von der gängigen Praxis abweichen. 

#10 Errors should never pass silently 

Ein stummer Fehler liegt vor, wenn ein Programm einen Fehlercode oder None zurückgibt, anstatt eine Exception auszulösen. Es ist besser, wenn ein Programm abstürzt, als dass ein Fehler stillschweigend übergangen wird und es weiterläuft. Langfristig führt das Unterdrücken von Fehlern zu schwer auffindbaren Bugs. 

#11 Unless explicitly silenced

Leitsatz elf ergänzt den vorherigen. Es gibt Fälle, in denen du bestimmte Fehler ignorieren willst. Dann solltest du den Fehler im Code ausdrücklich und gezielt unterdrücken. 

#12 In the face of ambiguity, refuse the temptation to guess

Computer tun nur, was wir ihnen sagen: Wenn sich dein Code nicht so verhält, wie du es willst, liegt es daran, dass er genau das tut, was du ihm vorgeschrieben hast. Auf gut Glück verschiedene Lösungen auszuprobieren, bis eine „irgendwie“ funktioniert, ist eine schlechte Strategie – du kaschierst womöglich das Problem, statt es zu lösen. Widerstehe der Versuchung. Denke die Logik durch und finde mit kritischem Denken eine passende Lösung. 

#13 There should be one - and preferably only one - obvious way to do it 

Das Motto der Programmiersprache Perl lautet: „There’s more than one way to do it!“ Zu viele Optionen führen leicht zur Qual der Wahl. Ähnlich ist es, wenn es viele Wege gibt, um dasselbe Ziel im Code zu erreichen. Du hast zwar mehr Freiheit beim Schreiben, musst beim Lesen aber alle möglichen Varianten kennen – unnötiger Mehraufwand. 

#14 Although that way may not be obvious at first unless you're Dutch

Dieser Aphorismus zeigt den Humor von Tim Peters: Guido van Rossum, der Erfinder von Python und „Benevolent Dictator For Life“ (BDFL), ist Niederländer. Es ist ein augenzwinkernder Hinweis darauf, dass die Regeln der Sprache für alle außer ihrem Schöpfer nicht immer sofort offensichtlich sind. 

#15 Now is better than never

Dieser Leitsatz sagt: Code, der in einer Endlosschleife hängt oder blockiert, ist schlimmer als Code, der das nicht tut. 

#16 Although never is often better than *right* now

Im Anschluss daran: Es ist oft besser, zu warten, bis dein Programm korrekt fertig ist, als es zu früh abzubrechen und falsche Ergebnisse zu bekommen. 

#17 If the implementation is hard to explain, it’s a bad idea

Es reicht nicht, dass du deine eigene Implementierung verstehst – „Ich weiß schon, was ich meine“ ist kein Argument. Programmieren ist Teamarbeit. Wenn du deine Implementierung nicht erklären kannst, ist sie höchstwahrscheinlich zu kompliziert. 

#18 If the implementation is easy to explain, it may be a good idea

Allerdings bedeutet leicht erklärbarer Code nicht automatisch, dass er gut ist – nur, dass er sich gut erklären lässt. Er könnte dennoch Schwächen haben, aber du bist auf dem richtigen Weg. 

#19 Namespaces are one honking great idea - let’s do more of those!

Ein Namespace ist in Python eine Abstraktion zur Organisation der Namen, die Objekten im Programm zugewiesen werden. In einem gegebenen Namespace und Scope kann Python so auflösen, auf welches Objekt sich ein Bezeichner bezieht. Der Aphorismus sagt im Kern: Die Art und Weise, wie Python Namen unter der Haube organisiert, ist ziemlich großartig. 

Fazit 

In diesem Artikel haben wir unsere Interpretation des Zen of Python vorgestellt – Leitlinien, die Python-Programmierer motivieren, sauberen, gut lesbaren Code zu schreiben. Manche sehen darin den ultimativen Bauplan für reibungsloses Coden, andere nehmen es lockerer. Probiere die Prinzipien an deinem eigenen Code aus und sieh selbst, wie sie deine Arbeit verbessern. Wenn du mehr über optimierten Code lernen möchtest, schau dir DataCamps Kurs Writing Efficient Python Code an.