python之「禪」

這次，我們來討論一下Python的設計哲學。首先一樣，打開我們的Python IDLE(或是其他開發環境)。輸入import this。 <a href="http://www.playrobot.com/robotpress/wp-content/uploads/2018/09/p03-01.png"><img class="wp-image-5957 size-full" src="http://www.playrobot.com/robotpress/wp-content/uploads/2018/09/p03-01.png" alt="p03-01" width="449" height="300" /></a> 執行後，會出現一篇文章。我們這次使用Anaconda的Spyder作為示範，當然，不管使用何種IDLE都會看到差不多的結果： <a href="http://www.playrobot.com/robotpress/wp-content/uploads/2018/09/p03-02.png"><img class="alignnone size-full wp-image-5958" src="http://www.playrobot.com/robotpress/wp-content/uploads/2018/09/p03-02.png" alt="p03-02" width="506" height="346" /></a> 我們下面提供了一些解釋： The Zen of Python, by Tim Peters Python之禪，Tim Peters作於1999年   Beautiful is better than ugly. 優美勝於醜陋。 Python，以編寫優美的程式碼為目標。 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. 錯誤不該被無聲地忽略。 防錯檢查盡量捕捉所有的錯誤（不要以except pass忽略它） 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之父（他是荷蘭人）。 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! 命名空間是個絕妙的點子，我們應當多加利用！ 善用python的命名空間。   上面的「禪」中有幾個有趣的地方： - 程式設計原則大於縮短程式碼。這在進入業界工作後會更有體會，當你和人協作時得去猜測變數x到底是指什麼的時候就會知道了...... - 比起一直思考怎麼寫，直接動手會比較快。這和現在的一些開發原則有異曲同工之妙，同時也是python為什麼受歡迎的原因：容許快速地多次迭代。 - 容易說明的程式才是好程式，這在一般程式上毫無疑問，但AI類的程式我想大多都是壞程式－－尤其是現在神經網路時代根本沒人可以講清楚為什麼會有這些表現狀況。 - Dutch是荷蘭人的代稱，用來指Python之父吉多·范·羅蘇姆(Guido van Rossum)。 - 最有趣的其實是，10個設計師讀這篇禪可能會有10種不同解釋，恰好對應不同領域的工程師其看重的點和使用的語言背景不同的狀況。但是，當我們打開this的原始檔時，可以發現更有趣的地方－－尤其是this的原始碼完全違反上面打的那坨東西－－這就留待下次再討論吧。