作者：折木奉太郎(經(jīng)授權(quán)轉(zhuǎn)載)來源：https://www.zhihu.com/question/30296617/answer/112564303

作為 Python 愛好者，需要了解 .py 腳本的基本運(yùn)行機(jī)制及特性：

在很多工作上，Python 的運(yùn)行流程基本上取決于用戶，因此源碼不需要編譯成二進(jìn)制代碼(否則無法實(shí)現(xiàn)大部分貼近用戶的特性)，而直接從源碼運(yùn)行程序。當(dāng)我們運(yùn)行 Python 文件程序的時(shí)候，Python 解釋器將源碼轉(zhuǎn)換為字節(jié)碼，然后再由解釋器來執(zhí)行這些字節(jié)碼。

因此總的來說，它具有以下三條特性：

源碼距離底層更遠(yuǎn)(根據(jù)官方文檔的解釋。不說，你們也感覺得到)(。?`ω′?)

運(yùn)行時(shí)都需要生成字節(jié)碼，交由虛擬機(jī)執(zhí)行。(你們問我虛擬機(jī)在哪兒？！你們也不看看各自都是用什么軟件執(zhí)行的！沒錯(cuò)，就是解釋器，別和我說是 IDLE 啊。虛擬機(jī)具體實(shí)現(xiàn)了由 switch-case 語句構(gòu)成的框架函數(shù)?PyEval_EvalFrameEx，剛剛說的字節(jié)碼就是這貨執(zhí)行的)

每次執(zhí)行腳本，虛擬機(jī)總要多出加載和鏈接的流程。(所以呢，相比于編譯型語言就有點(diǎn)慢了。這與“有絲分裂間期”一樣，準(zhǔn)備東西也要花時(shí)間啊！)

那么，有人要問了：“不是說，運(yùn)行時(shí)總要生成字節(jié)碼么！那，字節(jié)碼都去哪兒了？” 咳咳，別急！容我先說說，虛擬機(jī)它是怎么執(zhí)行腳本的(咕嚕咕嚕喝杯水...)：

完成模塊的加載和鏈接；

將源代碼翻譯為?PyCodeObject?對(duì)象(這貨就是字節(jié)碼)，并將其寫入內(nèi)存當(dāng)中(方便 CPU 讀取，起到加速程序運(yùn)行的作用)；

從上述內(nèi)存空間中讀取指令并執(zhí)行；

程序結(jié)束后，根據(jù)命令行調(diào)用情況(即運(yùn)行程序的方式)決定是否將 PyCodeObject 寫回硬盤當(dāng)中(也就是直接復(fù)制到 .pyc 或 .pyo 文件中)；

之后若再次執(zhí)行該腳本，則先檢查本地是否有上述字節(jié)碼文件。有則執(zhí)行，否則重復(fù)上述步驟。

你看！在我們點(diǎn)擊(或輸入命令)運(yùn)行腳本，并悠閑地喝咖啡時(shí)，“人家”虛擬機(jī)做了這么多的事情。不過，你有沒有發(fā)現(xiàn) .pyc 或 .pyo 文件是否生成，是取決于我們?nèi)绾芜\(yùn)行程序的(雖然我們不知道要怎么做(? ??_??)? )。

同樣，有人會(huì)吐槽：“哼！為什么不直接生成這些文件，這樣來得不是‘更快、更高、更強(qiáng)’！”

其實(shí)，虛擬機(jī)也是講究效率的。畢竟對(duì)于比較大的項(xiàng)目，要將 PyCodeObject 寫回硬盤也是不可避免地要花些時(shí)間的，而且它又不知道你是不是也就只執(zhí)行一次，之后就對(duì)剛剛跑完的腳本“棄之不顧”了呢。不過，它其實(shí)也有貼心的一面。比如，

• 若你在命令行直接輸入“python path/to/projectDir”(假設(shè)projectDir目錄含有“__main__.py”文件，以及其他將要調(diào)用的模塊)，那么程序運(yùn)行結(jié)束后便自動(dòng)為當(dāng)前目錄下所有的腳本生成字節(jié)碼文件，并保存于本地新文件夾__pycache__當(dāng)中。(這也有可能是 IDE 寫小項(xiàng)目時(shí)自動(dòng)生成 .pyc 文件的原因，不過問題描述略微曖昧。詳情參見上面知乎問題板塊)
• 或者是，在命令行輸入“python path/to/projectDir/__main__.py”，則生成除__main__.py 外腳本的字節(jié)碼文件。不過總的來說，上述這兩種行為都大大縮短了項(xiàng)目運(yùn)行前的準(zhǔn)備時(shí)間(畢竟分工明確的程序，規(guī)模應(yīng)該不會(huì)太小，復(fù)用率也不會(huì)太低。除非吃飽了撐著，搞出這么多事情(Θ皿Θメ))
• 模塊在每次導(dǎo)入前總會(huì)檢查其字節(jié)碼文件的修改時(shí)間是否與自身的一致。若是則直接從該字節(jié)碼文件讀取內(nèi)容，否則源模塊重新導(dǎo)入，并在最后生成同名文件覆蓋當(dāng)前已有的字節(jié)碼，從而完成內(nèi)容的更新(詳見import.py)。這樣，就避免了修改源代碼后與本地字節(jié)碼文件產(chǎn)生沖突(當(dāng)然，設(shè)計(jì)者也不會(huì)這么傻。╮(￣▽￣")╭)。

若想優(yōu)化生成字節(jié)碼，應(yīng)注意這兩點(diǎn)：

• .pyc 文件是由 .py 文件經(jīng)過編譯后生成的字節(jié)碼文件，其加載速度相對(duì)于之前的 .py 文件有所提高，而且還可以實(shí)現(xiàn)源碼隱藏，以及一定程度上的反編譯。比如， Python3.3 編譯生成的 .pyc 文件，Python3.4 就別想著去運(yùn)行啦！→_→
• .pyo文件也是優(yōu)化(注意這兩個(gè)字，便于后續(xù)的理解)編譯后的程序(相比于 .pyc 文件更小)，也可以提高加載速度。但對(duì)于嵌入式系統(tǒng)，它可將所需模塊編譯成 .pyo 文件以減少容量。

但總的來說，作用上是幾乎與原來的 .py 腳本沒有區(qū)別的，也就是“然并卵 ”(當(dāng)然，并非毫無作用。比如，我個(gè)人覺得用處最大的地方就是防止別人偷看我的代碼。_(:з」∠)_畢竟 .py 源文件是直接以源碼的形式呈現(xiàn)給大家的)。╮(╯▽╰)╭ 呃...這么說，好像又有點(diǎn)自相矛盾的趕腳。

在所有的?Python 選項(xiàng)中：

• -O，表示優(yōu)化生成 .pyo 字節(jié)碼(這里又有“優(yōu)化”兩個(gè)字，得注意啦！)
• -OO，表示進(jìn)一步移除 -O 選項(xiàng)生成的字節(jié)碼文件中的文檔字符串(這是在作用效果上解釋的，而不是說從 -O?選項(xiàng)得到的文件去除)
• -m，表示導(dǎo)入并運(yùn)行指定的模塊

對(duì)此，我們可以使用如下格式運(yùn)行 .py 文件來生成 .pyc 文件(以下調(diào)用均假設(shè)?/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字符串，從而避免轉(zhuǎn)義的麻煩。比如，這里不加“r”的話，你就得對(duì)斜杠進(jìn)行轉(zhuǎn)義

py_compile 是 Python 的自帶模塊，這里面就兩個(gè)函數(shù)(看到這個(gè)，我笑了(??? ? ???)噗噗)。其下的?py_compile.compile(file[,?cfile[,?dfile[,?doraise]]]) 可將 .py 文件編譯生成 .pyc 文件(默認(rèn))，對(duì)應(yīng)的參數(shù)解釋如下

file，表示需要生成 .pyc 或 .pyo 文件的源腳本名(字符串)；

cfile，表示需要生成 .pyc 或 .pyo 文件的目標(biāo)腳本名。呃...好像沒有區(qū)別(＞﹏＜) ，也就是源腳本-----[巴拉拉賜予你力量！編譯！]( *￣▽￣)o ─═≡※:☆----->目標(biāo)腳本。當(dāng)然，它默認(rèn)是以 .pyc 為擴(kuò)展名的路徑名的字符串(呼...好長(zhǎng))。此外，當(dāng)且僅當(dāng)所使用的解釋器允許編譯成 .pyo 文件，才能以“.pyo”結(jié)尾。這也就是我上面為什么會(huì)在函數(shù)功能解釋上加上“(默認(rèn))”這兩個(gè)字的原因。

dfile，表示編譯出錯(cuò)時(shí)，將報(bào)錯(cuò)信息中的名字“file”替換為“dfile”。

doraise，設(shè)置是否忽略異常。若為 True，則拋出 PyCompileError 異常；否則直接將錯(cuò)誤信息寫入 sys.stderr(什么！不知道 sys.stderr？！溫馨提示：sys.stderr 是 Python 自帶的標(biāo)準(zhǔn)錯(cuò)誤輸出)

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

另外，生成 .pyo 文件的格式調(diào)用如下：

python -O -m py_compile /path/to/需要生成.pyo的腳本.py

那么，有人要問了：為什么不是像生成.pyc文件那樣采用“python -O /path/to/需要生成.pyo的腳本.py”形式的調(diào)用？

“忘記”說明這一點(diǎn)了，很多博客以及書籍都像我上面那樣解釋“-O”選項(xiàng)的作用，但詳細(xì)來解釋的話是:

-O?選項(xiàng)，將 .pyc 文件優(yōu)化(注意我一直強(qiáng)調(diào)的“優(yōu)化”二字，這里就用到啦！)為 .pyo 文件，而不是將 .py 文件優(yōu)化編譯為 .pyo 文件。(其直接的結(jié)果是優(yōu)化編譯后的文件略微小于 .pyc 文件，也就是“減肥”了。現(xiàn)在，大家知道 .pyo 文件為什么小的原因了吧！)

注意：?以上無論是生成 .pyc 還是 .pyo 文件，都將在當(dāng)前腳本的目錄下生成一個(gè)含有字節(jié)碼的文件夾 __pycache__?。

可能還有人會(huì)問，.pyd 文件又是什么鬼(＞﹏＜)？！(問題真多，精分ing...) 別在意，那只是 Python 的動(dòng)態(tài)鏈接庫。如果要深究，還得扯上 C++ 的知識(shí)(長(zhǎng)篇大論的，會(huì)被噴的啊)。

再啰嗦一句：生成字節(jié)碼的方法多了去了，不止以上這幾種。比如，你們不妨試試將上面命令行調(diào)用中的“py_compile”改成“compileall”，而代碼行中的“py_compile.compile”改成“compileall.compile_file”或“compileall.compile_dir”，又或者直接使用帶有編譯功能的 IDE 生成字節(jié)碼。

再再啰嗦一句：知道 Python 運(yùn)行機(jī)制，并不是我們一般人所必須的(吃瓜群眾：“滾！我剛好不容易看完了，你才說？！”)。但是，了解其加速程序運(yùn)行以及優(yōu)化代碼的設(shè)計(jì)思想，對(duì)于我們?cè)谌蘸髽?gòu)造緩存系統(tǒng)、如何減少不必要的運(yùn)行時(shí)間，以及同步更新工作內(nèi)容等問題上起到很大的借鑒作用。

若想要了解更多的內(nèi)容，可以去翻翻官方文檔和其它博客：

https://docs.python.org/3.5/using/cmdline.html?highlight=#command-line-and-environmenthttps://docs.python.org/3.5/library/py_compile.html?highlight=.pyc#module-py_compilehttps://docs.python.org/3.5/c-api/code.html?highlight=pycodeobject#code-objectshttp://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.htmlhttp://www.tuicool.com/articles/Q7Rj6rrhttp://developer.51cto.com/art/201002/184914.html

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的android 在什么情况下会主动gc_Python 什么情况下会生成 pyc 文件？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。