Dieser Artikel stammt von stackoverflow Fragen und Antworten zum Zen von Python Dies ist eine Übersetzung von (CC BY-SA3.0-Lizenz). Die japanische Übersetzung von The Zen of Python basierte auf "Wonach suchen wir in" Python "?". ..
Das Zen of Python ist eine kurze Zusammenfassung der Einstellungen, die Python-Programmierer haben sollten. Dies sollte Programmierern, die kein Python schreiben, eine große Hilfe sein. "Zen" ist übrigens japanisches "Zen".
Sie müssen nicht versuchen, den vollständigen Text von Anfang an zu lesen. Wir empfehlen Ihnen, einen kurzen Blick auf diesen Artikel zu werfen und die Teile zu lesen, die Sie interessieren.
Der vollständige Text befindet sich auf dem Python-Interpreter
>>> import this
Sie können es durch Eingabe anzeigen.
Der vollständige Text ist unten.
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Schön ist besser als hässlich.
Explicit is better than implicit.
Es ist besser zu klären als zu implizieren.
Simple is better than complex.
Es ist besser, einfach als kompliziert zu sein.
Complex is better than complicated.
Trotzdem ist es besser, kompliziert als kompliziert zu sein.
Flat is better than nested.
Das Nest sollte flach sein.
Sparse is better than dense.
Es ist besser, eine Lücke zu haben, als überfüllt zu sein.
Readability counts.
Leicht zu lesen ist gut.
Special cases aren't special enough to break the rules.
Besonderes zu sein ist kein Grund, gegen die Regeln zu verstoßen.
Although practicality beats purity.
Wenn es jedoch um Praktikabilität geht, kann Reinheit verloren gehen.
Errors should never pass silently.
Verstecke den Fehler nicht, ignoriere ihn nicht.
Unless explicitly silenced.
Wenn es jedoch absichtlich versteckt ist, verpassen Sie es nicht.
In the face of ambiguity, refuse the temptation to guess.
Wenn Sie auf etwas Mehrdeutiges stoßen, raten Sie nicht, was es bedeutet.
There should be one-- and preferably only one --obvious way to do it.
Es muss einen guten Weg geben. Es gibt nur einen Weg, der für alle offensichtlich ist.
Although that way may not be obvious at first unless you're Dutch.
Die Methode kann auf den ersten Blick schwer zu verstehen sein. Es kann nur für Niederländer leicht zu verstehen sein.
Now is better than never.
Mach es jetzt, anstatt es nicht die ganze Zeit zu machen.
Although never is often better than *right* now.
Aber jetzt"demnächst"Es ist oft besser, es nicht zu tun, als es zu tun.
If the implementation is hard to explain, it's a bad idea.
Wenn es schwierig ist zu erklären, was der Code ist, ist es eine schlechte Implementierung.
If the implementation is easy to explain, it may be a good idea.
Wenn Sie den Inhalt des Codes leicht erklären können, ist dies wahrscheinlich eine gute Implementierung.
Namespaces are one honking great idea -- let's do more of those!
Namespaces sind eine großartige Idee und sollten aktiv genutzt werden.
Dann werde ich den Originaltext Zeile für Zeile erklären.
Beautiful is better than ugly. Schön ist besser als hässlich.
(Befragter: J. T. Hurley)
Mit Python können Sie mit genau so viel Code das maximale Engagement finden.
def gcd(x, y):
while y:
x, y = y, x % y
return x
Je schöner der Algorithmus, desto schöner der Code. Und Python kann seine Schönheit mit einer kleinen Anzahl von Zeilen ausdrücken.
Explicit is better than implicit. Es ist besser zu klären als zu implizieren.
Tu das nicht.
from os import *
print(getcwd())
Machen Sie es einfach zu sehen, von welchem Modul die Funktion bereitgestellt wird.
import os
print(os.getcwd())
Das Zen von Python sagt:
Namespaces are one honking great idea - let's do more of those!
Namespace ist eine großartige Idee.
Geben Sie in Python beim Aufrufen einer Methode und beim Verweisen auf ein Feld self auch in der Klasse an. Programmierer sollten immer wissen, was und wo sich das Objekt befindet, das sie verwenden.
Einige Skriptsprachen können dies tun.
test.php
<?php
$foo = "5";
echo $foo * 3;
?>
Wenn es ausgeführt wird, wird es so.
$php test.php
15
Dies liegt daran, dass die Zeichenfolge bei der Berechnung der Zeichenfolge x Ganzzahl als Ganzzahl betrachtet wird. Es heißt implizite Typkonvertierung. In Python ist dies jedoch ein Fehler.
>>> foo = "5"
>>> foo+3
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
Wenn Sie möchten, dass das Ergebnis als Ganzzahl zurückgegeben wird, müssen Sie es angeben.
>>> int(foo)+3
8
Simple is better than complex. Es ist besser, einfach als kompliziert zu sein.
Complex is better than complicated. Trotzdem ist es besser, kompliziert als kompliziert zu sein.
Referenzierte Seite: Was bedeutet "Komplex ist besser als kompliziert"? (Befragter: EinLama)
Kompliziert oder esoterisch zu sein, ist ein bisschen anders als kompliziert zu sein.
Nehmen wir diesen Code als Beispiel.
counter = 0
while counter < 5:
print(counter)
counter += 1
Dieser Code sollte sehr leicht zu verstehen sein. Aber dieser Code ist esoterisch. Zwei Elemente, "Verwalten von Zählervariablen" und "Anzeigen von Werten mit Druckanweisungen", sind in einem Code zusammengefasst.
for i in xrange(5):
print(i)
Andererseits ist dieser Code komplexer als das Beispiel mit wihle. Es gibt eine klare Trennung zwischen den beiden Elementen "Verwaltung von Zählervariablen" und "Drucken des Werts". Wenn Sie xrange nicht kennen, wissen Sie möglicherweise nicht, was dieser Code tut. Wenn Sie jedoch sauberen Code schreiben möchten, sind die Kosten für die Ermittlung von xrange nicht so hoch. Das Verhalten von xrange ist anhand der Dokumentation leicht zu verstehen.
Je größer der Code ist, desto größer ist der Unterschied in der Verwaltbarkeit zwischen esoterischem Code und komplexem Code. Je einfacher und einfacher das Schreiben ist, desto einfacher ist es natürlich zu verwalten.
Beautiful is better than ugly.
Flat is better than nested.
Das Nest sollte flach sein.
### Beispiel
(Befragter: [S.Lott](https://stackoverflow.com/users/10661/s-lott))
Beispielsweise erben die von Java- und C ++ - Bibliotheken bereitgestellten Klassen normalerweise von anderen Klassen.
In diesem Fall müssen Sie darüber nachdenken, wie die Klasse, die Sie verwenden möchten, von anderen Klassen erbt.
Daher wird es schwierig, die Spezifikationen der Bibliothek richtig zu verstehen und zu verwenden.
Mit Python müssen Sie jedoch nicht __com.company.java.blah.blah__ schreiben, wenn Sie Standardmodule verwenden. Meistens sollten Sie in der Lage sein, __timeit__ oder __csv__ zu verwenden. Dies ist möglich, weil der Namespace flach aufgebaut ist.
Sparse is better than dense.
Es ist besser, eine Lücke zu haben, als überfüllt zu sein.
### Beispiel
```python
if i>0: return sqrt(i)
elif i==0: return 0
else: return 1j * sqrt(-i)
if i > 0:
return sqrt(i)
elif i == 0:
return 0
else:
return 1j * sqrt(-i)
Was ist leichter zu lesen, der Code oben oder der Code unten?
Versuchen Sie nicht, zu viel in eine Zeile zu packen.
Readability counts. Leicht zu lesen ist gut.
(Befragter: Federico A. Ramponi)
Vergleichen wir C und Python.
#include <stdio.h>
int main(void) {
printf("Hello, world!\n");
return(0);
}
print("Hello, world!")
Selbst mit dem gleichen "Hallo Welt!" Ist die Lesbarkeit zwischen C und Python völlig unterschiedlich. Mit Python können Sie auf einen Blick sehen, was Ihr Code tut.
Special cases aren't special enough to break the rules. Besonderes zu sein ist kein Grund, gegen die Regeln zu verstoßen.
Although practicality beats purity. Wenn es jedoch um Praktikabilität geht, kann Reinheit verloren gehen.
(Befragter: Federico A. Ramponi)
Python hat keinen "Nur-Zeichen" -Typ wie char. Es ist nicht so besonders, wie es eine spezielle Form braucht. Um die Praktikabilität zu gewährleisten, ist jedoch eine Funktion erforderlich, die ein Zeichen der Länge 1 wie chr oder ord annimmt oder zurückgibt.
Errors should never pass silently. Verstecke den Fehler nicht, ignoriere ihn nicht.
(Befragter: Ali Afshar)
Schreiben Sie diesen Code beispielsweise nicht.
try:
import this
except ImportError:
pass
Stellen Sie klar, dass ein Fehler erkannt wurde.
try:
import this
except ImportError:
print('this is not available')
Unless explicitly silenced. Wenn es jedoch absichtlich versteckt ist, verpassen Sie es nicht.
(Befragter: Ali Afshar)
Schauen wir uns diesen Code an.
d = dict((('spam', 1), ('ham', 2)))
default = 0
k = 'eggs'
try:
v = d[k]
except KeyError:
v = d[k] = default
print("v:{}".format(v))
print("d:{}".format(d))
Wenn es ausgeführt wird, wird es so.
$python silenced.py
v:0
d:{'eggs': 0, 'ham': 2, 'spam': 1}
Wenn in diesem Code kein Schlüssel vorhanden ist, wird er auf den Standardwert gesetzt. Die Ausnahmeklausel benachrichtigt die Außenstehenden nicht darüber, dass ein Fehler aufgetreten ist. Weil ich das absichtlich mache.
In the face of ambiguity, refuse the temptation to guess. Wenn Sie auf etwas Mehrdeutiges stoßen, raten Sie nicht, was es bedeutet.
Wann wird diese bedingte Aussage wahr sein?
if not a and b:
pass
Schreiben Sie es so um
if b and not a:
pass
Oder es ist etwas klobig, aber es ist besser zu schreiben:
if (not a) and b:
pass
There should be one-- and preferably only one --obvious way to do it. Es muss einen guten Weg geben. Es gibt nur einen Weg, der für alle offensichtlich ist.
(Befragter: Federico A. Ramponi)
Je nach Typ gibt es in C ++ verschiedene Möglichkeiten, die Elemente eines Arrays in der richtigen Reihenfolge anzuzeigen. (Ich bin nicht mit C ++ vertraut. Bitte lassen Sie mich wissen, wenn Sie ein gutes Beispiel haben.)
Aber mit Python ist das alles, was Sie brauchen. Es spielt keine Rolle, ob das Ziel ein Wörterbuch oder eine Liste ist, in dieser Form ist alles in Ordnung.
for element in sequence:
Although that way may not be obvious at first unless you're Dutch. Die Methode kann auf den ersten Blick schwer zu verstehen sein. Es kann nur für Niederländer leicht zu verstehen sein.
"Niederländisch" bezieht sich hier auf den Python-Entwickler Guido van Rossum. Weitere Informationen finden Sie unter hier. Ich will es.
(Befragter: S.Lott)
Es gab eine hitzige Debatte über die Wenn-Dann-Sonst-Klausel (cond? Expr1: expr2 in C). Darin schlug Guido dies vor.
a = expr1 if cond else expr2
Dies ist die einzige Möglichkeit, eine Wenn-Dann-Sonst-Klausel in Python zu schreiben. Auf den ersten Blick ist es jedoch schwer zu verstehen.
Now is better than never Mach es jetzt, anstatt es nicht die ganze Zeit zu machen.
(Befragter: wim)
never
f = open('stay_open.txt', 'w')
f.write('every even number > 2 is the sum of two primes')
raise AssertionError('this sentence is false')
f.close()
now
with open('will_be_closed.txt', 'w') as f:
f.write('the sum of two primes > 2 is an even number')
raise AssertionError('this sentence is false')
Haben Sie bemerkt, was mit dem Nie-Code nicht stimmt? Der Nie-Code bestätigt die Verbindung zur Datei, ohne sie zu schließen. Die Idee "weil ich es später schließen werde" führt zu schlechtem Code. Der Now-Code schließt jedoch die Verbindung zur Datei auch dann ordnungsgemäß, wenn ein Fehler auftritt.
Der Nie-Code kann auch wie folgt umgeschrieben werden:
try:
f = open('will_be_closed.txt', 'w')
f.write('every even number > 2 is the sum of two primes')
assert not 'this sentence is false'
finally:
f.close()
Aber schön ist besser als hässlich.
Beautiful is better than ugly.
Although never is often better than right now. Aber es ist oft besser, es jetzt nicht zu tun, als es "sofort" zu tun.
Eine frühzeitige Überoptimierung Ihres Codes kann oft Zeitverschwendung sein.
Wenn Sie beispielsweise eine Sortierung implementieren müssen, müssen Sie häufig keine schnelle Sortierung von Grund auf neu implementieren. Eine schnelle Sortierung ist im Allgemeinen schwieriger zu implementieren als eine Blasensortierung. In der Realität ist das Sortieren von Blasen ein ausreichendes Problem, aber das Schreiben mit schnellem Sortieren von Anfang an ist Zeitverschwendung. Verwenden Sie in der Testphase vorerst die Blasensortierung und schreiben Sie sie bei Bedarf neu, um sie schnell zu sortieren.
If the implementation is hard to explain, it's a bad idea. Wenn es schwierig ist zu erklären, was der Code ist, ist es eine schlechte Implementierung.
If the implementation is easy to explain, it may be a good idea. Wenn Sie den Inhalt des Codes leicht erklären können, ist dies wahrscheinlich eine gute Implementierung.
Namespaces are one honking great idea -- let's do more of those! Namespaces sind eine großartige Idee und sollten aktiv genutzt werden.
(Befragter: Federico A. Ramponi, Herausgeber: wim)
Wenn Sie das Modul verwenden, schreiben Sie wie folgt.
import module
module.spam()
import module
breakfast = module.SpamAndEggs()
Schreib das nicht.
from module import *
Sie können dies nur schreiben, wenn Sie eine Funktion in einem Terminal testen. Wenn Sie dies in einem normalen Programm schreiben, können die Namen in Konflikt geraten. Außerdem wird die Lesbarkeit verringert, da nicht bekannt ist, zu welchem Modul die Funktion gehört.
Wenn der Modul- oder Klassenname lang ist, verwenden Sie als.
import aRidiculouslyLongModuleName as short
Wenn Sie Fragen oder Bedenken haben, kommentieren Sie bitte.
The Zen of Python Was suchen wir in "Python"? What does “Complex is better than complicated” mean? An Introduction to the Zen of Python
Recommended Posts