博客链接：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日于杭州家中
