相信大家在學習python肯定都聽說過python之禪。python之禪到底是個什么東西，設計者為什么要這樣設計？又有什么意義呢？看完下面的文章你就會明白了。

文章轉載自：微信公眾號 Python的樂趣

作者：一粒米飯

在Python的解釋器中隱藏一個彩蛋，輸入import this就會返回19條Python之禪，具體如下：

>>>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 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!

它的作者是 Tim Peter，這些設計理念開始是在Python郵件列表中發表，它包含了影響Python編程語言設計的19條軟件編寫原則。在最初及后來的一些版本中，一共包含20條，其中第20條是“這一條留空（...）請 Guido 來填寫”。這留空的一條從未公布也可能并不存在。

其中從吉多·范羅蘇姆的博客中可以了解到，最開始Python是他個人的一個實驗項目（skunkworks）。為了加快Python發展，他采用了一些原則，其中包括省時規則（timesaving rules）:

1. 盡可能從其他地方借用想法，只有它有意義。
2. “事情應該盡可能簡單，但不要簡單?！?（來自愛因斯坦）
3. 做好一件事情。（來自UNIX哲學）
4. 不要太擔心性能，可以在后面需要時進行優化。
5. 不要與環境抗爭，順其自然。
6. 不要嘗試完美，因為“足夠好”通常就是這樣。
7. （因此）有時可以偷工減料，尤其是后面可以完善的情況下。

還有除了省時規則以外的其他規則：

    1. Python實現不應局限于特定平臺?？梢赃\行某些功能并非總是可用的，但是核心部分應該在任何地方都可以使用。

    2. 不要用機器可以處理的細節來打擾用戶。

    3. 支持和鼓勵獨立于平臺的用戶代碼，但不要中斷對平臺功能或屬性的訪問（這與Java形成鮮明對比）。

    4. 大型復雜系統應具有多個擴展級別。這為經驗豐富的用戶（無論是否熟練）提供了最大的發揮空間。

    5. 錯誤不應致命。也就是說，只要虛擬機仍在運行，用戶代碼就應該能夠從錯誤情況中恢復。

    6. 同時，錯誤不應靜默地傳遞（后兩項決定了在整個實現中使用異常）。

    7. 不應允許用戶的Python代碼錯誤導致Python解釋器的不確定行為；核心錯誤絕不應該是由用戶的錯誤引起的。

基于以上的哲學理念，Tim Peter整理了19條Python之禪并收錄到Python增強建議（PEP 20）之中。

下面，再來簡單說下這19條Python之禪的含義。

• 優美優于丑陋(Beautiful is better than ugly)程序員經常為實現功能而快速編寫代碼，導致沒有考慮可讀性。但在這個看顏值的時代，優美的代碼肯定更加優秀并且受人歡迎?？吹皆愀獾拇a.gif
• 明了優于隱晦(Explicit is better than implicit)這一條不言而喻的，應該讓代碼清晰可讀，避免將代碼的功能隱藏晦澀的代碼中，使得別人需要在非常熟悉代碼之后才能完全理解其功能。誰也不希望過一個月后再閱讀自己的代碼是下面的表情。閱讀隱晦的代碼.gif
• 簡單優于復雜, 復雜優于凌亂(Simple is better than complex, Complex is better than complicated)這兩條提醒我們，構建任何事物都可以使用簡單或復雜的技術來完成。對于一個簡單的問題，例如建造一個鳥籠，一個簡單的解決方案會更好。另一方面，制造火車發動機是一個復雜的問題，需要復雜的技術。即使可以使用鳥籠技術制造柴油火車引擎，最終也可能不是理想的解決方案。相對于復雜，簡單一點更好，但要了解簡單的局限性。
• 扁平優于嵌套(Flat is better than nested)程序員喜歡將事物分門別類，尤其是包含子類的類別，這些子類又包含其他子類。但是，最好可以將代碼僅放在一個頂層模塊或類中，而不是將代碼分散在多個子模塊或子類中。如果制作需要導入import spam.eggs.bacon.ham.foo.bar之類的代碼的程序包和模塊，那么這代碼就太復雜了。
• 稀疏優于稠密(Sparse is better than dense)程序員通常喜歡將盡可能多的功能塞入盡可能少的代碼中，例如像以下這樣的單行代碼：print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))雖然這樣的代碼能人自我感覺良好，但它會讓嘗試理解它的同事非常不爽。與密集的單行代碼相比，分布在多行代碼通常更易于閱讀。
• 可讀性很重要！(Readability counts)自從1970年代以來一直使用C語言進行編程的人，strcmp（）可能顯然意味著“字符串比較”功能，但是現代計算機具有足夠的內存來寫出完整的函數名。不要從你的名字中刪除元音，也不要寫過于簡潔的代碼。代碼的可讀性和可維護性更重要，因此，清晰易讀的代碼比簡潔的不清晰代碼更為重要。
• 即使實用比純粹更優, 特例亦不可違背原則。(Special cases aren't special enough to break the rules, Although practicality beats purity)這兩條是相互矛盾的。程序員有時擼起袖子就是干，代碼能運行就行。這樣的做法可能會導致一堆混亂的，無法維護的代碼。另一方面，又會講究各種設計模式，可復用性，比如Java編程語言嘗試使所有代碼適合其面向對象的范例，即使是最小的程序，也常常會導致大量樣板代碼。實際上，在這兩種風格都不能走極端，要根據實際情況折中取舍。
• 錯誤絕不能悄悄忽略, 除非它明確需要如此。(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)這是一句玩笑話。吉多·范羅蘇姆是Python的創建者和BDFL（獨裁者）。但是，即使這樣也不能阻止Python結合三種不同的格式化字符串的方式。
• 做優于不做，然而不假思索還不如不做(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.)Python致力于簡化程序員的工作，而不是適應計算機以使程序運行更快。程序不僅需要編寫它的程序員可以理解，而且還需要其他維護代碼的程序員可以理解。這兩條提醒我們，如果“高性能”代碼過于復雜以致程序員無法理解和調試，那么它就是不好的代碼。反之，很容易向其他人解釋程序的代碼，并不意味著它不是不好的代碼。編程是一件困難的事，程序員何苦為難程序員。
• 命名空間是個絕妙的主意，我們應好好利用它(Namespaces are one honking great idea—let's do more of those)命名空間（以及全局和局部作用域）是防止一個模塊或作用域中的名稱與另一個模塊或作用域中的名稱沖突的關鍵。但也要記住，扁平比嵌套好，命名空間應該僅用于防止命名沖突，而不能添加不必要的分類。這些都是很好的設計哲學，每個有追求的Python程序員都應該謹記于心。