Python智慧合約程式設計 -- 開篇：為什麼是Python
Python因其簡單易用，開發效率高而深受廣大開發者的喜愛和推崇。雖說程式設計最重要的是背後的思想，但是思想的表達也是非常的重要的。Python正是這種有強大表達能力的語言。Python有句名言：Life is short, use Python.中文版是：人生苦短，我用Python。可以從一個側面來了解Python是一個高效的開發語言。在科學計算，網路程式設計，人工智慧等等領域，Python有著廣泛的應用。最近的訊息顯示Python即將被納入高考內容，並且Python已經進入小學生的教材。詳見csdn公眾號文章。所以說，學習python真的是大勢所趨，沒有必要費時費力的勸說別人去學Python了。
以太坊智慧合約功能讓以太坊火了起來，甚至帶動了上一波的區塊鏈的牛市。以太坊也憑藉它的智慧合約功能坐上了區塊鏈市場的第二把交椅的位置。智慧合約將會是以後區塊鏈專案的必備的功能。但是智慧合約本身卻也有許多的問題，最明顯的就是效能和易用性問題。以太坊的solidity智慧合約語言在效能和易用性上都不盡如人意。智慧合約語言的設計並不是簡單的事情，但是卻又是區塊鏈世界必須解決的問題。既然Python這麼好用，為什麼不直接用Python作為智慧合約語言呢？其實，早期的以太坊就早就已經認識到了這個問題。最早的以太坊智慧合約語言serpent就是一種類Python的語言，後面逐漸被solidity所替代。現在以太坊又在開發
這裡就提出來一個問題：既然Python這麼好用，為什麼以太坊不直接把python作為智慧合約語言？原因是不適合。Ethereum的智慧合約是基於GAS付費模型的，需要精確的計算程式碼所佔的CPU和程式碼操作儲存空間所需的花費，以太坊稱之為GAS。而原生的Python直譯器有眾多的程式碼，相對於簡單的EVM虛擬機器來說，要複雜很多，要計算GAS比較困難。
下面來談談Python為什麼能作為Eos的智慧合約程式語言。Eos是Daniel Larimer以及他的開發團隊為我們帶來了的，因為Eos的TS是零費用的，執行智慧合約的時候計算的是CPU的執行時間，不用像Ethereum那樣去費時費力的計算每一行程式碼的GAS，使得用Python作為智慧合約的開發語言成為可能。為Python成為智慧合約語言移除了一個大阻礙。所以感謝Daniel Larimer吧，苦哈哈的開發者們看到了一絲曙光。
再來說說Python的效能問題。其實在今天這個世界裡，開發者更關注的是軟體的開發效率和維護成本。至於效能，在大多數情況下，以現在CPU的計算能力，是完全能夠滿足需求的。如果在十幾二十年前，你可能還需要為了效能而斤斤計較，但是現在，大多數應用場景下，真的不用了。並且在Python程式碼不滿足效能要求時，完全有很方便的方法來對Python程式碼進行優化以幾倍幾十倍的提高程式碼的效能。另外，二八定律也同樣適用於程式的執行。也就是說，20%的程式碼佔用了80%的執行時間。具體到Python語言，20%的bytecode佔用了80%的執行時間，並且由於Python的關鍵模組很多都是通過C來實現的，所以實際上80%的Python程式執行時間又是大部分時間裡都在執行除解釋bytecode以外的C程式碼。這也就是即使不採用優化手段，Python的效能在大多數情況下不會太差的原因。事實上，Python的list,dict等等關鍵模組的執行速度已經和C/C++寫的程式碼沒有多大的差別了。但是，有句實話還是得說：會用Python和用好Python還是有很大的差別的。當然，高效能的區塊鏈專案對智慧合約語言的效能還是有比較高的要求的，從測試的情況來看，cpython的執行速度比wasm的binaryen執行方式會快3倍以上。和wasm的wabt執行模式處於同一個資料級。這也說明了python智慧合約的執行速度是能夠滿足要求的。
最後，祭出Python之禪(Zen of Python)作為本篇的結束
Zen of Python(Python之禪)
1. Beautiful is better than ugly.
優美勝於醜陋（Python 以編寫優美的程式碼為目標）
2. Explicit is better than implicit.
明瞭勝於晦澀（優美的程式碼應當是明瞭的，命名規範，風格相似）
3. Simple is better than complex.
簡潔勝於複雜（優美的程式碼應當是簡潔的，不要有複雜的內部實現）
4. Complex is better than complicated.
複雜勝於凌亂（如果複雜不可避免，那程式碼間也不能有難懂的關係，要保持介面簡潔）
5. Flat is better than nested.
扁平勝於巢狀（優美的程式碼應當是扁平的，不能有太多的巢狀）
6. Sparse is better than dense.
間隔勝於緊湊（優美的程式碼有適當的間隔，不要奢望一行程式碼解決問題）
7. Readability counts.
可讀性很重要（優美的程式碼是可讀的）
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
即便假借特例的實用性之名，也不可違背這些規則（這些規則至高無上）
10. Errors should never pass silently.
11. Unless explicitly silenced.
不要包容所有錯誤，除非你確定需要這樣做（精準地捕獲異常，不寫except:pass風格的程式碼）
12. In the face of ambiguity, refuse the temptation to guess.
當存在多種可能，不要嘗試去猜測
13. There should be one-- and preferably only one --obvious way to do it.
而是儘量找一種，最好是唯一一種明顯的解決方案（如果不確定，就用窮舉法）
14. Although that way may not be obvious at first unless you're Dutch.
雖然這並不容易，因為你不是 Python 之父（這裡的 Dutch 是指 Guido）
15. Now is better than never.
16. Although never is often better than right now.
做也許好過不做，但不假思索就動手還不如不做（動手之前要細思量）
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
如果你無法向人描述你的方案，那肯定不是一個好方案；反之亦然（方案測評標準）
19. Namespaces are one honking great idea -- let's do more of those!
名稱空間是一種絕妙的理念，我們應當多加利用（倡導與號召）
參考連結：
http://blog.csdn.net/gzlaiyonghao/article/details/2151918