python不是用C實現的，而是利用了CPython直譯器使python的執行效率可以接近C程式。至於為什麼不直接生成exe，因為沒有必要啊，exe是C程式編譯之後執行的，意味著每一次執行python，後端的C直譯器都需要將目前的python程式碼翻譯成C程式碼，再執行編譯、檢查連結等等一系列操作，之後把所有的庫靜態或者動態打包好形成一個exe來供使用者執行，這個效率未免太低了吧？而且在呼叫庫的時候要如何選擇連結方式？使用靜態連結的話編譯出來的檔案會很大，動態連結又不能保證每一個使用者都可以執行，不能保證庫檔案已經正確安裝，導致跨平臺性不好。

Python執行原理是執行在C編寫的Python虛擬機器上，透過opcode來決定python需要執行的指令，並且可以透過建立執行緒的方式來提高python的執行效率。只要直譯器生成了對應的機器碼，虛擬機器執行緒可以立刻進入執行狀態，效率比編譯高多了，無論是暫停、修改還是重新執行速度都非常快。

C語言其實是一種比較“古老”而且“底層”的語言。其執行效率，僅次於組合語言。

說其古老，是因為C語言的出現很早。

雖然Fortran、Cobol語言出現比C語言更早，但是現代主流作業系統（Windows、Mac Os、linux、iOS、Android、Unix）全部脫胎於C語言。

說它底層，是因為C語言設計之初就是為了同時編寫組合語言。理論上可以全部用匯編寫。而組合語言是執行效率最高的語言。

所以Python用C語言寫一點也不奇怪。這和它能不能生成Exe一點關係都沒有。

Exe檔案是Windows平臺的私有格式。最簡單的Exe是Com可執行檔案。Exe檔案實際上是一個載入程式+一個解釋程式組成的。

Python語言生成的程式碼，只需要配以載入程式和解釋程式，就可以作為Exe檔案執行。

所以，Python生成Exe檔案一點難度都沒有。只是它願不願意提供的問題。

你可以理解成python就是個exe（cpython真是），你要執行這個exe需要寫寫python格式的程式碼進去讓它執行。

所以python叫指令碼執行（動態型別，需要直譯器，cpython只是其中一種，還有java實現等）。

任何語言在理論上都是可以生成可執行檔案的（exe檔案是windows環境下的一種可執行檔案），但是實際上由於python在設計之時將其設計成為一個指令碼語言，其並沒有相關編譯成可執行檔案的編譯器，但有一種方法是進行打包，就是引入PyWin32包後，使用下面的pyinstaller 命令進行打包生成一個exe。

命令格式如下，為方便顯示做了分行處理：

pyinstaller [主檔案] -p [其他檔案1] -p [其他檔案2]

--hidden-import [自建模組1]

--hidden-import [自建模組2]

下來，我們說明一個概念。什麼是可執行檔案？

PE（Portable Executable）格式，是微軟Win32環境可移植可執行檔案(如exe、dll、vxd、sys和vdm等)的標準檔案格式。PE格式檔案分為PE32和PE64，PE32是win32也就是windows 32位作業系統原生態的可執行檔案，其藉助於wow64子系統，可以運行於64位windows環境下。PE64是windows64位作業系統下的可執行檔案格式。

在宇宙第一IDE VS環境下，可透過工程配置管理器來選擇生成的exe是32位的還是64位的。

PE檔案格式如下圖所示：

我們透過PE檔案的格式圖可以看出，PE檔案更像一個數據的組織架構圖，其按照嚴格的資料組裝方式進行資料分配管理索引（當然這些是由編譯器和連結器最終生成的），而且其程式碼最終編譯成與CPU相關的機器碼，其依賴的庫是系統相應的dll動態庫或其它資源。

PYTHON語言一個指令碼語言，其執行是透過python直譯器負責執行的。其程式碼在執行過程中透過python直譯器將python語言進行翻譯成機器碼，然後再交由CPU去執行。

當然PYTHON也是可以編譯的，不過這裡的編譯只是將指令碼程式碼翻譯成python對應的位元組流，其並不是真正的機器碼。

所以我們可以進行這樣的一個對比說明：

C語言經過編譯連結，最終生成了與機器機關的彙編執令，其編譯後文件資料的組織方式為PE格式，其在執行時由程序載入器負責其依賴的系統庫的載入和初始化。而python無論是否編譯，最終是將其python的程式碼或者位元組流交由python直譯器去解釋執行，其與系統無關，但python直譯器是與系統有關，而且python程式碼在使用過程中需要的庫資源由python虛擬機器負責載入初始化，並給python提供介面。

而現在python打包生成的exe只是對python指令碼、python的直譯器、python指令碼需要引入的包和 python虛擬機器進行一個打包，並非一個真正意義上的exe檔案，其在執行過程中本質是由python直譯器負責解釋python程式碼並在其虛擬中執行的。

eval(),exec(),等指令無法編譯。解釋性語言都存在這類問題，是特有的優點，也是阻礙編譯成二進位制語言的缺點。

這個事跟是用什麼開發工具不搭界，跟語言的基本屬性搭界。Phyton是解釋型語言先天註定它不能生成EXE檔案。

exe是有檔案格式的二進位制程式碼。是微軟特有的格式。

python是解釋語言，是需要執行環境的，編譯成exe就不能跨平臺運行了。

Python就不是幹exe這活的，大街上有那卡車當公交車使的嘛！雖然都叫車，都有發動機和四個軲轆。卡車也能拉人，公交也能拉貨。但畢竟都不是自己的設計初衷！沒有萬能的語言，只有合適的場景。每種程式語言的誕生，都是由它要解決的應用場景為初衷。Python設計的時候，已經有人能把exe這活幹的很好，沒必要去做重複的事。

我覺得你需要搞清楚一個概念，runtime. exe 只是一個殼子，exe 可以把整個just-in-time編譯器和程式碼全部打包。看上去就是一個exe，但和你想象的exe不是一回事。程式分為三種，一種比如c,c++, rust，不需要JIT (just-in-time)編譯器，不需要 runtime。第二種是不需要JIT 但需要runtime 比如 go, 它的gc 是runtime來實現的。第三種是需要JIT和runtime 比如java, .net, javascript, python 等等。JIT 的任務是產生中間程式碼，java 叫byte code, .net 叫 IL. 僅僅打包為 exe 不代表可以確定是三種中的任何一種。比如你把 .net 的exe 反編譯，得到的程式碼甚至不是IL而是稍稍變了一點樣子的原始碼。我們知道機器是不需要函式名的，反編譯看到函式名說明什麼？說明本來打包為exe就沒怎麼動你的程式碼，僅僅是做了語法分析和linking，但是沒有真正意義上向c++那樣編譯而產生機器執行指令。這一點來講，java, .net, python， javascript 其實區別只是是不是強型別，沒有哪個真正釋出了“編譯”，應該是 比compile 原始但比transcoding更復雜一點的那種事。