Python进阶(一)

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

    原文作者:董夕
    原文地址: https://www.jianshu.com/p/b24ece2e9919
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞