作為Python愛好者，需要了解.py指令碼的基本執行機制及特性：

在很多工作上Python的執行流程基本上取決於使用者，因此原始碼不需要編譯成二進位制程式碼（否則無法實現大部分貼近使用者的特性），而直接從原始碼執行程式。當我們執行python檔案程式的時候，Python直譯器將原始碼轉換為位元組碼，然後再由直譯器來執行這些位元組碼。因此總的來說，它具有以下三條特性

• 原始碼距離底層更遠（根據官方文件的解釋。不說，你們也感覺得到）(。・`ω´・)
• 執行時都需要生成位元組碼，交由虛擬機器執行。（你們問我虛擬機器在哪兒？！你們也不看看各自都是用什麼軟體執行的！沒錯，就是直譯器，別和我說是IDLE啊。虛擬機器具體實現了由switch-case語句構成的框架函式PyEval_EvalFrameEx，剛剛說的位元組碼就是這貨執行的）
• 每次執行指令碼，虛擬機器總要多出載入和連結的流程。（所以呢，相比於編譯型語言就有點慢了。這與“有絲分裂間期”一樣，準備東西也要花時間啊！）

那麼，有人要問了：“不是說，執行時總要生成位元組碼麼！那，位元組碼都去哪兒了？” 咳咳，別急！容我先說說，虛擬機器它是怎麼執行指令碼的（咕嚕咕嚕喝杯水…）：

• 完成模組的載入和連結；
• 將原始碼翻譯為PyCodeObject物件（這貨就是位元組碼），並將其寫入記憶體當中（方便CPU讀取，起到加速程式執行的作用）；
• 從上述記憶體空間中讀取指令並執行；
• 程式結束後，根據命令列呼叫情況（即執行程式的方式）決定是否將PyCodeObject寫回硬碟當中（也就是直接複製到.pyc或.pyo檔案中）；
• 之後若再次執行該指令碼，則先檢查本地是否有上述位元組碼檔案。有則執行，否則重複上述步驟。

你看！在我們點選（或輸入命令）執行指令碼，並悠閒地喝咖啡時，“人家”虛擬機器做了這麼多的事情。不過，你有沒有發現.pyc或.pyo檔案是否生成，是取決於我們如何執行程式的（雖然我們不知道要怎麼做（ง •̀_•́）ง ）。

同樣，有人會吐槽：“哼！為什麼不直接生成這些檔案，這樣來得不是‘更快、更高、更強’！”
其實，虛擬機器也是講究效率的。畢竟對於比較大的專案，要將PyCodeObject寫回硬碟也是不可避免地要花些時間的，而且它又不知道你是不是也就只執行一次，之後就對剛剛跑完的指令碼“棄之不顧”了呢。不過，它其實也有貼心的一面。比如，

• 若你在命令列直接輸入“python path/to/projectDir”（假設projectDir目錄含有“main.py”檔案，以及其他將要呼叫的模組），那麼程式執行結束後便自動為當前目錄下所有的指令碼生成位元組碼檔案，並保存於本地新資料夾pycache當中。（這也有可能是IDE寫小專案時自動生成.pyc檔案的原因，不過問題描述略微曖昧。詳情參見上面知乎問題板塊）

或者是，在命令列輸入“python path/to/projectDir/main.py”，則生成除main.py外指令碼的位元組碼檔案。不過總的來說，上述這兩種行為都大大縮短了專案執行前的準備時間（畢竟分工明確的程式，規模應該不會太小，複用率也不會太低。除非吃飽了撐著，搞出這麼多事情(Θ皿Θメ)）

• 模組在每次匯入前總會檢查其位元組碼檔案的修改時間是否與自身的一致。若是則直接從該位元組碼檔案讀取內容，否則源模組重新匯入，並在最後生成同名檔案覆蓋當前已有的位元組碼，從而完成內容的更新（詳見import.py）。這樣，就避免了修改原始碼後與本地位元組碼檔案產生衝突（當然，設計者也不會這麼傻。╮(￣▽￣”)╭）。

若想優化生成位元組碼，應注意這兩點：

• .pyc檔案是由.py檔案經過編譯後生成的位元組碼檔案，其載入速度相對於之前的.py檔案有所提高，而且還可以實現原始碼隱藏，以及一定程度上的反編譯。比如，Python3.3編譯生成的.pyc檔案，Python3.4就別想著去執行啦！→_→.
• pyo檔案也是優化（注意這兩個字，便於後續的理解）編譯後的程式（相比於.pyc檔案更小），也可以提高載入速度。但對於嵌入式系統，它可將所需模組編譯成.pyo檔案以減少容量。

但總的來說，作用上是幾乎與原來的.py指令碼沒有區別的，也就是“然並卵 ”（當然，並非毫無作用。比如，我個人覺得用處最大的地方就是防止別人偷看我的程式碼。(:з」∠)畢竟.py原始檔是直接以原始碼的形式呈現給大家的）。╮(╯▽╰)╭ 呃…這麼說，好像又有點自相矛盾的趕腳。

在所有的Python選項中：

• -O，表示優化生成.pyo位元組碼（這裡又有“優化”兩個字，得注意啦！）
• -OO，表示進一步移除-O選項生成的位元組碼檔案中的文件字串（這是在作用效果上解釋的，而不是說從-O選項得到的檔案去除）
• -m，表示匯入並執行指定的模組

對此，我們可以使用如下格式執行.py檔案來生成.pyc檔案（以下呼叫均假設/path/to目錄含有.py指令碼）：

python -m py_compile /path/to/需要生成.pyc的指令碼.py #若批量處理.py檔案
                                                  #則替換為/path/to/{需要生成.pyc的指令碼1,指令碼2,...}.py
                                                  #或者/path/to/

其效果等效於如下程式碼：

import py_compile
py_compile.compile(r'/path/to/需要生成.pyc的指令碼.py') #同樣也可以是包含.py檔案的目錄路徑
                                                    #此處儘可能使用raw字串，從而避免轉義的麻煩。比如，這裡不加“r”的話，你就得對斜槓進行轉義

py_compile是Python的自帶模組，這裡面就兩個函式（看到這個，我笑了(๑•́ ₃ •̀๑)噗噗）。其下的py_compile.compile(file[, cfile[, dfile[, doraise]]])可將.py檔案編譯生成.pyc檔案（預設），對應的引數解釋如下

• file，表示需要生成.pyc或.pyo檔案的源指令碼名（字串）；
• cfile，表示需要生成.pyc或.pyo檔案的目標指令碼名。呃…好像沒有區別（＞﹏＜） ，也就是源指令碼—–[巴拉拉賜予你力量！編譯！]（ *￣▽￣）o ─═≡※:☆—–>目標指令碼。當然，它預設是以.pyc為副檔名的路徑名的字串（呼…好長）。此外，當且僅當所使用的直譯器允許編譯成.pyo檔案，才能以“.pyo”結尾。這也就是我上面為什麼會在函式功能解釋上加上“（預設）”這兩個字的原因。
• dfile，表示編譯出錯時，將報錯資訊中的名字“file”替換為“dfile”。
• doraise，設定是否忽略異常。若為True，則丟擲PyCompileError異常；否則直接將錯誤資訊寫入sys.stderr（什麼！不知道sys.stderr？！溫馨提示：sys.stderr是Python自帶的標準錯誤輸出）

（╯’ - ‘)╯︵ ┻━┻ （掀桌子） ┬─┬ ノ( ’ - ‘ノ) （擺好擺好） (╯°Д°)╯︵ ┻━┻(再TA喵掀一次）

另外，生成.pyo檔案的格式呼叫如下：

python -O -m py_compile /path/to/需要生成.pyo的指令碼.py

那麼，有人要問了：為什麼不是像生成.pyc檔案那樣採用“python -O /path/to/需要生成.pyo的指令碼.py”形式的呼叫？
“忘記”說明這一點了，很多部落格以及書籍都像我上面那樣解釋“-O”選項的作用，但詳細來解釋的話是

-O選項，將.pyc檔案優化（注意我一直強調的“優化”二字，這裡就用到啦！）為.pyo檔案，而不是將.py檔案優化編譯為.pyo檔案。（其直接的結果是優化編譯後的檔案略微小於.pyc檔案，也就是“減肥”了。現在，大家知道.pyo檔案為什麼小的原因了吧！）

注意：
以上無論是生成.pyc還是.pyo檔案，都將在當前指令碼的目錄下生成一個含有位元組碼的資料夾pycache。

可能還有人會問，.pyd檔案又是什麼鬼（＞﹏＜）？！（問題真多，精分ing…） 別在意，那只是Python的動態連結庫。如果要深究，還得扯上C++的知識（長篇大論的，會被噴的啊）。

再囉嗦一句：生成位元組碼的方法多了去了，不止以上這幾種。比如，你們不妨試試將上面命令列呼叫中的“py_compile”改成“compileall”，而程式碼行中的“py_compile.compile”改成“compileall.compile_file”或“compileall.compile_dir”，又或者直接使用帶有編譯功能的IDE生成位元組碼。

再再囉嗦一句：知道Python執行機制，並不是我們一般人所必須的（吃瓜群眾：“滾！我剛好不容易看完了，你才說？！”）。但是，瞭解其加速程式執行以及優化程式碼的設計思想，對於我們在日後構造快取系統、如何減少不必要的執行時間，以及同步更新工作內容等問題上起到很大的借鑑作用。

若想要了解更多的內容，可以去翻翻官方文件和其他部落格：

貼心提示：以上顏文字以及搞怪語氣，主要是為了能夠提高各位的閱讀興趣。如有不當的地方，懇請各位能夠悉心指出。