python进阶课程_Python进阶课程笔记(一)

原标题：Python进阶课程笔记(一)

这周听了三节Python进阶课程，有十几年的老程序给你讲课传授一门语言的进阶知识，也许这是在大公司才能享受到的福利。虽然接触使用Python也有三四年时间了，但是从课程中还是学习到不少东西，掌握了新技巧的用法，明白了老知识背后的原因。

下载了课件，做了笔记，但我还是希望用讲述的方式把它们表现出来，为未来的自己，也给需要的读者。整体以大雄的课程为蓝本，结合我在开发中的一些自己的体会和想法。

1. 写操作对于命名空间的影响

首先来看这样一段代码：

import mathdef foo(processed): value = math.pi # The other programmer add logic here. if processed: import math value = math.sin(value) print valuefoo(True)

思考：你觉得这段代码有没有什么问题，它的运行结果是什么？

首先，我个人不喜欢在代码中进行import math的操作的方式，通常会建议把这一操作放置到文件头部，这主要处于性能的考虑——虽然已经import过的模块不会重复执行加载过程，但毕竟有一次从sys.modules中查询的过程。这种操作在tick等高频执行的逻辑中尤其要去避免。

但这并不是这段代码的问题所在的重点，当你尝试执行这段代码的时候，会输出如下的错误：

Traceback (most recent call last): File "C:UsersDavid-PCDesktopAdvanced Course on Python 2016t019.py", line 13, in foo(True) File "C:UsersDavid-PCDesktopAdvanced Course on Python 2016t019.py", line 4, in foo value = math.piUnboundLocalError: local variable 'math' referenced before assignment

在赋值之前被引用了，这似乎是在文件头部进行import的锅。这个例子稍微有点复杂，我们尝试写一段有点近似但是更简单的例子，在之前编码过程中我就遇到过类似的情况：

value = 0def foo(): if value > 0: value = 1 print valuefoo()

同样会提示value在被赋值之前被使用了，让这段代码正常运作很简单，只需要把global value放在foo函数定义的第一行就可以了。

思考: 为什么在foo函数内部，无法访问其外部的value变量？

如果你把value = 1这一行代码注释掉，这段代码就可以正常运行，看上去对于value的赋值操作导致了我们无法正常访问一个外部的变量，无论这个赋值操作在访问操作之前还是之后。

Write operationwill 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 = callbackclass Entity(object): def __init__(self): self._animation = Animation(self._complete) def _complete(self): passe = 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的地方都需要经过迭代和整理才可以正常执行。

文末，感谢作者贾伟昊的供稿，本系列将在后面继续更新，请大家持续关注Nexus。如果您有任何独到的见解或者发现也欢迎后台联系我们，一起探讨。

责任编辑：