說說Python程式的執行過程

1. Python是一門解釋型語言？

我初學Python時，聽到的關於Python的第一句話就是，Python是一門解釋性語言，我就這樣一直相信下去，直到發現了*.pyc檔案的存在。如果是解釋型語言，那麼產生的*.pyc檔案是什麼呢？c應該是compiled的縮寫才對啊！

為了防止其他學習Python的人也被這句話誤解，那麼我們就在文中來澄清下這個問題，並且把一些基礎概念給理清。

2. 解釋型語言和編譯型語言

電腦是不能夠識別進階語言的，所以當我們運行一個進階語言程式的時候，就需要一個“翻譯機”來從事把進階語言轉變成電腦能讀懂的機器語言的過程。這個過程分成兩類，第一種是編譯，第二種是解釋。

編譯型語言在程式執行之前，先會通過編譯器對程式執行一個編譯的過程，把程式轉變成機器語言。運行時就不需要翻譯，而直接執行就可以了。最典型的例子就是C語言。

解釋型語言就沒有這個編譯的過程，而是在程式啟動並執行時候，通過解譯器對程式逐行作出解釋，然後直接運行，最典型的例子是Ruby。

通過以上的例子，我們可以來總結一下解釋型語言和編譯型語言的優缺點，因為編譯型語言在程式運行之前就已經對程式做出了“翻譯”，所以在運行時就少掉了“翻譯”的過程，所以效率比較高。但是我們也不能一概而論，一些解釋型語言也可以通過解譯器的最佳化來在對程式做出翻譯時對整個程式做出最佳化，從而在效率上超過編譯型語言。

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

用Java來舉例，Java首先是通過編譯器編譯成位元組碼檔案，然後在運行時通過解譯器給解釋成機器檔案。所以我們說Java是一種先編譯後解釋的語言。

再換成C#，C#首先是通過編譯器將C#檔案編譯成IL檔案，然後在通過CLR將IL檔案編譯成機器檔案。所以我們說C#是一門純編譯語言，但是C#是一門需要二次編譯的語言。同理也可等效運用到基於.NET平台上的其他語言。

3. Python到底是什麼

其實Python和Java/C#一樣，也是一門基於虛擬機器的語言，我們先來從表面上簡單地瞭解一下Python程式的運行過程吧。

當我們在命令列中輸入python hello.py時，其實是啟用了Python的“解譯器”，告訴“解譯器”：你要開始工作了。可是在“解釋”之前，其實執行的第一項工作和Java一樣，是編譯。

熟悉Java的同學可以想一下我們在命令列中如何執行一個Java的程式：

javac hello.java

java hello

只是我們在用Eclipse之類的IDE時，將這兩部給融合成了一部而已。其實Python也一樣，當我們執行python hello.py時，他也一樣執行了這麼一個過程，所以我們應該這樣來描述Python，Python是一門先編譯後解釋的語言。

4. 簡述Python的運行過程

在說這個問題之前，我們先來說兩個概念，PyCodeObject和pyc檔案。

我們在硬碟上看到的pyc自然不必多說，而其實PyCodeObject則是Python編譯器真正編譯成的結果。我們先簡單知道就可以了，繼續向下看。

當python程式運行時，編譯的結果則是儲存在位於記憶體中的PyCodeObject中，當Python程式運行結束時，Python解譯器則將PyCodeObject寫回到pyc檔案中。

當python程式第二次運行時，首先程式會在硬碟中尋找pyc檔案，如果找到，則直接載入，否則就重複上面的過程。

所以我們應該這樣來定位PyCodeObject和pyc檔案，我們說pyc檔案其實是PyCodeObject的一種持久化儲存方式。

5. 運行一段Python程式

我們來寫一段程式實際運行一下：

程式本身毫無意義。我們繼續看：

然而我們在程式中並沒有看到pyc檔案，仍然是test.py孤零零地呆在那！

那麼我們換一種寫法，我們把print_str方法換到另外的一個python模組中：

然後運行程式：

這個時候pyc檔案出現了，其實認真思考一下不難得到原因，我們考慮一下實際的業務情況。

6. pyc的目的是重用

回想本文的第二段在解釋編譯型語言和解釋型語言的優缺點時，我說編譯型語言的優點在於，我們可以在程式運行時不用解釋，而直接利用已經“翻譯”過的檔案。也就是說，我們之所以要把py檔案編譯成pyc檔案，最大的優點在於我們在運行程式時，不需要重新對該模組進行重新的解釋。

所以，我們需要編譯成pyc檔案的應該是那些可以重用的模組，這於我們在設計軟體類時是一樣的目的。所以Python的解譯器認為：只有import進來的模組，才是需要被重用的模組。

這個時候也許有人會說，不對啊！你的這個問題沒有被解釋通啊，我的test.py不是也需要運行麼，雖然不是一個模組，但是以後我每次運行也可以節省時間啊！

OK，我們從實際情況出發，思考下我們在什麼時候才可能運行python xxx.py檔案：

A. 執行測試時。

B. 開啟一個Web進程時。

C. 執行一個程式指令碼。

我們逐個來說，第一種情況我們就不用多說了，這個時候哪怕所有的檔案都沒有pyc檔案都是無所謂的。

第二種情況，我們試想一個webpy的程式把，我們通常這樣執行：

抑或者：

然後這個程式就類似於一個守護進程一樣一直監視著8181/9002連接埠，而一旦中斷，只可能是程式被殺死，或者其他的意外情況，那麼你需要恢複要做的是把整個的Web服務重啟。那麼既然一直監視著，把PyCodeObject一直放在記憶體中就足夠了，完全沒必要持久化到硬碟上。

最後一個情況，執行一個程式指令碼，一個程式的主入口其實很類似於Web程式中的Controller，也就是說，他負責的應該是Model之間的調度，而不包含任何的主邏輯在內，如我在http://www.cnblogs.com/kym/archive/2010/07/19/1780407.html中所提到，Controller應該就是一個Facade，無任何的細節邏輯，只是把參數轉來轉去而已，那麼如果做演算法的同學可以知道，在一段演算法指令碼中，最容易改變的就是演算法的各個參數，那麼這個時候給持久化成pyc檔案就未免有些畫蛇添足了。

所以我們可以這樣理解Python解譯器的意圖，Python解譯器只把我們可能重用到的模組持久化成pyc檔案。

7. pyc的到期時間

說完了pyc檔案，可能有人會想到，每次Python的解譯器都把模組給持久化成了pyc檔案，那麼當我的模組發生了改變的時候，是不是都要手動地把以前的pyc檔案remove掉呢？

當然Python的設計者是不會犯這麼白癡的錯誤的。而這個過程其實就取決於PyCodeObject是如何寫入pyc檔案中的。

我們來看一下import過程的源碼吧：

這段代碼比較長，我們只來看我標註了的代碼，其實他在寫入pyc檔案的時候，寫了一個Long型變數，變數的內容則是檔案的最近修改日期，同理，我們再看下載入pyc的代碼：

不用仔細看代碼，我們可以很清楚地看到原理，其實每次在載入之前都會先檢查一下py檔案和pyc檔案儲存的最後修改日期，如果不一致則重建一份pyc檔案。

8. 寫在最後的

其實瞭解Python程式的執行過程對於大部分程式員，包括Python程式員來說意義都是不大的，那麼真正有意義的是，我們可以從Python的解譯器的做法上學到什麼，我認為有這樣的幾點：

A. 其實Python是否儲存成pyc檔案和我們在設計緩衝系統時是一樣的，我們可以仔細想想，到底什麼是值得扔在緩衝裡的，什麼是不值得扔在緩衝裡的。

B. 在跑一個耗時的Python指令碼時，我們如何能夠稍微壓榨一些程式的已耗用時間，就是將模組從主模組分開。（雖然往往這都不是瓶頸）

C. 在設計一個軟體系統時，重用和非重用的東西是不是也應該分開來對待，這是軟體設計原則的重要部分。

D. 在設計緩衝系統（或者其他系統）時，我們如何來避免程式的到期，其實Python的解譯器也為我們提供了一個特別常見而且有效解決方案。