The Zen of Python (the Zen of Python)

Enter import in the interactive interpreter this will show Tim Peters the Zen of Python

the Zen of Python, by Tim petersbeautiful isbetter than ugly. Explicit isbetter than implicit. Simple isBetter than Complex.complex isbetter than complicated. Flat isbetter than nested. Sparse isbetter than dense. Readability counts. Special cases aren'T special enough to break the rules.Although practicality beats purity. Errors should neverPasssilently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- andPreferably only one--obvious-do it. Although that, may notBe obvious at first unless're Dutch.Now isbetter than never. Although never isOften better than *right*Now . If the implementation isHard to explain, it's a bad idea.If the implementation isEasy to explain, it is a good idea. Namespaces is one honking great idea-Let's do more than those!

Import This

The full text content contrast translation is as follows:

Python Zen in English

The Zen of Python, by Tim Peters	The Zen of Python by Tim Peters
Beautiful is better than ugly.	Beauty is better than ugliness (Python aims to write graceful code)
Explicit is better than implicit.	Clarity is better than obscure (graceful code should be clear, naming specification, style similar)
Simple is better than complex.	Simplicity is better than complexity (graceful code should be concise, not complex internal implementations)
Complex is better than complicated.	Complexity is better than clutter (if complexity is unavoidable, there is no hard-to-understand relationship between the code, keep the interface simple)
Flat is better than nested.	Flattening is better than nesting (graceful code should be flat, not too much nesting)
Sparse is better than dense.	The interval is better than the compact (graceful code has the appropriate interval, do not expect a line of code to solve the problem)
Readability counts.	Readability is important (graceful code is readable)
Special cases aren ' t special enough to break the rules. Although practicality beats purity.	Even in the name of the practicality of the special case, the rules must not be violated (these rules are paramount)
Errors should never pass silently. Unless explicitly silenced.	Do not tolerate all errors unless you are sure you need to (catch exceptions accurately, do not write Except:pass-style code)
In the face of ambiguity, refuse the temptation to guess.	When there are many possibilities, don't try to guess
There should is one--and preferably only one--obvious the-do it.	Instead, try to find one, preferably the only obvious solution (if unsure, use the brute-lifting method)
Although that is obvious at first unless you ' re Dutch.	Although this is not easy, because you are not the father of Python (here Dutch refers to Guido)
Now is better than never. Although never is often better than *right* now.	It may be better not to do it, but it's better not to do it without thinking about it (before you do it)
If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it could be a good idea.	If you can't describe your plan to someone, it's certainly not a good plan; and vice versa (Program evaluation criteria)
Namespaces is one honking great idea – let's do more than those!	Namespaces are a great idea and we should use them (advocacy and calling).

Biyoulin

Source:http://www.cnblogs.com/biyoulin/

Copyright NOTICE: This article copyright belongs to the author and the blog Park is shared, welcome reprint, but without the consent of the author must retain this paragraph statement, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

The Zen of Python (the Zen of Python)