搬家喽，新家在http://blog.csdn.net/balabalamerobert

沉寂了这么久，希望以后能多多更新

[绝对原创，转载请注明出处]

Python源码剖析

——Python执行引擎之一般表达式(2)

本文作者: Robert Chen(search.pythoner@gmail.com )

3.2     Simple.py

前面我们看了创建空的dict对象和空的list，那么如果是创建非空的dict和list时，行为又是如何的呢。这个问题很有趣，我们通过simple.py来研究：

对于simple.py，执行时的常量表co_consts自然和declare.py不同了，图11显示了与simple.py对应的co_consts和co_names：

编译得到的字节码中，前两行Python代码的字节码都是相同的，在创建非空的dict时，字节码与declare.py中的不同了：

对于DUP_TOP,Python会进行如下的动作：

不要注意的是，DUP_TOP不光增加了栈顶元素的引用计数，还将栈顶元素又一次第压入到栈中。由于在DUP_TOP之前是一个BUILD_MAP，所以会将创建的PyDictObject对象的引用计数增加1，并再次压入该PyDictObject对象。

然后会从consts中将需要插入到PyDictObject对象中的第一个元素对的键和值读取出来，都压入到栈中，完成后的情形如图12所示：

在接下来的ROT_THREE中，会做一些奇怪的动作：

其中的SET_TOP等宏也是在PyEval_EvalFrame中定义的：

其实ROT_THREE并没有干什么有实际意义的事，所做的就是将栈顶的三个元素来了个乾坤大挪移。ROT_THREE操作完成后的情形如图13所示。

随后的STORE_SUBSCR会将元素插入到PyDictObject对象中去：

随着STACKADJ的执行，栈顶指针回退了3格，所以STORE_SUBSCR执行完后，运行时栈里又只剩下了最初由BUILD_MAP创建的PyDictObject对象。到这里，就完成了将一个元素对插入到PyDictObject的操作。剩下的不过是重复上面的动作，将第二个元素对插入到PyDictObject对象中去。最后由我们的老朋友STORE_NAME完成将这个PyDictObject对象添加到f->f_locals中的工作。最后的情形如图14所示：

在成功创建了PyDictObject对象之后，会创建一个非空的PyListObject对象：

从这里可以看到，确实Python会首先将会填入PyListObject对象的元素先从consts读入，压入运行时栈，然后如之前描述的，BUILD_LIST再创建PyListObject对象之后，会从栈中依次将元素读出，从后至前地填入PyListObject对象中。

3.3     simple2.py

到了这里，对于一般的声明语句或常量赋值表达式，我们都已经了如指掌。下面，通过研究如下的simple2.py，考察变量赋值，变量运算以及最基本的print操作，完成对一般Python语句的考察：

编译完成后，其co_consts和co_names如图15所示：

第一条Python代码现在我们已经很熟悉了，不用再费唇舌。现在看第二条，变量间的赋值：

对于STORE_NAME，已经摸清楚它到底干了些什么。而对于LOAD_NAME，我们还是第一次遇到：

首先，会从names中抽取出第0个元素，参考前面的simple2.py编译的结果，可知是一个PyStringObject对象“a”。然后检查当前PyFrameObject中所维护的局部变量集合f->f_locals，如果这个东西不存在，那么直接返回（why？），如果局部变量集合存在，就会进行一系列的搜索动作：

[1]：在局部变量集合f_locals中搜索“a”。

[2]：如果f_locals中没有“a”,则在全局变量集合f_globals中搜索“a”。

[3]：如果f_globals中没有“a”，则在Python运行时内建变量集合f_builtins中搜索“a”。

如果搜索到了与“a”对应的元素，那么就将该元素返回。在simple2.py这个例子中，第一条Python代码的执行会在f_locals中插入（“a”，1）的元素对，所以这里会返回PyIntObject对象1。

如果到了最后还搜索不到“a”，那么表示有错误发生，程序引用了一个不存在的符号。

这样的行为正是Python官方文档中所描述的变量的搜索会沿着局部作用域，全局作用域，内建作用域依次上溯，直至搜索成功或全部搜完三个作用域。

现在很清楚了，在b = a执行完成后，内存中的情形如图16所示：

而从前面我们对PyIntObject对象的分析可知，这两个1实际上指向内存中的同一个PyIntObject对象。

现在a，b都是合法而有效的变量了，它们的结合就变得很有趣了：

首先会将a和b所对应的变量值从f_locals中读取出来，压入运行时栈，然后通过BINARY_ADD计算两个变量的和，假设结果为num，最后就通过STORE_NAME,将（“c”，num）元素对插入到f_locals中。过程非常清晰，而现在我们感兴趣的就是那个从两个现有对象创造出新的对象的BINARY_ADD：

如果参与运算的两个对象都是PyIntObject对象，会直接将PyIntObject中的value提取出来相加，然后根据相加的结果创建新的PyIntObject对象作为结果返回；同样，如果是PyStringObject对象，也会选择string_concatenate加快速度。如果参与运算的对象落在了这两种有加速机制的情况之外，那么很不幸，只能通过PyNumber_Add完成运算，PyNumber_Add会进行大量的类型判断，寻找操作函数等额外工作，速度会比前两种加速机制慢上很多。一般来说，Python在PyNumber_Add中会首先检查PyNumberMethods中的nb_add能否完成在v和w上的加法运算，如果不能，还会检查PySequenceMethods中的sq_concat能否完成，如果都不能，Python也是有心杀敌，无力回天了，那也只好报告错误了。

可以看到，Python2.4.1在这里假设了用户在使用Python时，大量进行的加法操作是整数的加法和字符串的连接。其实如果你的程序中涉及到了大量的浮点运算，那你完全可以修改BINARY_ADD的代码，为浮点加法运算建立快速通道。实际上，对于加，减，乘，除这些操作，你都可以根据自己程序的实际情况对Python的代码进行改动，这样的改动应该对提升程序运行效率有很大的好处。

最后看一看print的动作，前面分析的byte code都是Python自己跟自己玩，这个print则是Python跟咱们用户玩，也是Python中最常用和易用的用户交互方式：

其中LOAD_NAME首先将刚才获得的那个加法运算的和c从f_locals中读取出来，压入运行时栈，然后通过PRINT_ITEM完成输出的魔法：

实际上输出的时候会进行很多动作，但是在这里，我们只考虑其大致的流程。首先会将待输出的对象从运行时栈中取出。然后，判断如果stream为NULL，则将w设为标准输出流。这个stream是什么东西呢？它实际上也是一个PyObject对象：

PyObject *stream = NULL;    /* for PRINT opcodes */

如果输出的时候，是通过如下的Python代码：print >> file, “str”

那么所产生的byte code中还有一个PRINT_ITEM_TO：

显然，这时在运行时栈中，在待输出对象之前，还会有一个对象，即输出的目标。在执行PRINT_ITEM_TO时，输出的目标就赋给了stream，同时也赋给了w。所以实际上stream是作为一个判断条件来使用的，真正使用的输出目标是w。要多使用这一个stream的原因是w在别的byte code中可能还会使用到，所以无法通过判断w是否为NULL来确定是否输出到标准输出流。

可以看到，在PRINT_ITEM最后，又将stream设为了NULL，又可以为下次输出时的判断做准备了。

在获得了输出的目标和待输出的对象后，PRINT_ITEM将通过PyFile_WriteObject -> PyObject_Print -> internal_print的调用序列最终调用v->ob_type->tp_print，即待输出对象自身所携带的输出函数进行输出。如果对象没有定义tp_print，那么会先调用tp_str或tp_repr获得对象的字符串表示形式，将字符串输出，如果这也失败了，Python也无能为力了，只好返回失败信息。

[绝对原创，转载请注明出处]

Python源码剖析

——Python执行引擎之一般表达式(1)

本文作者: Robert Chen(search.pythoner@gmail.com )

1     Declare.py

对于declare.py，我们可以解析其生成的pyc文件，解析的结果如图4所示，看一看co_consts和co_names究竟都有些什么：

这些就是declare.py中关于程序运行的重要信息。这些信息在byte code的执行过程中必不可少，在随后的描述中可以看得很清楚。

PyEval_EvalFram中还定义了一些宏，这些宏包括对栈的各种操作以及对tuple元素的访问操作，在执行byte code时，会大量使用这些宏。

我们首先来看一看对第一行Python代码的执行：

其中红色的部分表示当前的字节码指令对源文件中的哪个符号或常量进行了操作，或产生了影响。

在开始之前，我们先通过图5观察一下内存中栈以及f->f_locals的情况，前面说了，f->f_locals将存储程序执行过程中的局部变量，实际也就是Python执行引擎的局部变量表，也是一举足轻重的主儿：）

对于LOAD_CONST，执行引擎的动作如下

其中，GETITEM(consts, oparg)显然就是GETITEM(consts, 0)。LOAD_CONST的意图很明显，就是从consts中读取一个元素，然后将其压入到Python的运行时栈中。LOAD_CONST完成后的情况如图6所示：

LOAD_CONST只改变了运行时栈，而对f->f_locals没有任何改变。这个对f->f_locals的改变将在STORE_NAME中完成：

在这里，我们只考虑f->f_locals确实是PyDictObject对象的情况。STORE_NAME首先从names中读取一个元素，作为变量名，然后将刚才LOAD_CONST读取的元素作为变量值，将（变量名，变量值）元素对添加到f->f_locals中。

好了，到了这里，可以很清晰地看到Python代码中变量名与变量值在内存中是通过怎样的一种方式捆绑在一起的了。LOAD_CONST完成后的情况如图7所示。

现在,declare.py中第一行代码执行完毕，第2行代码所产生的byte code实际上跟第一行代码是一样的，只是操作的参数不同了：

图8展示了这段byte code执行时栈和f->f_locals的动态变化：

在declare.py的第三行，我们见到了一点新鲜的东西，在这里，我们并不是简单地Load了，而是凭空创建了一个PyDictObject对象：

对于BUILD_MAP,Python运行时会创建一个空的PyDictObject对象，并把这个对象压入到运行时堆栈中：

发现了吗？这里有一件很奇怪的事。从Python源代码编译出的字节码中，可以发现，BUILD_MAP是一个带有参数的byte code，从opcode.h中也能证实这一点，但是在这里，我们看到根本没有使用这个参数，可能，这又是“历史遗留”问题 ：）

接下来的STORE_NAME我们已经非常熟悉了，看到这条byte code，实际上我们就可以看到执行完毕后的情形了，如图9所示：

对于declare.py最后一行Python代码，很奇怪，居然编译出了四条byte code：

对于BUILD_LIST，猜想上会与BUILD_MAP是一路货色，但是，BUILD_LIST比BUILD_MAP好太多了，它善待了字节码所带的参数，真正利用了这个参数，而不是BUILD_MAP那样，仅仅做个摆设：

可以看到，如果Python源代码中创建的不是一个空的list，那么在BUILD_LIST之前一定会有许多LOAD_CONST的操作，将元素压入栈中，在真正执行BUILD_LIST时，会一一从栈中弹出元素，加入到创建的PyListObject对象中。这一点我们下面会详细考察。

在执行了接下来的STORE_NAME后，似乎declare.py中指示的所有工作都完成了，最后两行是干嘛的呢？原来Python在执行了一段Code Block后，一定要返回一点东西，这两行byte code就是用来返回某些东西的：

实际的返回值在retval中，是从栈中取得的，所以RETURN_VALUE前的那条LOAD_CONST就很清楚了，这家伙将返回值压入了栈了。可以看到，压入栈中的返回值是一个NoneObject，实际上什么有价值的东西也没有返回，但这个过场还是要走的，不走，人民是不答应的：）

执行完整个declare.py的瞬间，栈已经变空了，而所有有用的信息都已经到了f->f_locals的掌握之中,如图10所示：

[绝对原创，转载请注明出处]

Python源码剖析

——Python执行引擎之框架

本文作者: Robert Chen(search.pythoner@gmail.com )

1         PyFrameObject

Python执行引擎是Python的核心，Python源代码在被编译为byte code之后，就将由Python的执行引擎接手整个工作，依次读入每一条byte code，在当前的上下文环境中执行这条byte code。如此反复推磨，所有由Python源代码所规定的动作都会如期望一样，一一展开。

在进入Python的执行引擎之前，我们先来看一看在x86的机器上，程序是以一种什么方式运行的，在这里，我们主要关注运行时栈的栈帧，如图1所示：

图1所示的运行时栈的情形可以看作是如下的C代码的运行时情形：

void f(int a, int b)

{

    printf("a=%d, b=%d\n", a, b);

}

void g()

{

    f(1, 2);

}

int main()

{

    g();

}

其中图1绿色部分对应的是g的栈帧，而黄色部分对应的是f的栈帧。对于一个函数而言，其所有的局部变量和操作都在自己的栈帧中完成，而函数之间的调用则通过创建新的栈帧完成，当然，在函数调用发生时，系统会保存上一个栈帧的栈指针esp和帧指针ebp。大致上，这就是可执行文件在x86机器上的运行原理，而Python正是在执行引擎中通过不同的实现方式模拟了这一原理。

前面我们已经知道，Python源代码经过编译之后，所有的byte code以及程序的其他信息都存放在PyCodeObject对象中，那么Python的执行引擎是否就是在这个PyCodeObject对象上进行所有的动作呢？呃，是，又不是。PyCodeObject中包含了最关键的byte code以及关于程序的所有信息。然而有一点，PyCodeObject没有包含，也不可能包含。这就是执行环境。

什么是执行环境呢，考虑下面的一个例子：

在1和2两个地方，都进行了同样的动作，即print i，显然，它们所对应的字节码是相同的，但是这两条语句的执行效果是不同的。这样的结果正是在执行环境的影响下产生的。在执行1处的print时，执行环境中，i的值为999；而在执行2处的print时，执行环境中i的值为“Python”。这种同样的名字对应不同的值，甚至不同的类型的情况，必须在运行时动态地被捕捉和维护。这些则不可能在PyCodeObject中被静态地存储。

联想到x86运行程序的机理，我们可以这样来考虑。当Python调用函数f时，会在当前的运行环境之外重新创建一个新的运行环境，在这个新的运行环境中，有一个新的名字为“i”的对象，这个新的运行环境实际上可以看成是一个新的栈帧。所以在Python真正执行的时候，它的执行引擎实际上面对的并不是一个PyCodeObject对象，而是另一个家伙——PyFrameObject，这个东西就是Python对栈帧的模拟，你看，它的名字中还有个Frame呢。

当然，对于Python而言，PyFrameObject对象不是一个我们在x86机器上看到的那个简简单单的栈帧，它实际上包含了其他更多的信息，请看：

从f_back我们可以窥见一点，在Python实际的执行中，会产生很多PyFrameObject对象，而这些对象会被链接起来，形成一个链表。是不是看出点眉目来了，这似乎正是对x86机器上栈帧间关系的模拟，在x86上，栈帧间通过esp指针和ebp指针建立了关系，使新的栈帧在结束之后能顺利回退到旧的栈帧中，而Python似乎正是利用一个指针来完成这个动作。那真实的情况是不是这样呢，这是后话，暂且按下不表 J

在f_code中存放的是一个待执行的PyCodeObject对象，而接下来的f_builtins，f_globals，f_locals正是动态的执行环境，这三个PyObject*都会指向PyDictObject对象，而在这些PyDictObject对象中，分别维护了builtin的name，global的name，local的name与对应的值之间的映射关系。想想前面的那段Python代码，在执行print i时，会首先到f_locals中去寻找PyStringObject对象‘i’，找到了之后，将其对应的值取出，并打印出来。

在PyFrameObject的开头，有一个PyObject_VAR_HEAD，这表明PyFrameObject是一个变长的对象，即每次创建的PyFrameObject对象的大小可能是不一样的。这些变动的内存是用来做什么的呢？实际上，每一个PyFrameObject对象都维护了一个PyCodeObject对象，这表明一个PyFrameObject对象和Python源代码中的一段Code是对应的，更准确地说，是和我们在研究PyCodeObject时提到的那个Code Block对应的。而在编译一段Code Block时，会计算出这段Code Block执行过程中所需要的栈空间的大小（注意，这个栈空间才是和x86机器上那个用于函数执行的栈空间相对应的概念），这个栈空间的大小存储在f_stacksize中，而这个栈正是那段变动的内存。因为不同的Code Block所需的栈空间的大小是不同的，所以这决定了PyFrameObject一定有一个PyObject_VAR_HEAD。在PyFrameObject对象所维护的栈中，存储的都是PyObject*，你可能看出来了，这个栈的起始位置是从f_localsplus开始的。呃，其实不完全正确，f_localsplus确实维护了一段变动长度的内存，但是这段内存不光是给栈使用的，而且还有别的家伙也会使用：

可见，在创建PyFrameObject对象时，额外申请的那部分内存有一部分是给PyCodeObject对象中存储的那些co_names啊，co_freevars啊，co_cellvars啊使用的，而另一部分才是给栈使用的。所以，PyFrameObject对象中的栈的起始位置是由f_valuestack维护的，而f_stacktop维护了当前的栈顶。图2是一个刚被创建的PyFrameObject对象的示意图：

2         Python执行引擎框架

当Python启动后，会首先进行Python运行时环境的初始化，这个过程非常地复杂，我们将在后面用单独的一章来剖析，这里我们架设初始化的动作已经完成，我们已经站在了执行引擎的门槛外，只需要轻轻推动一下第一张骨牌，整个执行过程就像多米诺骨牌一样，一环扣一环地展开。

这个推动第一张骨牌的地方在一个名叫PyEval_EvalFram的函数中，PyEval_EvalFrame首先会初始化一些变量，其中PyFrameObject对象中的PyCodeObject对象包含的重要信息都被照顾到了。当然，另一个重要的动作就是初始化了堆栈的栈顶指针，使其指向f->f_stacktop：

前面我们说过，在PyCodeObject对象的co_code域中保存着字节码和字节码的参数，Python执行引擎执行字节码的过程就是从头到尾遍历整个co_code域，依次执行字节码的过程。在Python的执行引擎中，利用三个变量来完成整个遍历过程，图3展示了这三个变量在遍历中某时刻的情形：

那么这个一步一步的动作是如何完成的呢，我们来看一看Python执行引擎执行字节码的整体架构，其实就是一个for循环加上一个巨大的switch/case结构，熟悉Windows编程的朋友可以想象一下Windows下那个巨大的消息循环，没错，就是那样的结构：

注意，这只是一个极其简化之后Python执行引擎的样子，如果想看Python执行引擎的尊容，请参考ceval.c中的源码。

在这个执行架构中，对字节码的一步一步地遍历正是通过几个宏来实现的：

在对PyCodeObject对象的分析中我们说过，Python的字节码有的是带参数的，有的是没有参数的，而判断是否是带参字节码是通过HAS_ARG这个宏实现的。注意对不同的字节码，next_instr的位移是不同的，但是无论如何，next_instr总是指向Python下一条要执行的字节码，很像x86机器中的那个PC寄存器，对吗？

需要提到的一点是那个名叫why的神秘变量，这个家伙指示了在退出这个巨大的for循环时Python执行引擎的状态。你知道，世事难料，Python执行引擎不一定每次执行都会寿终正寝，很有可能在执行到某条字节码的时候，产生了错误，没错，就是我们熟悉的那个“异常”，exception。这个时候，就需要知道Python执行引擎到底是因为什么原因结束了对字节码的执行，是正常结束呢，还是因为有错误发生，实在是活不下去了，why义无反顾地负担起这一重任。

变量why的取值范围在ceval.c中被定义，其实也就是Python结束字节码执行时的状态：

好了，到现在，想必你已经对Python的执行引擎的大体框架了然于胸了。当Python的执行流程进入了PyEval_EvalFrame中的那个for循环，取出第一条字节码之后，第一张多米诺骨牌已经被推倒，命运不可阻挡地降临了。一条接一条的字节码像潮水一样汹涌而来，浩浩荡荡。天玄地黄，长风浩荡，我们展开双臂，迎接那些在天地间游荡的，那些在最平凡的面孔下蕴藏着最惊人的力量的精灵——字节码。

[绝对原创 转载请注明出处]

Python源码剖析

[compile.h]

/* Bytecode object */

typedef struct {

    PyObject_HEAD

    int co_argcount;        /* #arguments, except *args */

    int co_nlocals;     /* #local variables */

    int co_stacksize;       /* #entries needed for evaluation stack */

    int co_flags;       /* CO_..., see below */

    PyObject *co_code;      /* instruction opcodes */

    PyObject *co_consts;    /* list (constants used) */

    PyObject *co_names;     /* list of strings (names used) */

    PyObject *co_varnames;  /* tuple of strings (local variable names) */

    PyObject *co_freevars;  /* tuple of strings (free variable names) */

    PyObject *co_cellvars;      /* tuple of strings (cell variable names) */

    /* The rest doesn't count for hash/cmp */

    PyObject *co_filename;  /* string (where it was loaded from) */

    PyObject *co_name;      /* string (name, for reference) */

    int co_firstlineno;     /* first source line number */

    PyObject *co_lnotab;    /* string (encoding addr<->lineno mapping) */

} PyCodeObject;

[import.c]

static void write_compiled_module(PyCodeObject *co, char *cpathname, long mtime)

{

    FILE *fp;

    fp = open_exclusive(cpathname);

    PyMarshal_WriteLongToFile(pyc_magic, fp, Py_MARSHAL_VERSION);

    /* First write a 0 for mtime */

    PyMarshal_WriteLongToFile(0L, fp, Py_MARSHAL_VERSION);

    PyMarshal_WriteObjectToFile((PyObject *)co, fp, Py_MARSHAL_VERSION);

    /* Now write the true mtime */

    fseek(fp, 4L, 0);

    PyMarshal_WriteLongToFile(mtime, fp, Py_MARSHAL_VERSION);

    fflush(fp);

    fclose(fp);

}

[marshal.c]

typedef struct {

    FILE *fp;

    int error;

    int depth;

    PyObject *strings; /* dict on marshal, list on unmarshal */

} WFILE;

#define w_byte(c, p) putc((c), (p)->fp)

static void w_long(long x, WFILE *p)

{

    w_byte((char)( x      & 0xff), p);

    w_byte((char)((x>> 8) & 0xff), p);

    w_byte((char)((x>>16) & 0xff), p);

    w_byte((char)((x>>24) & 0xff), p);

}

static void w_string(char *s, int n, WFILE *p)

{

    fwrite(s, 1, n, p->fp);

}

[marshal.c]

static void w_object(PyObject *v, WFILE *p)

{

    ……

    else if (PyCode_Check(v))

    {

        PyCodeObject *co = (PyCodeObject *)v;

        w_byte(TYPE_CODE, p);

        w_long(co->co_argcount, p);

        w_long(co->co_nlocals, p);

        w_long(co->co_stacksize, p);

        w_long(co->co_flags, p);

        w_object(co->co_code, p);

        w_object(co->co_consts, p);

        w_object(co->co_names, p);

        w_object(co->co_varnames, p);

        w_object(co->co_freevars, p);

        w_object(co->co_cellvars, p);

        w_object(co->co_filename, p);

        w_object(co->co_name, p);

        w_long(co->co_firstlineno, p);

        w_object(co->co_lnotab, p);

}

……

}

[w_object() in marshal.c]

……

else if (PyList_Check(v))

    {

        w_byte(TYPE_LIST, p);

        n = PyList_GET_SIZE(v);

        w_long((long)n, p);

        for (i = 0; i < n; i++)

        {

            w_object(PyList_GET_ITEM(v, i), p);

        }

}

……

[w_object() in marshal.c]

else if (PyInt_Check(v))

    {

        w_byte(TYPE_INT, p);

        w_long(x, p);

    }

[import.c]

#define TYPE_NULL   '0'

#define TYPE_NONE   'N'

。。。。。。

#define TYPE_INT    'i'

#define TYPE_STRING 's'

#define TYPE_INTERNED   't'

#define TYPE_STRINGREF  'R'

#define TYPE_TUPLE  '('

#define TYPE_LIST   '['

#define TYPE_CODE   'c'

[marshal.c]

typedef struct {

    FILE *fp;

    int error;

    int depth;

    PyObject *strings; /* dict on marshal, list on unmarshal */

} WFILE;

[marshal.c]

void PyMarshal_WriteObjectToFile(PyObject *x, FILE *fp, int version)

{

    WFILE wf;

    wf.fp = fp;

    wf.error = 0;

    wf.depth = 0;

    wf.strings = (version > 0) ? PyDict_New() : NULL;

    w_object(x, &wf);

}

[w_object() in marshal.c]

else if (PyString_Check(v))

    {