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

文章轉(zhuǎn)載自：微信公眾號 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，這些設(shè)計理念開始是在Python郵件列表中發(fā)表，它包含了影響Python編程語言設(shè)計的19條軟件編寫原則。在最初及后來的一些版本中，一共包含20條，其中第20條是“這一條留空（...）請 Guido 來填寫”。這留空的一條從未公布也可能并不存在。

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

1. 盡可能從其他地方借用想法，只有它有意義。
2. “事情應(yīng)該盡可能簡單，但不要簡單?！?（來自愛因斯坦）
3. 做好一件事情。（來自UNIX哲學(xué)）
4. 不要太擔(dān)心性能，可以在后面需要時進(jìn)行優(yōu)化。
5. 不要與環(huán)境抗?fàn)帲樒渥匀弧?
6. 不要嘗試完美，因為“足夠好”通常就是這樣。
7. （因此）有時可以偷工減料，尤其是后面可以完善的情況下。

還有除了省時規(guī)則以外的其他規(guī)則：

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

    2. 不要用機器可以處理的細(xì)節(jié)來打擾用戶。

    3. 支持和鼓勵獨立于平臺的用戶代碼，但不要中斷對平臺功能或?qū)傩缘脑L問（這與Java形成鮮明對比）。

    4. 大型復(fù)雜系統(tǒng)應(yīng)具有多個擴展級別。這為經(jīng)驗豐富的用戶（無論是否熟練）提供了最大的發(fā)揮空間。

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

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

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

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

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

• 優(yōu)美優(yōu)于丑陋(Beautiful is better than ugly)程序員經(jīng)常為實現(xiàn)功能而快速編寫代碼，導(dǎo)致沒有考慮可讀性。但在這個看顏值的時代，優(yōu)美的代碼肯定更加優(yōu)秀并且受人歡迎?？吹皆愀獾拇a.gif
• 明了優(yōu)于隱晦(Explicit is better than implicit)這一條不言而喻的，應(yīng)該讓代碼清晰可讀，避免將代碼的功能隱藏晦澀的代碼中，使得別人需要在非常熟悉代碼之后才能完全理解其功能。誰也不希望過一個月后再閱讀自己的代碼是下面的表情。閱讀隱晦的代碼.gif
• 簡單優(yōu)于復(fù)雜, 復(fù)雜優(yōu)于凌亂(Simple is better than complex, Complex is better than complicated)這兩條提醒我們，構(gòu)建任何事物都可以使用簡單或復(fù)雜的技術(shù)來完成。對于一個簡單的問題，例如建造一個鳥籠，一個簡單的解決方案會更好。另一方面，制造火車發(fā)動機是一個復(fù)雜的問題，需要復(fù)雜的技術(shù)。即使可以使用鳥籠技術(shù)制造柴油火車引擎，最終也可能不是理想的解決方案。相對于復(fù)雜，簡單一點更好，但要了解簡單的局限性。
• 扁平優(yōu)于嵌套(Flat is better than nested)程序員喜歡將事物分門別類，尤其是包含子類的類別，這些子類又包含其他子類。但是，最好可以將代碼僅放在一個頂層模塊或類中，而不是將代碼分散在多個子模塊或子類中。如果制作需要導(dǎo)入import spam.eggs.bacon.ham.foo.bar之類的代碼的程序包和模塊，那么這代碼就太復(fù)雜了。
• 稀疏優(yōu)于稠密(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))))雖然這樣的代碼能人自我感覺良好，但它會讓嘗試?yán)斫馑耐路浅２凰?。與密集的單行代碼相比，分布在多行代碼通常更易于閱讀。
• 可讀性很重要！(Readability counts)自從1970年代以來一直使用C語言進(jìn)行編程的人，strcmp（）可能顯然意味著“字符串比較”功能，但是現(xiàn)代計算機具有足夠的內(nèi)存來寫出完整的函數(shù)名。不要從你的名字中刪除元音，也不要寫過于簡潔的代碼。代碼的可讀性和可維護(hù)性更重要，因此，清晰易讀的代碼比簡潔的不清晰代碼更為重要。
• 即使實用比純粹更優(yōu), 特例亦不可違背原則。(Special cases aren't special enough to break the rules, Although practicality beats purity)這兩條是相互矛盾的。程序員有時擼起袖子就是干，代碼能運行就行。這樣的做法可能會導(dǎo)致一堆混亂的，無法維護(hù)的代碼。另一方面，又會講究各種設(shè)計模式，可復(fù)用性，比如Java編程語言嘗試使所有代碼適合其面向?qū)ο蟮姆独?，即使是最小的程序，也常常會?dǎo)致大量樣板代碼。實際上，在這兩種風(fēng)格都不能走極端，要根據(jù)實際情況折中取舍。
• 錯誤絕不能悄悄忽略, 除非它明確需要如此。(Errors should never pass silently, Unless explicitly silenced.)僅僅因為程序員經(jīng)常忽略錯誤消息并不意味著程序應(yīng)該停止發(fā)出錯誤消息。當(dāng)函數(shù)返回錯誤代碼而不引發(fā)異常時，可能會發(fā)生無提示的錯誤。但是，讓程序快速失敗并崩潰比使錯誤靜默并繼續(xù)運行程序更好。否則會不可避免地讓后面發(fā)生的錯誤更加難以調(diào)試，因為它們與原始錯誤原因相去甚遠(yuǎn)。盡管你可以選擇忽略程序所導(dǎo)致的錯誤，但是請確保這個錯誤是被你捕獲的。
• 面對不確定性，拒絕妄加猜測(In the face of ambiguity, refuse the temptation to guess)計算機不是魔術(shù)。如果代碼無法正常工作，那是有原因的，只有謹(jǐn)慎，批判性的思維才能解決。不能盲目猜測、不加思考，隨意的掩蓋問題并不是真正地解決問題。
• 任何問題應(yīng)有一種，且最好只有一種，顯而易見的解決方法(There should be one—and preferably only one—obvious way to do it)事實證明，用三種或四種不同的方式來編寫可完成相同任務(wù)的代碼是一把雙刃劍：過于靈活的解決方法可以讓人自由發(fā)揮。但如果都是隨個人習(xí)慣實現(xiàn)，那會讓整個項目的代碼參差不齊，后期維護(hù)人員也會一頭霧水。
• 盡管這方法一開始并非如此直觀，除非你是荷蘭人(Although that way may not be obvious at first unless you're Dutch)這是一句玩笑話。吉多·范羅蘇姆是Python的創(chuàng)建者和BDFL（獨裁者）。但是，即使這樣也不能阻止Python結(jié)合三種不同的格式化字符串的方式。
• 做優(yōu)于不做，然而不假思索還不如不做(Now is better than never, Although never is often better than right now)這兩條告訴我們，掛起或陷入無限循環(huán)的代碼顯然是不好的。但是，幾乎可以肯定的是，等待程序結(jié)束總比過早結(jié)束程序而導(dǎo)致錯誤結(jié)果要好。
• 很難解釋的，必然是壞方法。很好解釋的，可能是好方法(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致力于簡化程序員的工作，而不是適應(yīng)計算機以使程序運行更快。程序不僅需要編寫它的程序員可以理解，而且還需要其他維護(hù)代碼的程序員可以理解。這兩條提醒我們，如果“高性能”代碼過于復(fù)雜以致程序員無法理解和調(diào)試，那么它就是不好的代碼。反之，很容易向其他人解釋程序的代碼，并不意味著它不是不好的代碼。編程是一件困難的事，程序員何苦為難程序員。
• 命名空間是個絕妙的主意，我們應(yīng)好好利用它(Namespaces are one honking great idea—let's do more of those)命名空間（以及全局和局部作用域）是防止一個模塊或作用域中的名稱與另一個模塊或作用域中的名稱沖突的關(guān)鍵。但也要記住，扁平比嵌套好，命名空間應(yīng)該僅用于防止命名沖突，而不能添加不必要的分類。這些都是很好的設(shè)計哲學(xué)，每個有追求的Python程序員都應(yīng)該謹(jǐn)記于心。