Original#
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!
Translation#
Beautiful is better than ugly.
Explicit is better than implicit. (1)
Simple is better than complex.
Complex is better than complicated. (2)
Flat is better than nested.
Sparse is better than dense. (3)
Readability is important. (4)
Although practicality is more important than purity,
special cases are often not special enough to break the rules.
Errors should never be ignored, unless explicitly silenced. (5)
In the face of ambiguity, do not 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. (6)
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. (7)
Namespaces are a great idea - let's do more of those!
References#
The packages to be imported are explicitly listed one by one, without merging; do not use asterisks; do not hide unexpected side effects in methods, and so on. Another example is the famous software design principle "Convention over Configuration." If not done carefully, such as when the rules you set are not really industry conventions, it will violate this principle.
A question on StackOverflow regarding this sentence: Necessary complexity is always inevitable, but verbose and convoluted code is unacceptable. You can do many things, complex things, but they should not be verbose and should be easy to understand. Complexity is not a sin, but the code needs to be more logical and better organized. In short, Simple > Complex > Complicated > Chaotic. (Also, the above content is limited to the context of Python, and the definitions of Complex and Complicated may vary in different contexts.)
Some people like to write long one-liners, such as: lambda L: [] if L==[] else qsort([x for x in L[1:] if x< L[0]]) + L[0:1] + qsort([x for x in L[1:] if x>=L[0]]) # one-liner quicksort. Although this can be impressive, it is also difficult to understand. Code that others cannot understand is not elegant code.
One of the motivations for writing this article is seeing someone translate "Readability counts" as "Readability calculation."
In practice, many people do not pay attention to catching exceptions and just log them and move on quickly. Is this good? No, it's not. The software industry generally advocates for the "Let it fail" principle, also known as the Fail-fast principle. In short, the earlier a problem is exposed in the project cycle, the lower the cost of fixing it. If you wait until your project is live and various strange bugs appear, you will have no clue and can only dig through long logs. So I advise everyone not to make this kind of cleverness, small cleverness.
The author of this article, Tim Peters, explains that the term "Dutch" here refers to Guido van Rossum, the creator of Python, and it is a compliment to him: equivalent to saying "You Dutch guy, you really are a genius."
The core of the entire PEP 20 is the phrase "Your code is meant to be read by others!" From this perspective, code that is difficult to understand and maintain, even if it is "high-performance," is definitely not good code. However, on the other hand, code that is easy to understand does not necessarily mean it is good code. Programming is really difficult.