來源：https://www.zhihu.com/question/30296617/answer/112564303
作為 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 腳本）：
<code>
python -m py_compile /path/to/需要生成.pyc的腳本.py #若批量處理.py文件
#則替換為/path/to/{需要生成.pyc的腳本1,腳本2,...}.py
#或者/path/to//<code>
其效果等效於如下代碼：
<code>
import py_compile
py_compile.compile(r'/path/to/需要生成.pyc的腳本.py') #同樣也可以是包含.py文件的目錄路徑
#此處儘可能使用raw字符串，從而避免轉義的麻煩。比如，這裡不加“r”的話，你就得對斜槓進行轉義/<code>
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 文件的格式調用如下：
<code>
python -O -m py_compile /path/to/需要生成.pyo的腳本.py/<code>
那麼，有人要問了：為什麼不是像生成.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 運行機制，並不是我們一般人所必須的（吃瓜群眾：“滾！我剛好不容易看完了，你才說？！”）。但是，瞭解其加速程序運行以及優化代碼的設計思想，對於我們在日後構造緩存系統、如何減少不必要的運行時間，以及同步更新工作內容等問題上起到很大的借鑑作用。
若想要了解更多的內容，可以去翻翻官方文檔和其它博客：
https://docs.python.org/3.5/using/cmdline.html?highlight=#command-line-and-environment
https://docs.python.org/3.5/library/py_compile.html?highlight=.pyc#module-py_compile
https://docs.python.org/3.5/c-api/code.html?highlight=pycodeobject#code-objects
http://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.html
http://www.tuicool.com/articles/Q7Rj6rr
http://developer.51cto.com/art/201002/184914.htm
閱讀更多 Python貓 的文章
