用python写逻辑的感受

最近工作用python写游戏逻辑，用惯了用lua写脚本，发现还是有一些地方不一样。虽然早就学了python语言，也经常用python写一些辅助工具，真正在工作的线上代码使用还是第一次。毕竟python也是脚本语言，我自己也实现过脚本语言，脚本语言的优势和便捷性在python语言中体现的淋漓尽致。下面说说用python写游戏逻辑的体会，主要对比以前写lua脚本时的感受。

python语言使用局部变量时不用local关键字。用惯了用local表示局部变量，反而用python写的一个局部变量时，老担心这个变量是不是全局变量。虽然在写lua的时候，一个应该用local表示的变量不用local时可能不会有太多问题，毕竟忘掉写local的那个变量重名的概率还是比较小的。不过根据我几年的编程经验来看，bug往往就是出现在那些看起来很不起眼的地方。等你千辛万苦找到bug时，你就会捶胸顿足的仰天长叹，妈的当时我怎么就没有发现呢。所有为了不必要的麻烦，请您一定要按照编程规范来写，该写local的地方一定要写。更进一步的，lua语言使用local也是为了效率方面的考虑。一方面，lua（所有的脚步都应该是如此吧）在搜索变量的时候，会从当前作用域开始，找不到才去全局变量作用域查找。这些工作都是脚本引擎自己在后台进行的，我们是感受不到的，也不需要感受到。虽然查找不同作用域的步骤只会多几个指令，但是当代码量很多或者执行高并发的时候就是一个很可观的开销了。而且从计算机架构体系来说，程序都有局部相关性，可能最终导致的效率差别是很大的。另一方面，全局变量会常驻内存，局部变量的声明周期到了会被gc回收。虽然这些内存看起来可以忽略不计，也许等真真遇到PB级数据量都是常态的时候，你才会明白大牛们为什么都那么在乎性能了。

python调用函数时，必须将参数个数补全，除非有默认参数。我已经习惯用lua写函数，调用函数了，我切换到用python调用函数时，发现报了一个给定函数参数不一致的错误。我立马就懵逼了，这算哪门子脚本语言，一点都不灵活，传入参数个数都有严格限制，这个不是和调用C++函数一样了吗？后来我意识到，其实我早就知道python的这种函数调用方式，只不过写lua写久了，理所当然的也认为python也是这样的。在lua中，如果传入的参数个数少于函数的参数，多余的参数则会被忽略掉；反之，少于的参数将会以null值传入。这才是理想中的脚步语言，好不。我们灵活的运用后面的特性，可以对我们的逻辑功能很好的扩展。例如，在项目中，我们经常会在原来代码功能上增加需求，通常这只需要加一个参数就可以解决问题。我们给原来的函数加一个参数，然后根据这个参数是否有值来执行新的逻辑。在新的地方调用时走新的逻辑，而旧的调用逻辑不会改变！多棒的特性，维护起来是多么的方便。当然python也可以做到，给函数加一个默认参数即可。不过我仔细想了想，从程序健壮性考虑，python这样做是对的，可以避免很多不必要的错误。本身脚本语言就很灵活了，如果对调用参数不加任何限制，以至于执行时才发现是一个参数为null导致的，将会带来很多麻烦。

不过python的面向对象特性比lua强大的多。python专门为面向对象设计有相关特性，而lua的面向对象只能通过元表的特性来实现，对面向对象的特性支持相当有限，或者说要想达到面向对象的功能，要自己用代码来实现，有点麻烦。不过脚本语言需要那么多面向对象的特性干嘛？项目中有多少特性被用到了呢？私认为python为了实现面向对象的特性好像有点复杂了，类的静态变量，类的实例，这些让像C++，java静态脚本语言来承担就好了，脚本语言用最少的特性来实现功能就好。像GO那么牛逼的语言，不也是没有面向对象，继承多态的概念么，一点也不妨碍GO能够实现多么复杂的功能。lua用元表仅有的功能就可以实现面向对象的特性，这是多么的简洁和轻便啊！

超赞的是，python语言功能确实强大，数据结构也很丰富，列表，元组，字典，集合等高级数据结构应有尽有。lua只有table一种数据结构。这一点即可以看做他们的缺点，也可以看做是优点。不过在高级程序员看来，自带越多的数据结构和内置函数，体验也越好，毕竟特定的功能实现，用python用几行代码就可以解决，而C++可能需要几十行代码解决。越少的代码表示语言的功能表达能力越强，也就意味着越少的bug。想象着用C++将一个分割字符串拆分成一个数组，每一步都要小心翼翼，生怕内存越界或者内存操作错误，很抓狂是不是！这用python处理简直不是个事，不要太爽有木有。lua这方面的处理能力就要弱很多。

以上就是一点杂想吧，写的有点大题小作，很肤浅，权当是充数了。