博客链接:http://inarrater.com/2016/06/30/pythonadvance1/
这周听了三节Python进阶课程,有十几年的老程序给你讲课传授一门语言的进阶知识,也许这是在大公司才能享受到的福利。虽然接触使用Python也有三四年时间了,但是从课程中还是学习到不少东西,掌握了新技巧的用法,明白了老知识背后的原因。
下载了课件,做了笔记,但我还是希望用讲述的方式把它们表现出来,为未来的自己,也给需要的读者。整体以大雄的课程为蓝本,结合我在开发中的一些自己的体会和想法。
1. 写操作对于命名空间的影响
首先来看这样一段代码:
import math
def foo(processed):
value = math.pi
# The other programmer add logic here.
if processed:
import math
value = math.sin(value)
print value
foo(True)
思考:你觉得这段代码有没有什么问题,它的运行结果是什么?
首先,我个人不喜欢在代码中进行import math
的操作的方式,通常会建议把这一操作放置到文件头部,这主要处于性能的考虑——虽然已经import过的模块不会重复执行加载过程,但毕竟有一次从sys.modules中查询的过程。这种操作在tick等高频执行的逻辑中尤其要去避免。
但这并不是这段代码的问题所在的重点,当你尝试执行这段代码的时候,会输出如下的错误:
Traceback (most recent call last):
File "C:\Users\David-PC\Desktop\Advanced Course on Python 2016\t019.py", line 13, in <module>
foo(True)
File "C:\Users\David-PC\Desktop\Advanced Course on Python 2016\t019.py", line 4, in foo
value = math.pi
UnboundLocalError: local variable 'math' referenced before assignment
在赋值之前被引用了,这似乎是在文件头部进行import的锅。这个例子稍微有点复杂,我们尝试写一段有点近似但是更简单的例子,在之前编码过程中我就遇到过类似的情况:
value = 0
def foo():
if value > 0:
value = 1
print value
foo()
同样会提示value在被赋值之前被使用了,让这段代码正常运作很简单,只需要把global value
放在foo函数定义的第一行就可以了。
思考: 为什么在foo函数内部,无法访问其外部的value变量?
如果你把value = 1
这一行代码注释掉,这段代码就可以正常运行,看上去对于value的赋值操作导致了我们无法正常访问一个外部的变量,无论这个赋值操作在访问操作之前还是之后。
Write operation will shield the locating outside the current name space, which is determined at compile time.
简单来说,命名空间内部如果有对变量的写操作,这个变量在这个命名空间中就会被认为是local的,你的代码就不能在赋值之前使用它,而且检查过程是在编译的时候。使用global关键字可以改变这一行为。
那我们回到第一段代码,为什么imort的一个模块也无法正常被使用呢?
如果理解import的过程,答案就很简单了——import其实就是一个赋值的过程。
总结:之前我自认为Python的命名空间很容易理解,对于全局变量或者说upvalue的访问却通常不去注意,有时候觉得不需要写global来标识也可以访问得到,有时候又会遇到语法错误的提示,其实一直没有理解清楚是什么规则导致这样的结果。
写操作对于命名空间的影响解答了这一问题,让我看到自己之前“面对出错提示编程”的愚蠢和懒惰。。。
2. 循环引用
Python的垃圾回收(GC)结合了引用计数(Reference Count)、对象池(Object Pool)、标记清除(Mark and Sweep)、分代回收(Generational Collecting)这几种技术,具体的GC实现放在后面来说,我们先看代码中存在循环引用的情况。
游戏开发中设计出循环引用非常地简单,比如游戏中常用的实体(Entity)结构:
class EntityManager(object):
def __init__():
self.__entities = {}
def add_entity(eid):
#Some process code.
self.__entities[eid] = Entity(id, self)
def get_entity(eid):
return self.__entities.get(eid, None)
class Entity(object):
def __init__(eid, mgr):
self.eid = _id
self.mgr = mgr
def attact(skill_id, target_id):
target = self.mgr.get_entity(target_id)
#attack the target
#...
很明显,这里EntityManager
中的__entities
属性引用了它所控制的所有对象,而对于一个游戏实体,有时候需要能够获取别的实体对象,那么最简单的方法就是把EntityManager
的自己传递给创建出来的实体,让其保留一个引用,这样在执行攻击这样的函数的时候,就可以很方便地获取到想要拿到的数据。
EntityManager
中的__entities
属性引用了Entity
对象,Entity
对象身上的mgr属性又引用了EntityManager
对象,这就存在循环引用。
有的人也许会说,有循环引用了,so what? 首先我可以从逻辑上保证释放的时候都会把环解开,这样就可以正常释放内存了。再者,本身Python自己就提供了垃圾回收的方式,它可以帮我清理。
对于这种想法,作为一个游戏开发者,我表示——呵呵
我们看一个在游戏开发中常见的循环引用的例子,有些情况下写了循环引用而不自知(实例代码直接使用大雄课程中的)。
class Animation(object):
def __init__(self, callback):
self._callback = callback
class Entity(object):
def __init__(self):
self._animation = Animation(self._complete)
def _complete(self):
pass
e = Entity()
print e._animation._callback.im_self is e
最终print输出的结果是True,也解释了这段逻辑中的循环引用所在。
对于多人协作来实现的大型项目来说,逻辑上保证代码中没有环存在是几乎不可能的事情,况且即使你代码逻辑上可以正确释放,偶发的traceback就可能让你接环的逻辑没有被执行到,从而导致了循环引用对象的无法立即释放。
Python的循环引用处理,如果一个对象的引用计数为0的时候,该对象会立即被释放掉。
然后Python的GC是很耗的一个过程,会造成CPU瞬间的峰值等问题,网易有项目就完全自己实现了一套分片多线程的GC机制来替换掉Python原生的GC。
大量循环引用的存在会导致更慢更加频繁的GC,也会导致内存的波动。
解决方法:对于
EntityManager
的例子,使用weakref来解决;对于callback的例子,尽量避免使用对象的方法来作为一个回调。
总结:对于简单的系统来说,不需要关心循环引用的问题,交给Python的GC就够了,但是需要长时间运行,对于CPU波动敏感的系统,需要关注循环引用的影响,尽量去规避。
题外话:在我们现在的项目中,EntityManager的例子使用了单例模式来解除循环引用,这是一种常用的方法,但是单例模式也不是“银弹”。这种设计模式在限制对象实例化的同时,也提供了全局访问的接口,意味着这个单例对象变成了一个全局对象,于是代码中充满了不考虑耦合性的滥用。在客户端代码中,这些使用全局单例的逻辑没有问题,因为客户端只需要一个EntityManager就可以管理所有的游戏实体,也不会存在其他的并行环境,而当我们需要进行服务端开发的时候,同一份代码拿到服务端就变成了灾难——对于服务端来说,可能会存在很多EntityManager管理不同情境下的游戏实体,单例的模式不再可用,之前任意访问EntityManager的地方都需要经过迭代和整理才可以正常执行。
PPS:刚刚开始使用MarkDown,一些语法还不熟悉,但是用它写起这种包含代码的文章来说还是非常舒服的,这篇开头让我体会到了这一点。所以说,只有程序员这种geek生物才会喜欢Hexo等基于MarkDown需要generate成静态网页的博客。。。
2016年6月30日于杭州家中