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。如果您有任何独到的见解或者发现也欢迎后台联系我们,一起探讨。

责任编辑:

你可能感兴趣的:(python进阶课程)