博客链接:http://inarrater.com/2016/07/03/pythonadvance3/
4. Bound Method和Unbound Method
声明: 本系列文章中的所有内容都是基于Python 2.x版本的,原因是网易绝大部分项目都是在用2.x版本,笔者参与过的项目无论端游还是手游都是基于Python 2.7.x版本进行的开发,因此无论经验还是课程适用性,都是在2.x范围内。在Python 3.x中,unbound method的概念已经被取消了。
上一小节说了,Bound Method和Unbound Method这部分是我参与大雄的课程中最喜欢的一部分,因为它让我窥探到了Python语言动态特性的一角,也加深了我对于平时在用的一种优化方法的认识。这部分会比较长,我们分几个小节来细说。
4.1 基本概念
先从代码来看,定义一个简单的类A:
class A(object):
def foo(self):
pass
a = A()
很简单,我们来打印一些信息来看看:
print A.foo # <unbound method A.foo>
print a.foo # <bound method A.foo of <__main__.A object at 0x023DE070>>
print A.foo == a.foo # False
print a, id(a) #<__main__.A object at 0x0235E070> 37085296
print A.foo.im_self # None
print a.foo.im_self # <__main__.A object at 0x0241E070>
为了方便对比和理解我把输出的结果放在了对应的print之后,首先输出两个A.foo
和a.foo
,看到了他们分别是两个对象,一个叫做unbound method,一个叫做bound method,很明显他们是两个不同的对象。这跟我从C++角度来理解Python的方法(Method)就有点不同了——通常静态语言中,面向对象的设计,把方法的定义放在类上,对象通过一定的机制(比如虚函数表等)查找到对应的函数地址来进行调用,那按这样推理,A.foo和a.foo应该是一个东西才对。事实证明Python语言不是这样的。
继续看后面的输出代码,我们打印了方法的im_self属性来进行查看,发现A.foo的该属性为None,a.foo.im_self的该属性为a。
那么概念上的答案就很明显了,unbound method和bound method的区别在于是否绑定了im_self属性。更加准确的是Python官方文档的描述:
While they could have been implemented that way, the actual C implementation of PyMethod_Type in Objects/classobject.c is a single object with two different representations depending on whether the im_self field is set or is NULL (the C equivalent of None).
如果你直接调用A.foo()
这种未绑定的方法,就会有这样的提示:
TypeError: unbound method foo() must be called with Foo instance as first argument (got nothing instead)
而且可以通过A.foo(a)这种方式来进行手动的绑定,这也是早期Python的一种常用调用方式。到这里可能还有很多疑问,在对基本概念进行明确之后,我们继续往下看。
思考:对象实例a的foo属性存在在哪里?
4.2 动态创建
我们来做一些分析工作:
print 1, id(a.foo) # 1 37674480
print 2, id(a.foo) # 2 37674480
# print a.__dict__ # {}
多执行几次a.foo来获取函数,发现他们的id是一样的,上面执行都是38002160,这很正常,他们看上去就应当是同一个对象。我们尝试打印a的__dict__
属性来看,结果是空的,也就是说foo这个对象不存在在a对象身上,那它存在在哪儿呢?对应的类A身上?我们刚才打印的a.foo和A.foo并不是同一个对象啊。
好,然后我们来做一点奇怪的事情:
print 1, id(a.foo) # 1 37674480
print 2, id(a.foo) # 2 37674480
m1 = a.foo
m2 = a.foo
print 3, id(m1) # 3 37674480
print 4, id(m2) # 4 37594296
什...什么鬼?!
我使用两个变量,都获取a.foo这个bound method对象,然后打印他们的id,结果m1和m2的id不同,意味着他们两个不是同一个Python对象!
思考:对象身上的方法对象,分别赋值给两个变量,结果发现它们不是同一个对象,但是之前直接执行a.foo来进行id的输出,他们的id又是一致的,这是什么神奇的逻辑?
好,在揭晓答案之前,我们再看一些分析代码:
print 1, id(a.foo) # 1 32824816
print 2, id(a.foo) # 2 32824816
m1 = a.foo
m2 = a.foo
print 3, id(m1) # 3 32824816
print 4, id(m2) # 4 32744632
print 5, id(a.foo) # 5 32824896
m2 = None
m1 = None
print 6, id(a.foo) # 6 32824816
由于多次执行,id值跟上次执行的不在相同,我们只在本次执行的代码输出中进行对比。在输出m1和m2的id之后,我们再次输出a.foo
的id,发现它改变了。=_=,好吧,我已经见怪不怪了,当我删除了m2和m1两个变量之后,再次查看id( a.foo )
,它又变回了原来的值32824816。。。
如果你还没有看出什么端倪,那可能会有种被逼疯了的感觉。
但是,通过这个id的值来看,有没有中似乎什么对象被复用了的感觉?
Python是有小对象缓存池机制的,对于int、float,string甚至tuple、list都会有不同的对象缓存机制,那这里a.foo
返回的对象是被缓存过的,才会出现重复的id。
本来在印象中,应当是一个对象就可以搞定的事情,为什么有多个对象,还要有缓存池?那是因为——
Bound & unbound methods are almost temporary instance objects.
是的,无论bound还是unbound method,几乎都是临时的实例对象。
m1 = A.foo
m2 = A.foo
print 7, id(m1) # 7 36625904
print 8, id(m2) # 8 36545720
它们这些对象在通过.
进行属性访问的时候创建,这里有个疑问我暂时没有查到,这一创建过程是在__getattr__
方法中还是在__getattribute__
方法中?暂时没有查到,需要再去看下源码。
动态创建,加上缓存池的应用,共同造成了上述的id变化的现象。由于id(a.foo)
这行代码在执行完毕之后,对于当时创建的对象的引用就已经为0了,因此会被立即释放,Python出于性能的考虑,把这个对象放入了池中,再次执行id(a.foo)
的时候,不再重新创建对象,而是从缓存池中去拿,因此id是一样的,当使用m1这样的属性引用住了对象的时候,再次调用a.foo
,就会创建一个新的对象,因此id就不同了。当del m1
之后,释放的对象又重新放回到缓存池,等待被复用。
思考: 如果我把m1、m2两个变量的释放顺序反过来,然后再去取id,会有有不同?
我们通过代码来看一下:
print 1, id(a.foo) # 2 37281264
print 2, id(a.foo) # 2 37281264
m1 = a.foo
m2 = a.foo
print 3, id(m1) # 3 37281264
print 4, id(m2) # 4 37201080
print 5, id(a.foo) # 5 32824896
m1 = None
m2 = None
print 6, id(a.foo) # 6 37201080
解释这个现象很容易——缓存池是使用栈的数据结构来存储的,按照对象归还顺序入栈,获取的时候从栈顶拿,那么后面获取的对象就是栈顶最新归还的对象。
4.3 foo在哪里
Bound method和Unbound method对象都是在调用的时刻创建,然后引用计数为0的时候被释放,这解释了他们从哪儿来到哪儿去的问题,但是还没有解释这些方法执行的时候调用的代码在哪里。
前面提到了一个点,就是a身上的__dict__
里并没有foo变量,但是也可以调用到foo方法,这是Python的属性获取机制来决定,首先从self的__dict__
中检索,如果没找到会从type(self)的__dict__
中检索,这里就是A,可以看下A的__dict__
属性:
print A.__dict__
# {'__dict__': <attribute '__dict__' of 'A' objects>, '__module__': '__main__', 'foo': <function foo at 0x024CA4B0>, '__weakref__': <attribute '__weakref__' of 'A' objects>, '__doc__': None}
这里有个key为foo的对象,注意,它是一个function对象,而不是unbound method对象,这也证明了它的动态生成。那a.foo这个bound method对象是如何访问到这个function对象的呢?我们来看一下:
print A.foo.im_func, a.foo.im_func # <function foo at 0x0254A4B0> <function foo at 0x0254A4B0>
print A.foo.im_class, a.foo.im_class # <class '__main__.A'> <class '__main__.A'>
无论是bound method还是unbound method,都是有im_func和im_class这两个属性的,其中im_func属性就是A.__dict__
中的foo对象,im_class就是A对象,这样就不难猜测a.foo调用过程中的过程,最终是通过im_class和im_func来找到真正执行的代码。
4.4 Python语言的动态特性
思考: 说了这么多,理解了原理,那么Python语言为什么要这么设计呢?
这么设计其实是为了实现Python的动态特性,我们来看一个例子:
class A(object):
def foo(self):
return 'A'
def foo(self):
return 'B'
a = A()
print foo, A.foo.im_func, a.foo.im_func # <function foo at 0x0230A2B0> <function foo at 0x0239A4B0> <function foo at 0x0239A4B0>
A.foo = foo
print foo, A.foo.im_func, a.foo.im_func # <function foo at 0x0230A2B0> <function foo at 0x0230A2B0> <function foo at 0x0230A2B0>
print a.foo() # B
print A.foo(a) # B
这段代码其实是游戏中常用的hotfix的一种实现原来的demo。
所谓hotfix,是指在玩家不知情的情况下,替换掉客户端脚本代码中的部分逻辑,实现修复bug的目的。
对于静态语言,进行这种运行时修改代码比较麻烦,而且像ios这样的平台禁止了在数据段执行代码,也就是你无法动态替换dll,使用native的语言或者C#的几乎不能方便地进行hotfix,这也是脚本语言在游戏行业里(尤其国内)面非常常用的原因。
上述例子中,A.foo = foo
这句代码替换了A的__dict__
中的foo对象,由于方法对象都是在使用时动态生成的,因此无论是新创建的对象还是已经在内存中存在的对象,都会在调用方法的时候重新生成方法对象,它们的im_func属性就指向了类中的新的属性对象。
4.5 代价
动态的代价,就是慢。
C++静态语言的方法调用,即使考虑继承的情况,也不过是一次虚表的查询操作,而python中不但有各种__dict__
检索,而且要通过__mro__
属性向继承的父类进行搜索,这块具体的过程在后面进行分析。然后加上对象的创建过程,影响效率可想而知。
因此,我们在代码中常用的一种优化是:
如果在一段代码中有对于对象属性的频繁访问,在不会修改其内容的前提下,通常会使用一个局部变量保存属性的应用供后面的代码逻辑使用。
代码中通常会有a.b.c.d.func()
这样的调用,如果这段逻辑在一个循环中,就可以先定义一个func = a.b.c.d.func
,然后通过func()来进行函数调用即可。
性能差别有多大?我们使用Python的timeit来做一些测试:
import timeit
class A(object):
def __init__(self):
self.value = 0
def foo(self):
pass
a = A()
n = 100000000
print timeit.Timer('a.foo', 'from __main__ import a').timeit(n)
m = a.foo
print timeit.Timer('m', 'from __main__ import m').timeit(n)
输出结果
6.63377350532
1.8554838526
在执行一亿次的情况下,是6.6s和1.8s的差距。注意这里并没有真正执行foo函数,而只是获取这个属性。其实这里我有一个疑问,是属性访问导致的这么大的性能差异,还是bound method对象的生成呢?于是我又添加了对于value属性的访问测试:
value = a.value
print timeit.Timer('a.value', 'from __main__ import a').timeit(n)
m = a.foo
print timeit.Timer('value', 'from __main__ import value').timeit(n)
输出结果:
4.79706941201
1.85150998879
可以看到,单纯的属性访问也是有很大的性能差异的,但是即使在有缓存池的情况下,同样通过.
来访问属性与访问方法,也有较大的性能差异,这就是Python为了实现动态特性所付出的代价之一。
总结:从一个语言概念,探究到语言的实现,再到把这个语言特性应用到工程中,这需要技术的积累和积淀,而透过初看难以理解的现象分析出问题的本质,需要更多耐心和经验。
2016年7月2日晚于杭州家中