python 程序執行過程

轉自 : http://www.cnblogs.com/kym/archive/2012/05/14/2498728.html

   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程序


我們來寫一段程序實際運行一下:

201205140014.jpg

程序本身毫無意義。我們繼續看:


201205140015.jpg

然而我們在程序中並沒有看到pyc文件,仍然是test.py孤零零地呆在那!

那麼我們換一種寫法,我們把print_str方法換到另外的一個python模塊中:


201205140015.jpg


201205140016.jpg

然後運行程序:


201205140016.jpg

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


6. pyc的目的是重用


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

所以,我們需要編譯成pyc文件的應該是那些可以重用的模塊,這於我們在設計軟件類時是一樣的目的。所以Python的解釋器認爲:只有import進來的模塊,纔是需要被重用的模塊。

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

OK,我們從實際情況出發,思考下我們在什麼時候纔可能運行python xxx.py文件:

A. 執行測試時。

B. 開啓一個Web進程時。

C. 執行一個程序腳本。

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

第二種情況,我們試想一個webpy的程序把,我們通常這樣執行:


201205140016.jpg

抑或者:


201205140017.jpg

然後這個程序就類似於一個守護進程一樣一直監視着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過程的源碼吧:


201205140024.jpg

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


201205140025.jpg


201205140026.jpg

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


8. 寫在最後的


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

A. 其實Python是否保存成pyc文件和我們在設計緩存系統時是一樣的,我們可以仔細想想,到底什麼是值得扔在緩存裏的,什麼是不值得扔在緩存裏的。

B. 在跑一個耗時的Python腳本時,我們如何能夠稍微壓榨一些程序的運行時間,就是將模塊從主模塊分開。(雖然往往這都不是瓶頸)

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

D. 在設計緩存系統(或者其他系統)時,我們如何來避免程序的過期,其實Python的解釋器也爲我們提供了一個特別常見而且有效的解決方案。


發佈了72 篇原創文章 · 獲贊 13 · 訪問量 16萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章