Python Learning Notes (9)-python programming style

Title of this node
1. Python Programming style
1.1. Python Design philosophy
1.2. Run import this in the Python interpreter to get a complete list of programming styles

=============================================================================================================== ========
1. Python Programming Style

1.1. Python Design philosophy
Python's design philosophy is "elegant", "clear", "simple".
The Python developer's philosophy is "in one way, it's best to have only one way to do something."
When designing the Python language, Python developers tend to reject the fancy syntax when faced with a variety of choices, and choose a syntax that is unambiguous or rarely ambiguous. These guidelines are called "Python maxims."

1.2. Run import this in the Python interpreter to get a complete list of programming styles

1 beauty is better than ugliness (Python aims to write graceful code)
2 clarity is better than obscure (graceful code should be clear, naming specification, style similar)
3 simplicity is better than complexity (graceful code should be concise, without complex internal implementations)
4 complexity is better than clutter (if complexity is unavoidable, there can be no hard-to-understand relationship between the code, to keep the interface concise)
5 flat is better than nesting (graceful code should be flat, not too much nesting)
6 interval is better than compact (graceful code has the appropriate interval, do not expect a line of code to solve the problem)
7 readability is important (graceful code is readable)
8 Do not violate these rules, even in the name of the practicality of the special case (these rules are paramount)
9 do not tolerate all errors unless you are sure you need to do this (accurately capturing exceptions, not writing Except:pass-style code)
10 when there are many possibilities, don't try to guess
11 instead try to find one, preferably the only obvious solution (if unsure, use the brute-lifting method)
12 Although this is not easy, because you are not the father of Python (here Dutch refers to Guido)
13 It may be better not to do it, but it's better not to do it without thinking about it (before you do it)
14 If you can't describe your plan to someone, it's certainly not a good plan; and vice versa (Program evaluation criteria)
15 namespaces are a wonderful idea that we should use (advocacy and call)

[[email protected] ~]# python
Python 2.7.13 (default, Jan 29 2017, 23:09:06)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "Help", "copyright", "credits" or "license" for more information.
>>>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 is one--and preferably only one--obvious the-do it.
Although that is 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 Learning Notes (9)-python programming style