A few words in the Zen of Python-the legendary Serpent sect

Simple is better than complex.

Simplicity is better than complexity.

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.

The full text, the source is already unclear, if specified, must be thanked!

the Zen of Python, by Tim Peters Beautiful are better than ugly. Explicit is better than implicit. Simple are 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 is one--and preferably only one--obvious the-do it. Although that's 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 could be a good idea. Namespaces is one honking great idea – let's do more than those! 

Python Zen by Tim Peters Beauty is better than ugliness (Python's goal of writing graceful code) is better than obscure (graceful code should be clear, naming specification, style similar) simplicity is better than complexity (graceful code should be concise, Do not have complex internal implementations) complexity is better than clutter (if complex inevitably, the code can not have a difficult relationship, to keep the interface concise) flat than nesting (graceful code should be flat, not too much nesting) interval than compact (graceful code has the appropriate interval, Do not expect a line of code to solve the problem) readability is important (beautiful code is readable) even in the name of the practicality of the special case, do not violate these rules (these rules are paramount) do not tolerate all errors, unless you are sure you need to do this (accurately catch exceptions, do not write Except:pass-style code) When there are many possibilities, do not try to guess but try to find one, preferably the only obvious solution (if not sure, use the poor lifting method) Although this is not easy, because you are not the father of Python (here Dutch refers to Guido) do perhaps better than not to do, But it's better not to do it without thinking about it (before you do it) if you can't describe your plan to someone, it's certainly not a good idea; and vice versa (Program evaluation criteria) namespaces are a wonderful concept and we should use them (advocacy and call)

　　

A few words in the Zen of Python-the legendary Serpent sect