@@ -14,6 +14,32 @@ It's loosely based on the exercises & theory from the book [Cracking the Code In
1414Even after the years, this book can be useful if you are aiming to learning Python and/or practicing for software engineering interviews.
1515
1616
17+ ---
18+
19+ ## [ The Zen of Python] ( https://www.python.org/dev/peps/pep-0020/ )
20+
21+ ```
22+ Beautiful is better than ugly.
23+ Explicit is better than implicit.
24+ Simple is better than complex.
25+ Complex is better than complicated.
26+ Flat is better than nested.
27+ Sparse is better than dense.
28+ Readability counts.
29+ Special cases aren't special enough to break the rules.
30+ Although practicality beats purity.
31+ Errors should never pass silently.
32+ Unless explicitly silenced.
33+ In the face of ambiguity, refuse the temptation to guess.
34+ There should be one-- and preferably only one --obvious way to do it.
35+ Although that way may not be obvious at first unless you're Dutch.
36+ Now is better than never.
37+ Although never is often better than *right* now.
38+ If the implementation is hard to explain, it's a bad idea.
39+ If the implementation is easy to explain, it may be a good idea.
40+ Namespaces are one honking great idea -- let's do more of those!
41+ ```
42+
1743-----
1844
1945This work is licensed under a [ Creative Commons Attribution-ShareAlike 4.0 International License] ( http://creativecommons.org/licenses/by-sa/4.0/ ) .
0 commit comments