Python智能合约编程 -- 开篇：为什么是Python
Python因其简单易用，开发效率高而深受广大开发者的喜爱和推崇。虽说编程最重要的是背后的思想，但是思想的表达也是非常的重要的。Python正是这种有强大表达能力的语言。Python有句名言：Life is short, use Python.中文版是：人生苦短，我用Python。可以从一个侧面来了解Python是一个高效的开发语言。在科学计算，网络编程，人工智能等等领域，Python有着广泛的应用。最近的消息显示Python即将被纳入高考内容，并且Python已经进入小学生的教材。详见csdn公众号文章。所以说，学习python真的是大势所趋，没有必要费时费力的劝说别人去学Python了。
下面来谈谈Python为什么能作为Eos的智能合约编程语言但是却不适用于Ethereum。在Ethereum上用Solidity编写过智能合约代码的开发者，大多对Solidity不会有好感。只可惜，目前来看，他们没得选。这也是为什么Ethereum开发者还要开发另外一种语法和Python高度类似的vyper语言的原因。那Ethereum为什么不直接把python拿来用，而要费时费力的去写编译器重新开发另一种语言呢？根据本人的猜想，原因可能是原生的Python并不能适应Ethereum的基于GAS的付费模型。原生的Python除了bytecode之外，关键模块的代码都是C中实现的，这么多函数和bytecode如何去精确的计算内存和CPU的使用情况，这确实是个问题。要不然像Vitalik Buterin这样的pythoner不会认识不到Python的巨大优势。并且也解释不了为什么后面还要去设计vyper这种类Python语言。并且有趣的是,vyper的编译器也是用Python写的。实际上，Ethereum最早就是用Python开发的，后面才有C++和Go的版本，并且在这几个版本中交叉验证设计思想的实现。这也是我欣赏Ethereum的地方。虽然Ethereum上不能直接用Python来写智能合约，但是Daniel Larimer以及他的开发团队为我们带来了Eos，使得用Python作为智能合约的开发语言成为可能。因为Eos的TS是零费用的，不用像Ethereum那样去费时费力的计算GAS，为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还是有很大的差别的。当然，高性能的区块链项目对智能合约语言的性能还是有比较高的要求的，这或者可以通过pypy这样的JIT的技术来加以解决。并且，Eos已经承诺会实现并行功能，这可以大大加快TS的处理速度。
最后，祭出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!
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）
最后，对Eos有兴趣的可以扫码加入讨论群讨论。
参考链接：
http://blog.csdn.net/gzlaiyonghao/article/details/2151918
