Das 'Zen of Python' ausgeschrieben

In der Newsgroup comp.lang.python kam die Frage auf, ob das Python-Zen ernst gemeint ist. Das hier ist Stephen D'Apranos (Mitglied der 'Python software foundation') Antwort darauf:

Re: Warum „flach ist besser als verschachtelt“ ?

• Du hast keine Ahnung, wenn du denkst, dass Pythonprogrammierer das Zen nicht ernst nehmen. Ich nehme an, manche tun das tatsächlich nicht - ganz besonders die, die Lisp/Java/PHP/Sonst-was in Python schreiben. Ich nehme auch an, dass es manche zu ernst nehmen, wie ein religiöses Dogma. Obwohl das Zen auf eine heitere Art und Weise geschrieben ist, ist es nicht als Scherz gedacht. Jede Zeile ist einer ernsthafter Rat – sogar die über Holland. Wäre es hilfreich, das Zen auf eine weniger heitere Art zu formulieren?
  • Wenn du in Python programmierst, solltest du auf schönen, eleganten Code
    • und Algorithmen hinarbeiten, nicht auf hässlichen, unordentlichen.
  • Beim Programmieren geht es darum, dem Computer Anweisungen zu geben. Es
    • ist besser diese Anweisungen ausdrücklich zu geben als durch den Zusammenhang, da dieser anders als erwartet oder vom Leser falsch erkannt sein kann.
  • In einfachem Code gibt es weniger Dinge, die schiefgehen können,
    • verstanden werden müssen, Fehler verdecken. Nimm lieber einfachen als aufwendigen Code.
  • Knifflige Probleme erfordern aufwendige Lösungen, aber meide komplizierte
    • Lösungen wenn immer du kannst. Eine Uhr ist aufwendig, die Rangordnung und Etikette am Hof des Sonnenkönigs Ludwigs XIV., im Frankreich des 17. Jahrhunderts, waren kompliziert.
  • Flache Strukturen sind üblicherweise einfacher und schneller zu Parsen
    • und sollten so verschachtelten Strukturen vorgezogen werden. Wenn du verschachtelte Strukturen brauchst, nimm lieber flach als tief verschachtelte.
  • Du liest Quellcode viel öfter, als dass du ihn schreibst, folglich ist
    • die Lesbarkeit wichtig. Strebe nach lesbarem Code, außer wenn die Geschwindigkeit Kompromisse verlangt.
  • Sprachen und Libraries sollten konsequent sein und den Normalfall
    • unterstützen. Widerstehe der Versuchung, Unterstützung für Ausnahmefälle aufzubauen, die fast niemand braucht. Der Aufrufende soll sich selbst um seine Ausnahmefälle kümmern.
  • Sofern es keine guten, praktischen Gründe gibt, sich um einen
    • Ausnahmefall zu kümmern.
  • Fehler sollten als Fehler behandelt werden. Library-Code sollte Fehler
    • immer melden und nicht einfach ausblenden.
  • Benutzer sollten die Möglichkeit haben Fehler, die sie nicht kümmern,
    • auszublenden.
  • Wenn eine Situation nicht eindeutig ist, sollten Funktionen nicht
    • versuchen zu erraten was der Aufrufende wollte – sie raten früher oder später falsch.
  • Für jede Aufgabe die ein Benutzer angehen will, sollte es eine
    • einleuchtende Möglichkeit geben, am besten nur eine, aber mehrere Lösungen sind auch erlaubt. Wenn es keine einleuchtende gibt, ist das ein Mangel in der Library bzw. Sprache.
  • Manchmal leuchtet das, was dem Erfinder von Python, Guido van Rossum,
    • Niederländer, einleuchtet, nicht jedem ein, der nicht den gleichen Hintergrund hat. Damit musst du leben.
  • Wenn etwas getan werden muss, ist es besser es gleich zu machen, als es
    • ewig vor sich her zu schieben. Warte nicht bis Software vollkommen ist – du kann auch Dinge abmessen, wenn dein Lineal 'ne Macke hat, und eine stumpfe Säge sägt besser als keine.
  • Aber manchmal ist es besser etwas zu lassen, als sich an fehlerhafte
    • Standards zu binden. Wenn es jetzt keine Lösung gibt, die gut genug ist, mag es besser sein auf eine gute zu warten als auf einer schlechten sitzen zu bleiben.
  • Wenn die Umsetzung von Software kompliziert und schwer zu erklären ist,
    • ist es wahrscheinlich verkehrt diesen Weg zu gehen. Suche eine bessere Lösung.
  • Wenn die Umsetzung einfach und leicht zu erklären ist, mag es eine gute
    • Idee sein. Aber manche Ideen sind eben schlecht, egal wie einfach sie umgesetzt werden können.
  • Namensräume sind eine erprobte Lösung für viele Programmieraufgaben.
    • Wir sollten sie öfter in Python verwenden.

Originalpost

Im original hier, comp.lang.python auf googlegroups zu lesen.

Zen of python

Das Zen gibt's hier auf deutsch.

this

   1 >>> 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!