Python是一門解釋型語言？
我初學Python時，聽到的關於Python的第一句話就是Python是一門解釋型語言，我就這樣一直相信下去，直到發現.pyc文件的存在，如果真是解釋型語言，那么生成的.pyc文件的是什么呢？c應該是compiled的縮寫才對啊！
為了防止其他學習Python的人也被這句話誤解，那么我們就在文中來澄清一下這個問題，並且把一些基礎概念給理一理。
解釋型語言和編譯型語言
計算機是不能夠識別高級語言的，所以當我們運行一個高級語言程序的時候，就需要一個“翻譯機”來從事把高級語言轉變成計算機能讀懂的機器語言的過程。這個過程分成兩類，第一種是編譯，第二種是解釋。
編譯型語言在程序執行之前，先會通過編譯器對程序執行一個編譯的過程，把程序轉變成集齊語言。運行時就不需要翻譯，而直接執行就可以了，最典型的例子就是C語言。
解釋型語言就沒有這個編譯過程，而是在程序運行的時候，通過解釋器對程序逐行做出解釋，然后直接運行，最典型的例子是Ruby。
通過以上的例子，我們可以來總結一下解釋型語言和編譯型語言的優缺點，因為編譯型語言在程序運行之前就已經對程序做出了“翻譯”，所以在運行時就少掉了“翻譯”的過程，所以效率比較高。但是我們也不能一概而論，一些解釋型語言也可以通過解釋器的優化來在對程序做出翻譯時對整個程序做出優化，從而在效率上超過編譯型語言。
此外，隨着Java等基於虛擬機的語言的興起，我們又不能把語言純粹的分成解釋型和編譯型這兩種。
用Java來舉例，Java首先是通過編譯器編譯成字節碼文件，然后在運行時通過解釋器給解釋成機器文件。所以我們說Java是一種先編譯后解釋的語言。
再換成C#，C#首相是通過編譯器將C#文件編譯成IL文件，然后在通過CLR將IL文件編譯成機器文件。所以我們說C#是一門純編譯語言，但是C#是一門需要二次編譯的語言。同理也可以等效運用到基於.NET平台上的 其他語言。
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是一門先編譯后解釋的語言。
簡述Python中程序的運行過程
在說這個問題之前，我們先來說兩個概念，PyCodeObject和pyc文件。
我們在硬盤上看到的pyc自然不必多說，而其實PyCodeObject則是Python編譯器真正編譯成的結果。我們先簡單知道就可以了，繼續向下看。
當Python程序運行時，編譯的結果則是保存在位於內存中的PyCodeObject中，當Python程序運行結束時，Python解釋器則將PyCodeObject寫回到pyc文件中。
當Python程序第二次運行時，首先程序會在硬盤中尋找對應的pyc文件，如果找到，則直接載入，否則就重復上面的過程。
所以我們應該這樣來定位PyCodeObject和pyc文件：pyc文件其實是PyCodeObject的一種持久化保存方式。
我們先來簡單看兩個例子
寫一段簡單的程序運行一下：
運行結果：
我們發現在運行完test.py這個程序后，當前路徑下並沒有生成相應的pyc文件。那是為什么呢？
我們再來做一個小測試，將test.py當做模塊導入到test888.py文件中，然后在這個程序中運行print_hello這個程序：
然后運行程序：
我們可以發現運行完test888.py文件后在當前路徑下出現了一個名叫__pycache__的文件夾，里面包含了一個pyc文件，下面我們來分析一下這個過程到底發生了什么。
pyc文件的目的
回想上面我們在分析編譯型語言和解釋型語言的優缺點時，編譯型語言的優點在於，我們可以在程序運行時不用解釋，而直接利用已經翻譯過的文件。也就是說，我們之所以要把py文件編譯成pyc文件，最大的優點在於我們在運行程序時，不需要重新對該模塊進行再次解釋。
所以，需要編譯成pyc文件的應該是那些可以重用的模塊，這於我們在設計類時是一樣的目的。所以Python的解釋器認為：只有import進來的模塊，才是需要被重用的模塊。
這個時候也許有人會有疑問，我的test.py不是也需要運行嗎，雖然不是一個模塊，但是以后我每次運行也可以節省時間啊！
OK，我們從實際情況出發，思考一下我們在什么時候才可能運行python xxx.py文件：
1. 執行測試時；
2. 開啟一個Web進程時；
3. 執行一個腳本時。
我們來逐條分析，第一種情況就不多說了，這個時候哪怕所有的文件都沒有pyc文件都是無所謂的。
第二種情況，試想一個web.py的程序，通常是這樣執行的：
然后這個程序就類似於一個守護進程一樣一直監視着8000端口，而一旦中斷，只可能是程序被殺死或者其他的意外情況，那么你要做的是把整個Web服務重啟，那么既然一直監視着，把PyCodeObject一直放在內存中就足夠了，完全沒有必要持久化到硬盤上。
再來看看最后一個情況，執行一個程序腳本，一個程序的主入口其實很類似於Web程序中的Controller，也就是說，他負責的應該是Model之間的調度，而不包含任何的主邏輯在內，只是負責把參數轉來轉去而已，那么如果做算法的同學可以知道，在一段算法腳本中，最容易改變的就是算法的各個參數，那么這個時候將它持久化成pyc文件就未免有些畫蛇添足了。
所以我們可以這樣理解Python解釋器的意圖，Python解釋器只是把我們可能重用到的模塊持久化成pyc文件。
pyc文件的過期時間
說完了pyc文件，可能有人會想到，每次Python解釋器都把模塊給持久化成pyc文件，那么當我的模塊發生改變的時候，是不是都要手動的把之前的pyc文件remove掉呢？
當然Python的設計者是不會犯這樣的錯誤的，這個過程其實取決於PyCodeObject是如何寫入pyc文件中的。
我們仔細看一下Import模塊的源碼其實不難發現，它在寫入pyc文件的時候，寫了一個Long型變量，變量的內容則是文件的最近修改日期，同理，在pyc文件中，每次在載入之前都會檢查一下py文件和pyc文件保存的最后修改日期，如果不一致則重新生成新的pyc文件。
總結
其實了解Python程序的執行過程對於大部分程序員來說意義都是不大的，那么真正有意義的是，我們可以從Python解釋器的做法上學到一些處理問題的方式和方法：
在Python中判斷是否生成pyc文件和我們在設計緩存系統時是一樣的，我們可以仔細想想，到底什么是值得扔在緩存里面的，什么是不值得的。
在運行一個耗時的Python腳本時，我們如何能夠做到稍微壓榨一些程序的運行時間呢？就是將模塊從主模塊分開。（雖然往往這都不是瓶頸）
在設計一個軟件系統時，重用和非重用的東西是不是也可以分開來對待，這是軟件設計原則的重要部分。
在設計緩存系統（或者其他系統）時，我們如何來避免程序的過期，其實Python解釋器為我們提供了一個特別常見而且有效的解決方案。