博客链接：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 #
print a.foo # >
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__': , '__module__': '__main__', 'foo': , '__weakref__': , '__doc__': None}
这里有个key为foo的对象，注意，它是一个function对象，而不是unbound method对象，这也证明了它的动态生成。那a.foo这个bound method对象是如何访问到这个function对象的呢？我们来看一下：
print A.foo.im_func, a.foo.im_func #
print A.foo.im_class, a.foo.im_class #
无论是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 #
A.foo = foo
print foo, A.foo.im_func, a.foo.im_func #
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日晚于杭州家中