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

文章轉(zhuǎn)載自：微信公眾號(hào) Python的樂趣

作者：一粒米飯

在Python的解釋器中隱藏一個(gè)彩蛋，輸入import this就會(huì)返回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è)計(jì)理念開始是在Python郵件列表中發(fā)表，它包含了影響Python編程語(yǔ)言設(shè)計(jì)的19條軟件編寫原則。在最初及后來(lái)的一些版本中，一共包含20條，其中第20條是“這一條留空（...）請(qǐng) Guido 來(lái)填寫”。這留空的一條從未公布也可能并不存在。

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

1. 盡可能從其他地方借用想法，只有它有意義。
2. “事情應(yīng)該盡可能簡(jiǎn)單，但不要簡(jiǎn)單。” （來(lái)自愛因斯坦）
3. 做好一件事情。（來(lái)自UNIX哲學(xué)）
4. 不要太擔(dān)心性能，可以在后面需要時(shí)進(jìn)行優(yōu)化。
5. 不要與環(huán)境抗?fàn)?，順其自然?
6. 不要嘗試完美，因?yàn)椤白銐蚝谩蓖ǔ＞褪沁@樣。
7. （因此）有時(shí)可以偷工減料，尤其是后面可以完善的情況下。

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

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

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

    3. 支持和鼓勵(lì)獨(dú)立于平臺(tái)的用戶代碼，但不要中斷對(duì)平臺(tái)功能或?qū)傩缘脑L問(wèn)（這與Java形成鮮明對(duì)比）。

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

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

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

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

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

下面，再來(lái)簡(jiǎn)單說(shuō)下這19條Python之禪的含義。

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