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对象也是一个名字空间，不过这些名字空间通过一些特殊的规则关联在一起，使得符号的搜索过程变得复杂，从而实现了面向对象这种编程模式