我初學(xué)Python時(shí)，聽(tīng)到的關(guān)于Python的第一句話(huà)就是，Python是一門(mén)解釋性語(yǔ)言，我就這樣一直相信下去，直到發(fā)現(xiàn)了*.pyc文件的存在。如果是解釋型語(yǔ)言，那么生成的*.pyc文件是什么呢？c應(yīng)該是compiled的縮寫(xiě)才對(duì)??！

為了防止其他學(xué)習(xí)Python的人也被這句話(huà)誤解，那么我們就在文中來(lái)澄清下這個(gè)問(wèn)題，并且把一些基礎(chǔ)概念給理清。

2. 解釋型語(yǔ)言和編譯型語(yǔ)言

計(jì)算機(jī)是不能夠識(shí)別高級(jí)語(yǔ)言的，所以當(dāng)我們運(yùn)行一個(gè)高級(jí)語(yǔ)言程序的時(shí)候，就需要一個(gè)“翻譯機(jī)”來(lái)從事把高級(jí)語(yǔ)言轉(zhuǎn)變成計(jì)算機(jī)能讀懂的機(jī)器語(yǔ)言的過(guò)程。這個(gè)過(guò)程分成兩類(lèi)，第一種是編譯，第二種是解釋。

編譯型語(yǔ)言在程序執(zhí)行之前，先會(huì)通過(guò)編譯器對(duì)程序執(zhí)行一個(gè)編譯的過(guò)程，把程序轉(zhuǎn)變成機(jī)器語(yǔ)言。運(yùn)行時(shí)就不需要翻譯，而直接執(zhí)行就可以了。最典型的例子就是C語(yǔ)言。

解釋型語(yǔ)言就沒(méi)有這個(gè)編譯的過(guò)程，而是在程序運(yùn)行的時(shí)候，通過(guò)解釋器對(duì)程序逐行作出解釋?zhuān)缓笾苯舆\(yùn)行，最典型的例子是Ruby。

通過(guò)以上的例子，我們可以來(lái)總結(jié)一下解釋型語(yǔ)言和編譯型語(yǔ)言的優(yōu)缺點(diǎn)，因?yàn)榫幾g型語(yǔ)言在程序運(yùn)行之前就已經(jīng)對(duì)程序做出了“翻譯”，所以在運(yùn)行時(shí)就少掉了“翻譯”的過(guò)程，所以效率比較高。但是我們也不能一概而論，一些解釋型語(yǔ)言也可以通過(guò)解釋器的優(yōu)化來(lái)在對(duì)程序做出翻譯時(shí)對(duì)整個(gè)程序做出優(yōu)化，從而在效率上超過(guò)編譯型語(yǔ)言。

此外，隨著Java等基于虛擬機(jī)的語(yǔ)言的興起，我們又不能把語(yǔ)言純粹地分成解釋型和編譯型這兩種。

用Java來(lái)舉例，Java首先是通過(guò)編譯器編譯成字節(jié)碼文件，然后在運(yùn)行時(shí)通過(guò)解釋器給解釋成機(jī)器文件。所以我們說(shuō)Java是一種先編譯后解釋的語(yǔ)言。

再換成C#，C#首先是通過(guò)編譯器將C#文件編譯成IL文件，然后在通過(guò)CLR將IL文件編譯成機(jī)器文件。所以我們說(shuō)C#是一門(mén)純編譯語(yǔ)言，但是C#是一門(mén)需要二次編譯的語(yǔ)言。同理也可等效運(yùn)用到基于.NET平臺(tái)上的其他語(yǔ)言。

3. Python到底是什么

其實(shí)Python和Java/C#一樣，也是一門(mén)基于虛擬機(jī)的語(yǔ)言，我們先來(lái)從表面上簡(jiǎn)單地了解一下Python程序的運(yùn)行過(guò)程吧。

當(dāng)我們?cè)诿钚兄休斎雙ython hello.py時(shí)，其實(shí)是激活了Python的“解釋器”，告訴“解釋器”：你要開(kāi)始工作了。可是在“解釋”之前，其實(shí)執(zhí)行的第一項(xiàng)工作和Java一樣，是編譯。

熟悉Java的同學(xué)可以想一下我們?cè)诿钚兄腥绾螆?zhí)行一個(gè)Java的程序：

javac hello.java

java hello

只是我們?cè)谟肊clipse之類(lèi)的IDE時(shí)，將這兩部給融合成了一部而已。其實(shí)Python也一樣，當(dāng)我們執(zhí)行python hello.py時(shí)，他也一樣執(zhí)行了這么一個(gè)過(guò)程，所以我們應(yīng)該這樣來(lái)描述Python，Python是一門(mén)先編譯后解釋的語(yǔ)言。

4. 簡(jiǎn)述Python的運(yùn)行過(guò)程

在說(shuō)這個(gè)問(wèn)題之前，我們先來(lái)說(shuō)兩個(gè)概念，PyCodeObject和pyc文件。

我們?cè)谟脖P(pán)上看到的pyc自然不必多說(shuō)，而其實(shí)PyCodeObject則是Python編譯器真正編譯成的結(jié)果。我們先簡(jiǎn)單知道就可以了，繼續(xù)向下看。

當(dāng)python程序運(yùn)行時(shí)，編譯的結(jié)果則是保存在位于內(nèi)存中的PyCodeObject中，當(dāng)Python程序運(yùn)行結(jié)束時(shí)，Python解釋器則將PyCodeObject寫(xiě)回到pyc文件中。

當(dāng)python程序第二次運(yùn)行時(shí)，首先程序會(huì)在硬盤(pán)中尋找pyc文件，如果找到，則直接載入，否則就重復(fù)上面的過(guò)程。

所以我們應(yīng)該這樣來(lái)定位PyCodeObject和pyc文件，我們說(shuō)pyc文件其實(shí)是PyCodeObject的一種持久化保存方式。

5. 運(yùn)行一段Python程序

我們來(lái)寫(xiě)一段程序?qū)嶋H運(yùn)行一下：

程序本身毫無(wú)意義。我們繼續(xù)看：

然而我們?cè)诔绦蛑胁](méi)有看到pyc文件，仍然是test.py孤零零地呆在那！

那么我們換一種寫(xiě)法，我們把print_str方法換到另外的一個(gè)python模塊中：

然后運(yùn)行程序：

這個(gè)時(shí)候pyc文件出現(xiàn)了，其實(shí)認(rèn)真思考一下不難得到原因，我們考慮一下實(shí)際的業(yè)務(wù)情況。

6. pyc的目的是重用

回想本文的第二段在解釋編譯型語(yǔ)言和解釋型語(yǔ)言的優(yōu)缺點(diǎn)時(shí)，我說(shuō)編譯型語(yǔ)言的優(yōu)點(diǎn)在于，我們可以在程序運(yùn)行時(shí)不用解釋?zhuān)苯永靡呀?jīng)“翻譯”過(guò)的文件。也就是說(shuō)，我們之所以要把py文件編譯成pyc文件，最大的優(yōu)點(diǎn)在于我們?cè)谶\(yùn)行程序時(shí)，不需要重新對(duì)該模塊進(jìn)行重新的解釋。

所以，我們需要編譯成pyc文件的應(yīng)該是那些可以重用的模塊，這于我們?cè)谠O(shè)計(jì)軟件類(lèi)時(shí)是一樣的目的。所以Python的解釋器認(rèn)為：只有import進(jìn)來(lái)的模塊，才是需要被重用的模塊。

這個(gè)時(shí)候也許有人會(huì)說(shuō)，不對(duì)??！你的這個(gè)問(wèn)題沒(méi)有被解釋通啊，我的test.py不是也需要運(yùn)行么，雖然不是一個(gè)模塊，但是以后我每次運(yùn)行也可以節(jié)省時(shí)間啊！

OK，我們從實(shí)際情況出發(fā)，思考下我們?cè)谑裁磿r(shí)候才可能運(yùn)行python xxx.py文件：

A. 執(zhí)行測(cè)試時(shí)。

B. 開(kāi)啟一個(gè)Web進(jìn)程時(shí)。

C. 執(zhí)行一個(gè)程序腳本。

我們逐個(gè)來(lái)說(shuō)，第一種情況我們就不用多說(shuō)了，這個(gè)時(shí)候哪怕所有的文件都沒(méi)有pyc文件都是無(wú)所謂的。

第二種情況，我們?cè)囅胍粋€(gè)webpy的程序把，我們通常這樣執(zhí)行：

抑或者：

然后這個(gè)程序就類(lèi)似于一個(gè)守護(hù)進(jìn)程一樣一直監(jiān)視著8181/9002端口，而一旦中斷，只可能是程序被殺死，或者其他的意外情況，那么你需要恢復(fù)要做的是把整個(gè)的Web服務(wù)重啟。那么既然一直監(jiān)視著，把PyCodeObject一直放在內(nèi)存中就足夠了，完全沒(méi)必要持久化到硬盤(pán)上。

最后一個(gè)情況，執(zhí)行一個(gè)程序腳本，一個(gè)程序的主入口其實(shí)很類(lèi)似于Web程序中的Controller，也就是說(shuō)，他負(fù)責(zé)的應(yīng)該是Model之間的調(diào)度，而不包含任何的主邏輯在內(nèi)，如我在http://www.cnblogs.com/kym/archive/2010/07/19/1780407.html中所提到，Controller應(yīng)該就是一個(gè)Facade，無(wú)任何的細(xì)節(jié)邏輯，只是把參數(shù)轉(zhuǎn)來(lái)轉(zhuǎn)去而已，那么如果做算法的同學(xué)可以知道，在一段算法腳本中，最容易改變的就是算法的各個(gè)參數(shù)，那么這個(gè)時(shí)候給持久化成pyc文件就未免有些畫(huà)蛇添足了。

所以我們可以這樣理解Python解釋器的意圖，Python解釋器只把我們可能重用到的模塊持久化成pyc文件。

7. pyc的過(guò)期時(shí)間

說(shuō)完了pyc文件，可能有人會(huì)想到，每次Python的解釋器都把模塊給持久化成了pyc文件，那么當(dāng)我的模塊發(fā)生了改變的時(shí)候，是不是都要手動(dòng)地把以前的pyc文件remove掉呢？

當(dāng)然Python的設(shè)計(jì)者是不會(huì)犯這么白癡的錯(cuò)誤的。而這個(gè)過(guò)程其實(shí)就取決于PyCodeObject是如何寫(xiě)入pyc文件中的。

我們來(lái)看一下import過(guò)程的源碼吧：

這段代碼比較長(zhǎng)，我們只來(lái)看我標(biāo)注了的代碼，其實(shí)他在寫(xiě)入pyc文件的時(shí)候，寫(xiě)了一個(gè)Long型變量，變量的內(nèi)容則是文件的最近修改日期，同理，我們?cè)倏聪螺d入pyc的代碼：

不用仔細(xì)看代碼，我們可以很清楚地看到原理，其實(shí)每次在載入之前都會(huì)先檢查一下py文件和pyc文件保存的最后修改日期，如果不一致則重新生成一份pyc文件。

8. 寫(xiě)在最后的

其實(shí)了解Python程序的執(zhí)行過(guò)程對(duì)于大部分程序員，包括Python程序員來(lái)說(shuō)意義都是不大的，那么真正有意義的是，我們可以從Python的解釋器的做法上學(xué)到什么，我認(rèn)為有這樣的幾點(diǎn)：

A. 其實(shí)Python是否保存成pyc文件和我們?cè)谠O(shè)計(jì)緩存系統(tǒng)時(shí)是一樣的，我們可以仔細(xì)想想，到底什么是值得扔在緩存里的，什么是不值得扔在緩存里的。

B. 在跑一個(gè)耗時(shí)的Python腳本時(shí)，我們?nèi)绾文軌蛏晕赫ヒ恍┏绦虻倪\(yùn)行時(shí)間，就是將模塊從主模塊分開(kāi)。（雖然往往這都不是瓶頸）

C. 在設(shè)計(jì)一個(gè)軟件系統(tǒng)時(shí)，重用和非重用的東西是不是也應(yīng)該分開(kāi)來(lái)對(duì)待，這是軟件設(shè)計(jì)原則的重要部分。

D. 在設(shè)計(jì)緩存系統(tǒng)（或者其他系統(tǒng)）時(shí)，我們?nèi)绾蝸?lái)避免程序的過(guò)期，其實(shí)Python的解釋器也為我們提供了一個(gè)特別常見(jiàn)而且有效的解決方案。