Python虚拟机类机制之instance对象（六）
instance对象中的__dict__
在Python虚拟机类机制之从class对象到instance对象（五）这一章中最后的属性访问算法中，我们看到“a.__dict__”这样的形式。
# 首先寻找'f'对应的descriptor(descriptor在之后会细致剖析)
# 注意：hasattr会在<class A>的mro列表中寻找符号'f'
if hasattr(A, 'f'):
descriptor = A.f
type = descriptor.__class__
if hasattr(type, '__get__') and (hasattr(type, '__set__') or 'f' not in a.__dict__):
return type.__get__(descriptor, a, A)
# 通过descriptor访问失败，在instance对象自身__dict__中寻找属性
if 'f' in a.__dict__:
return a.__dict__['f']
# instance对象的__dict__中找不到属性，返回a的基类列表中某个基类里定义的函数
# 注意：这里的descriptor实际上指向了一个普通的函数
if descriptor:
return descriptor.__get__(descriptor, a, A)
在前一章中，我们看到从<class A>创建<instance a>时，Python虚拟机仅为a申请了16个字节的内存，并没有额外创建PyDictObject对象的动作。不过在<instance a>中，24个字节的前8个字节是PyObject，后8个字节是为两个PyObject *申请的，难道谜底就在这多出的两个PyObject *？
在创建<class A>时，我们曾说到，Python虚拟机设置了一个名为tp_dictoffset的域，从名字上判断，这个可能就是instance对象中__dict__的偏移位置。下图1-1展示了我们的猜想：
图1-1 猜想中的a.__dict__
图1-1中，虚线画的dict对象就是我们期望中的a.__dict__。这个猜想可以在PyObject_GenericGetAttr中与上述的伪代码得到证实：
object.c
PyObject * PyObject_GenericGetAttr(PyObject *obj, PyObject *name)
{
PyTypeObject *tp = obj->ob_type;
PyObject *descr = NULL;
PyObject *res = NULL;
descrgetfunc f;
Py_ssize_t dictoffset;
PyObject **dictptr;
……
dictoffset = tp->tp_dictoffset;
if (dictoffset != 0) {
PyObject *dict;
//处理变长对象
if (dictoffset < 0) {
Py_ssize_t tsize;
size_t size;
tsize = ((PyVarObject *)obj)->ob_size;
if (tsize < 0)
tsize = -tsize;
size = _PyObject_VAR_SIZE(tp, tsize);
dictoffset += (long)size;
assert(dictoffset > 0);
assert(dictoffset % SIZEOF_VOID_P == 0);
}
dictptr = (PyObject **) ((char *)obj + dictoffset);
dict = *dictptr;
if (dict != NULL) {
Py_INCREF(dict);
res = PyDict_GetItem(dict, name);
……
}
}
……
}
如果dictoffset小于0，意味着A是继承自str这样的变长对象，Python虚拟机会对dictoffset进行一些处理，最终仍然会使dictoffset指向a的内存额外申请的位置。而PyObject_GenericGetAttr正是根据这个dictoffset获得一个dict对象。更进一步，查看函数g中有设置self（即<instance a>）中设置的a属性，这个instance对象的属性设置动作也会访问a.__dict__，而且这个动作最终调用的PyObject_GenericSetAttr也是a.__dict__最初被创建的地方：
object.c
int PyObject_GenericSetAttr(PyObject *obj, PyObject *name, PyObject *value)
{
PyTypeObject *tp = obj->ob_type;
PyObject *descr;
……
dictptr = _PyObject_GetDictPtr(obj);
if (dictptr != NULL) {
PyObject *dict = *dictptr;
if (dict == NULL && value != NULL) {
dict = PyDict_New();
if (dict == NULL)
goto done;
*dictptr = dict;
}
……
}
……
}
其中_PyObject_GetDictPtr的代码就是PyObject_GenericGetAttr中根据dictoffset获得dict对象的那段代码
再论descriptor
在上面的伪代码中出现了“descriptor”，这个命名其实是有意为之，目的是唤起前面我们在Python虚拟机类机制之填充tp_dict（二）这一章中所描述过的descriptor。前面我们看到，在PyType_Ready中，Python虚拟机会填充tp_dict，其中与操作名对应的是一个个descriptor，那时我们看到的是descriptor这个概念在Python内部是如何实现的。现在，我们将要剖析的是descriptor在Python的类机制究竟会起到怎样的作用
在Python虚拟机对class对象或instance对象进行属性访问时，descriptor将对属性访问的行为产生重大的影响，一般而言，对于一个Python中的对象obj，如果obj.__class__对应的class对象中存在__get__、__set__和__delete__三种操作，那么obj就可以称为Python的一个descriptor。在slotdefs中，我们会看到__get__、__set__、__delete__对应的操作：
typeobject.c
static slotdef slotdefs[] = {
……
TPSLOT("__get__", tp_descr_get, slot_tp_descr_get, wrap_descr_get,
"descr.__get__(obj[, type]) -> value"),
TPSLOT("__set__", tp_descr_set, slot_tp_descr_set, wrap_descr_set,
"descr.__set__(obj, value)"),
TPSLOT("__delete__", tp_descr_set, slot_tp_descr_set,
wrap_descr_delete, "descr.__delete__(obj)"),
……
}
在前面几章我们看到了PyWrapperDescrObject、PyMethodDescrObject等对象，它们对应的class对象中分别为tp_descr_get设置了wrapperdescr_get、method_get等函数，所以，它们是descriptor
如果细分，那么descriptor还可分为如下两种：
- data descriptor：type中定义了__get__和__set__的descriptor
- non data descriptor：type中只定义了__get__的descriptor
在Python虚拟机访问instance对象的属性时，descriptor的一个作用是影响Python虚拟机对属性的选择。从PyObject_GenericGetAttr的伪代码可以看出，Python虚拟机会在instance对象自身的__dict__中寻找属性，也会在instance对象对应的class的mro列表中寻找属性，我们将前一种属性称为instance属性，而后一种称为class属性
虽然PyObject_GenericGetAttr里对属性进行选择的算法比较复杂，但是从最终的效果上，我们可以总结处如下的两条规则：
- Python虚拟机按照instance属性、class属性的顺序选择属性，即instance属性优先于class属性
- 如果在class属性中发现同名的data descriptor，那么该descriptor会优先于instance属性被Python虚拟机选择
这两条规则在对属性进行设置时仍然会被严格遵守，换句话说，如果执行"a.value = 1"，就算在A中发现一个名为"value"的no data descriptor，那么还是会设置a.__dict__['value'] = 1，而不会设置A中已有的属性
当最终获得的属性是一个descriptor，最神奇的事发生了，Python虚拟机不是简单的返回descriptor，而是如伪代码所示的那样，调用descriptor.__get__，将调用的结果返回，在下面的代码示例中，展示了descriptor对属性访问行为的影响：
descriptor改变返回值
>>> class A(list): ... def __get__(self, instance, owner): ... return "A.__get__" ... >>> class B(object): ... value = A() ... >>> b = B() >>> b.value 'A.__get__' >>> s = b.value >>> type(s) <class 'str'>
instance属性优先于non data descriptor
>>> class A(list): ... def __get__(self, instance, owner): ... return "A.__get__" ... >>> class B(object): ... value = A() ... >>> b = B() >>> b.value = 1 >>> b.__dict__["value"] 1 >>> b.__class__.__dict__["value"] []
data descriptor优先于instance属性
>>> class A(list):
... def __get__(self, instance, owner):
... return "A.__get__"
... def __set__(self, instance, value):
... print("A.__set__")
... self.append(value)
...
>>> class B(object):
... value = A()
...
>>> b = B()
>>> b.value = 1
A.__set__
>>> b.__dict__["value"]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 'value'
>>> b.__class__.__dict__["value"]
[1]
前面我们说，当访问的属性最终对应的是一个descriptor时，会调用其__get__方法，并将__get__的结果作为返回。其实这个说法不是完全正确的，仔细对比type_getattro和PyObject_GenericGetAttr的代码，我们会发现它们在对待descriptor上存在差异。在PyObject_GenericGetAttr中，如果查询到的descriptor存在于class对象的tp_dict中，会调用其__get__方法；若它存在于instance对象的tp_dict中，则不会调用其__get__方法
>>> class A(object): ... def __get__(self, instance, owner): ... return "Python" ... >>> class B(object): ... desc_in_class = A() ... >>> B.desc_in_class 'Python' >>> b = B() >>> b.desc_in_class 'Python' >>> b.desc_in_class = A() >>> b.desc_in_class <__main__.A object at 0x000000FBDD76C908>
到这里，我们已经看到，descriptor对属性访问的影响主要在两个方面：其一是对访问顺序的影响，其二是对访问结果的影响，第二种影响正是类的成员函数调用的关键
函数变身
demo1.py
class A(object):
name = "Python"
def __init__(self):
print("A::__init__")
def f(self):
print("A::f")
def g(self, aValue):
self.value = aValue
print(self.value)
a = A()
a.f()
a.g(10)
在前面讨论创建class A对象时，我们看到A.__dict__中保存了一个与符号"f"对应的PyFunctionObject对象，所以在伪代码中的descriptor对应的就是一个PyFunctionObject对象。先抛开伪代码中确定最终返回值的过程不说，我们从另一个角度来看一看，假设PyFunctionObject作为LOAD_ATTR的最终结果，在LOAD_ATTR指令代码的最后被SET_TOP压入到运行时栈，那会有什么后果呢？
在A的成员函数f的def语句中，我们看到一个self参数，self在Python中是不是一个有效的参数呢？还是它仅仅是语法意义上的占位符？这一点可以从g中看到答案，在函数g中有再这样的语句：self.value = aValue。这条语句毫无疑问地揭示了self是一个货真价实的参数，所以也表明了函数f也是一个带参函数。现在，问题来了，根据我们之前对函数机制的分析，Python通常会将参数事先压入运行时栈中，但是demo1.py中的a.f语句编译后的指令序列中可以看到，Python在获得a.f对应的对象后，没有进行任何普通函数调用时将参数压入栈的动作，而是直接执行了CALL_FUNCTION指令
a.f()调用指令
16 31 LOAD_NAME 2 (a) 34 LOAD_ATTR 3 (f) 37 CALL_FUNCTION 0 40 POP_TOP
这里没有任何像参数的东西在栈中，栈中只有一个可能是a.f的PyFunctionObject对象，那么这个遗失的self参数究竟在什么地方？
既然栈中没有参数，而栈中唯一的PyFunctionObject对象又需要参数，那么说明，我们之前的推理可能是错误的，所以，栈中的对象只能是另一种我们尚未了结的对象，由于是通过访问属性"f"得到的这个对象，所以一个合理的假设是：在这个对象中，还包含函数f的参数：self
在之前介绍函数机制的时候，我们似乎忘记介绍一个对象PyFunction_Type，这是PyFunctionObject对象对应的class对象，观察PyFunction_Type对象，我们会发现与__get__对应的tp_descr_get被设置为&func_descr_get，这意味着这里的A.f实际上是一个descriptor。由于PyFunc_Type中并没有设置func_descr_set，所以A.f是一个non data descriptor。此外，由于在a.__dict__中没有f符号的存在，所以根据伪代码中的算法，a.f的的返回值将被descriptor改变，其结果将是A.f.__get__，也就是func_descr_get(A.f, a, A)
funcobject.c
PyTypeObject PyFunction_Type = {
……
func_descr_get, /* tp_descr_get */
……
};
……
static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
if (obj == Py_None)
obj = NULL;
return PyMethod_New(func, obj, type);
}
func_descr_get将A.f对应的PyFunctionObject进行了一番包装，通过PyMethod_New在PyFunctionObject的基础上创建了一个新的对象，于是，我们再进入到PyMethod_New
funcobject.c
PyObject * PyMethod_New(PyObject *func, PyObject *self, PyObject *klass)
{
register PyMethodObject *im;
……
im = free_list;
if (im != NULL) {
//使用缓冲池
free_list = (PyMethodObject *)(im->im_self);
PyObject_INIT(im, &PyMethod_Type);
}
else {
//不使用缓冲池，直接创建PyMethodObject对象
im = PyObject_GC_New(PyMethodObject, &PyMethod_Type);
if (im == NULL)
return NULL;
}
im->im_weakreflist = NULL;
Py_INCREF(func);
im->im_func = func;
Py_XINCREF(self);
//这里就是self对象
im->im_self = self;
Py_XINCREF(klass);
im->im_class = klass;
_PyObject_GC_TRACK(im);
return (PyObject *)im;
}
这里我们可以知道，原先运行时栈中已经不再是PyFunctionObject对象，而是PyMethodObject对象。看到free_list这样熟悉的字眼，我们可以立即判断出，在PyMethodObject的实现和管理中，Python采用了缓冲池的技术，现在来看一看这个PyMethodObject
typedef struct {
PyObject_HEAD
PyObject *im_func; //可调用的PyFunctionObject对象
PyObject *im_self; //用于成员函数调用的self参数，instance对象
PyObject *im_class; //class对象
PyObject *im_weakreflist;
} PyMethodObject;
在PyMethod_New中，分别将im_func、im_self、im_class设置了不同的值，结合a.f，分别对应符号"f"所对应的PyFunctionObject对象，符号"a"对应的instance对象，以及<class A>对象
在Python中，将PyFunctionObject对象和一个instance对象通过PyMethodObject对象结合在一起的过程就称为成员函数的绑定。下面的代码清晰地展示了在访问属性时，发生函数绑定的结果：
>>> class A(object): ... def f(self): ... pass ... >>> a = A() >>> a.__class__.__dict__["f"] <function A.f at 0x000000FBDD74E620> >>> a.f <bound method A.f of <__main__.A object at 0x000000FBDD76CE80>>
无参函数的调用
在LOAD_ATTR指令之后，指令"37 CALL_FUNCTION 0"开始了函数调用的动作，之前我们研究过对于PyFunctionObject对象的调用，而对于PyMethodObject对象，情况则有些不同，如下：
ceval.c
static PyObject * call_function(PyObject ***pp_stack, int oparg)
{
int na = oparg & 0xff;
int nk = (oparg >> 8) & 0xff;
int n = na + 2 * nk;
PyObject **pfunc = (*pp_stack) - n - 1;
PyObject *func = *pfunc;
PyObject *x, *w;
……
if (PyCFunction_Check(func) && nk == 0)
{
……
}
else
{ //[1]：从PyMethodObject对象中抽取PyFunctionObject对象和self参数
if (PyMethod_Check(func) && PyMethod_GET_SELF(func) != NULL)
{
PyObject *self = PyMethod_GET_SELF(func);
func = PyMethod_GET_FUNCTION(func);
//[2]：self参数入栈，调整参数信息变量
*pfunc = self;
na++;
n++;
}
if (PyFunction_Check(func))
x = fast_function(func, pp_stack, n, na, nk);
else
x = do_call(func, pp_stack, na, nk);
……
}
……
return x;
}
调用成员函数f时，显示传入的参数个数为0，也就是说，调用f时，Python虚拟机没有进行参数入栈的动作。而f显然至少需要一个实例对象的参数，而正是在call_function中，Python虚拟机为PyMethodObject进行了一些参数处理的动作
Python虚拟机执行a.f()时，在call_function中，代码[1]处的判断将会成立，其中PyMethod_GET_SELF被定义为：
classobject.h
#define PyMethod_GET_SELF(meth) \ (((PyMethodObject *)meth) -> im_self)
在call_function中，func变量指向一个PyMethodObject对象，在上述代码[1]处成立后，在if分支中又会将PyMethodObject对象中的PyFunctionObject对象和instance对象分别提取出来，在if分支中有一处最重要的代码，即[2]处，pfunc指向的位置正是运行时栈中存放PyMethodObject对象的位置，那么这个本来属于PyMethodObject对象的地方改为存放instance对象究竟有什么作用呢？在这里，Python虚拟机以另一种方式完成了函数参数入栈的动作，本来属于PyMethodObject对象的内存空间被用作了函数f的self参数的容身之处，图1-1展示了运行call_function时运行时栈的变化情况：
图1-1 设置self参数
a是设置pfunc之前的运行时栈，b表示设置了pfunc之后的运行时栈。在call_function中，接着还会通过PyMethod_GET_FUNCTION将PyMethodObject对象中的PyFunctionObject对象取出，随后在[2]处，Python虚拟机完成了self参数的入栈，同时还调整了维护着参数信息的na和n，调整后的结果意味着函数会获得一个位置参数，看一看class A中的f的def语句，self正是一个位置参数
由于func在if分支之后指向了PyFunctionObject对象，所以接下来Python执行引擎将进入fast_function。到了这里，剩下的动作就和我们之前所分析的带参函数的调用一致。实际上a.f的调用是指上就是一个带一个位置参数的一般函数调用，而在fast_function，作为self参数的<instance a>被Python虚拟机压入到了运行时栈中，由于a.f仅仅是一个带位置参数的函数，所以Python执行引擎将进入快速通道，在快速通道中，运行时栈中的这个instance对象会被拷贝到新的PyFrameObject对象的f_localsplus中
ceval.c
static PyObject * fast_function(PyObject *func, PyObject ***pp_stack, int n, int na, int nk)
{
PyCodeObject *co = (PyCodeObject *)PyFunction_GET_CODE(func);
PyObject *globals = PyFunction_GET_GLOBALS(func);
PyObject *argdefs = PyFunction_GET_DEFAULTS(func);
PyObject **d = NULL;
int nd = 0;
PCALL(PCALL_FUNCTION);
PCALL(PCALL_FAST_FUNCTION);
if (argdefs == NULL && co->co_argcount == n && nk == 0 &&
co->co_flags == (CO_OPTIMIZED | CO_NEWLOCALS | CO_NOFREE))
{
//创建新的PyFrameObject对象f
PyFrameObject *f;
f = PyFrame_New(tstate, co, globals, NULL);
if (f == NULL)
return NULL;
fastlocals = f->f_localsplus;
//[1]：获得栈顶指针
stack = (*pp_stack) - n;
for (i = 0; i < n; i++)
{
//[2]：
fastlocals[i] = *stack++;
}
……
}
……
}
在调用fast_function时，参数的数量n已经由执行CALL_FUNCTION时的0变为了1，所以代码[1]处的stack指向的位置就和图1-1中pfunc指向的位置是一致的了，在代码的[2]处将<instance a>作为参数拷贝到函数的参数区fastlocals中，必须将它放置到栈顶，也就是以前PyMethodObject对象所在的位置上，也也就是前面call_function那个赋值操作的原因
带参函数的调用
Python虚拟机对类中带参的成员函数的调用，其原理和流程与无参函数的调用是一致的，我们来看看a.g(10)的字节码序列：
17 41 LOAD_NAME 2 (a) 44 LOAD_ATTR 4 (g) 47 LOAD_CONST 2 (10) 50 CALL_FUNCTION 1 53 POP_TOP
可以看到，和调用成员函数f的指令序列几乎完全一致，只是多了一个"47 LOAD_CONST 2 (10)"。对于这个指令我们不会陌生，在分析函数机制的时候，我们看到它是用来将函数所需的参数压入到运行时栈中。对于g，真正有趣的地方在于考察函数的实现代码，从而可以看到那个作为self参数的instance对象的使用：
>>> dis.dis(A.g)
11 0 LOAD_FAST 1 (aValue)
3 LOAD_FAST 0 (self)
6 STORE_ATTR 0 (value)
12 9 LOAD_FAST 0 (self)
12 LOAD_ATTR 0 (value)
15 PRINT_ITEM
16 PRINT_NEWLINE
显然，其中的LOAD_FAST、LOAD_ATTR、STORE_ATTR这些字节码指令都涉及到了作为self参数的instance对象，有兴趣的同学可以分析一下STORE_ATTR的代码，可以发现其中也有类似于LOAD_ATTR中PyObject_GenericGetAttr的属性访问算法
其实到了这里，我们可以在更高的层次俯视一下Python的运行模型，最核心的模型其实非常简单，可以简化为两条规则：
- 在某个名字空间中寻找符号对应的对象
- 对从名字空间中得到的对象进行某些操作
抛开面向对象花里胡哨的外表，其实我们会发现，class对象其实就是一个名字空间，instance对象也是一个名字空间，不过这些名字空间通过一些特殊的规则关联在一起，使得符号的搜索过程变得复杂，从而实现了面向对象这种编程模式
