我最近花了一些時(shí)間在探索CPython，并且我想要在這里分享我的一些冒險(xiǎn)經(jīng)歷。Allison Kaptur的excellent guide to getting started with Python internals 有一點(diǎn)啰嗦，我想逐步介紹我自己的探索過程會(huì)更加有條理性，這樣也許其他好奇的Python使用者可以跟著一起做。
1．注意到了一些奇怪的事情
一開始，我只是設(shè)置好Nose對(duì)一些我寫的Python 3代碼進(jìn)行測(cè)試。當(dāng)我運(yùn)行這些測(cè)試的時(shí)候，我得到了一個(gè)不可思議的錯(cuò)誤信息：”TypeError: bad argument type for built-in operation”，這是我之前在這個(gè)程序里沒有見到過的。
最終造成這個(gè)錯(cuò)誤的原因有一點(diǎn)顯而易見——我不小心在程序里留了一個(gè)PDB斷點(diǎn)(`import pdb; pdb.set_trace()`)。當(dāng)我把它去掉后，測(cè)試正常運(yùn)行了。
但是，我曾經(jīng)使用Nose在Python 2 repos上進(jìn)行測(cè)試，并且在那種情況下，錯(cuò)誤留下的斷點(diǎn)并不會(huì)導(dǎo)致Nose崩潰，而是看上去像是“掛起”了。程序并不是真的掛起了——它僅僅是不顯示東西到stdout（標(biāo)準(zhǔn)輸出）了。Nose是故意這樣做的，而當(dāng)我正在運(yùn)行一套測(cè)試的時(shí)候這樣做是有意義的。我可能僅僅是想看測(cè)試的結(jié)果，而不是一大堆程序自己打印出來的狀態(tài)。如果你在這個(gè)腳本里面敲擊“c”，Nose僅僅像通常那樣經(jīng)過這個(gè)斷點(diǎn)。
通常情況下，我可能只是聳聳肩，移除掉這個(gè)斷點(diǎn)，然后繼續(xù)我的工作。但是！我在一個(gè)黑客學(xué)校并且有時(shí)間深入研究任何抓住我興趣的東西，所以我決定利用這次機(jī)會(huì)去窺探一下Python的內(nèi)核。
2.制造一個(gè)最簡(jiǎn)單的測(cè)試樣例。
結(jié)果這次的問題研究起來有一點(diǎn)復(fù)雜——我并不能確定問題是在Nose，還是PDB或者CPython自己的代碼里面。并且，我當(dāng)然不能使用任何斷點(diǎn)，因?yàn)檫@些斷點(diǎn)會(huì)導(dǎo)致我的程序崩潰。
最終，在驗(yàn)證了一些假設(shè)后，看上去PDB對(duì)`input()`的調(diào)用導(dǎo)致了崩潰。所以：在Python2和Python3里面，input的實(shí)現(xiàn)有什么不同嗎？或者是其他的某些東西不同？
我和Jesse一起進(jìn)行調(diào)試，最后我們意識(shí)到Nose以一種有趣的方式處理標(biāo)準(zhǔn)輸出：
|
1
2
|
self._buf = StringIO()sys.stdout = self._buf |
這里用sys.stout表示Python中的所有標(biāo)準(zhǔn)輸出，即表示所有向終端輸出的內(nèi)容都會(huì)發(fā)送到這里。但由于我們可以像訪問其他Python變量那樣訪問sys.stout，所以我們可以改變這個(gè)sys.stout。而Nose將sys.stoud設(shè)置為StringIO()，而這只是任意一個(gè)字符串。
如果你這么做，print函數(shù)就不會(huì)工作了！
|
1
2
3
4
|
import sys, iosys.stdout = io.StringIO()print(“Hello”)# Oh no, nothing printed! |
我們懷疑是否那一行就是問題所在，所以我們構(gòu)造了一個(gè)簡(jiǎn)單的測(cè)試樣例：
|
1
2
3
4
|
import sys, iosys.stdout = io.StringIO()print("Hello!") # Nothing will appearinput("Input: ") # Raises a TypeError |
在Python 3 里面運(yùn)行這個(gè)會(huì)出現(xiàn)我們之前看到過的”bad argument for built-in operation”。所以現(xiàn)在我們知道該調(diào)查哪里了！當(dāng)你試圖改變sys.stdout的時(shí)候，內(nèi)建函數(shù)`input()`以一種奇怪的方式中斷下來。
3.了解一點(diǎn)CPython！
所以我們想要看下‘input'是怎樣實(shí)現(xiàn)的。Python有一個(gè)非常酷的模塊叫做'inspect'，能讓你檢查源代碼，像這樣：
|
1
2
3
4
5
|
>>> from collections import namedtuple>>> import inspect; print(inspect.getsource(namedtuple))def namedtuple(typename, field_names, verbose=False, rename=False):"""Returns a new subclass of tuple with named fields...... |
然而當(dāng)你想要對(duì)'input'調(diào)用'inspect.getsource'的時(shí)候，結(jié)果會(huì)是：“TypeError: is not a module, class, method, function, traceback, frame, or code object.”這意味著我們的函數(shù)不是用Python實(shí)現(xiàn)的——它是用C語(yǔ)言實(shí)現(xiàn)的，因此'inspect;模塊不能為我們顯示它的代碼。
……但是，利用cinspect模塊的魔力，我們能查看C源代碼！
|
1
2
3
4
5
6
7
|
>>> import cinspect; print(cinspect.getsource(input))static PyObject *builtin_input(PyObject *self, PyObject *args){PyObject *line;char *str;..... |
很好，現(xiàn)在我們知道我們想要找的函數(shù)叫做'builtin_input'。這時(shí)，我們將要開始瀏覽C代碼了，而不僅僅是Python代碼，我們將要在中端調(diào)試而不是在Python的解釋器里。你不需要一定是一個(gè)C語(yǔ)言專家才能看明白接下來的東西——我大多數(shù)時(shí)候會(huì)以根據(jù)函數(shù)名稱進(jìn)行推測(cè)的方式進(jìn)行。
那么，讓我們來檢索一下Cpython的源代碼，然后我們將發(fā)現(xiàn)'builtin_input'是'builtin_input_impl'的封裝，而'builtin_input_impl'是一個(gè)在bltinmodule.c里面實(shí)現(xiàn)的一個(gè)方法。讓我們嘗試將Python載入到lldb C語(yǔ)言調(diào)試器里面并在那個(gè)方法的開頭設(shè)置一個(gè)斷點(diǎn)：
|
1
2
|
flowerhack$ lldb -- /Users/flowerhack/cpython/python.exeflowerhack$ breakpoint set --file bltinmodule.c --line 2337 |
當(dāng)單步步過源代碼的時(shí)候（這個(gè)過程和你在PDB里面做的事情很像——不停敲擊”n”來運(yùn)行下一行代碼），我們發(fā)現(xiàn)問題第一次出現(xiàn)的那點(diǎn)代碼：
|
1
2
3
4
|
stdout_encoding_str = _PyUnicode_AsString(stdout_encoding);stdout_errors_str = _PyUnicode_AsString(stdout_errors);if (!stdout_encoding_str || !stdout_errors_str)goto _readline_errors; // "throws" an exception |
第三行誤導(dǎo)了我：“如果編碼字符串是空或者錯(cuò)誤字符串是空，那么我們會(huì)得到一個(gè)錯(cuò)誤”。但是，請(qǐng)等一下，難道一個(gè)空的錯(cuò)誤字符串不是意味著沒有錯(cuò)誤被發(fā)現(xiàn)嗎？
因?yàn)檫@個(gè)，我進(jìn)一步查看了_PyUnicode_AsString的定義（另一個(gè)C函數(shù)）：
|
1
|
#define _PyUnicode_AsString PyUnicode_AsUTF8 |
那僅僅是一個(gè)宏：“嘿，當(dāng)我們調(diào)用_PyUnicode_AsString的時(shí)候，去調(diào)用PyUnicode_AsUTF8。”所以我們真正想要找的是PyUnicode_AsUTF8的定義：
|
1
2
3
4
5
|
char*PyUnicode_AsUTF8(PyObject *unicode){return PyUnicode_AsUTF8AndSize(unicode, NULL);} |
……看上去這個(gè)函數(shù)所做的所有的事情是調(diào)用PyUnicode_AsUTF8AndSize，而這正是我們真正想要去閱讀的。
在PyUnicode_AsUTF8AndSize函數(shù)里面有若干個(gè)錯(cuò)誤情況，每一個(gè)都返回NULL。在錯(cuò)誤情況里面返回NULL而不是返回像-1這樣的錯(cuò)誤代碼對(duì)我來說很奇怪。也許這里有其他我不熟悉的約定的考慮？
不管怎么樣，為了顯示出我究竟陷入了哪一個(gè)錯(cuò)誤情況，我進(jìn)行了“打印調(diào)試”——我在每一個(gè)可能的錯(cuò)誤情況后面加入了一個(gè)打印語(yǔ)句，然后運(yùn)行程序——這樣我們就能發(fā)現(xiàn)當(dāng)我們調(diào)用PyUnicode_Check到底錯(cuò)在了哪里。
那么，是否有在Python3里面進(jìn)行了而沒有在Python2里面進(jìn)行過的的檢查呢？嗯，我們能比較兩個(gè)版本的源代碼來找出這個(gè)答案。最后顯示出，Python 2 的源代碼沒有進(jìn)行類似的編碼檢查，然而Python 3做了。所以，如果sys.stdout被錯(cuò)誤編碼的東西代替了，它會(huì)在3里面運(yùn)行失敗，在2里面就不會(huì)。
4.收獲！
看上去僅僅是找出一個(gè)非常普通的固定的BUG后面的原因，就做了非常多的工作。并且也許確實(shí)是這樣。但是！我們?cè)谶@個(gè)過程中學(xué)到了一些很酷的東西。當(dāng)我在驗(yàn)證一些假設(shè)的時(shí)候我發(fā)現(xiàn)了很多Python處理標(biāo)準(zhǔn)輸入輸出的方式。我學(xué)到了更多如何閱讀大型的、很多宏的C工程的經(jīng)驗(yàn)。我學(xué)到了GOTO語(yǔ)句仍然在使用，這讓我感到很吃驚。但是在連貫性上這樣做是有意義的——看上去如果不用GOTO在C里面做一些像是異常處理的事情的時(shí)候?qū)⒆兊暮芊爆崱２⑶覟g覽bltinmodule.c的input 函數(shù)在Python2 和Python3中的不同真的是一件很酷的事情——嚴(yán)格上來說，是檢查。他們重構(gòu)和清理東西看上去很簡(jiǎn)潔。
聲明：設(shè)置cinspect有一點(diǎn)復(fù)雜。在這個(gè)項(xiàng)目的README里面的介紹會(huì)有一些幫助，但是注意“indexing your sources”這一步將會(huì)花很多時(shí)間。
如果你之前習(xí)慣使用gdb，那么你僅僅需要知道的是lldb和它非常相似。如果你兩個(gè)都沒有用過，他們?cè)谡{(diào)試上有一點(diǎn)像PDB。
