但是每當想到創建一個新Python實現的艱巨任務時，我就會不斷地問自己：

 

　　“Python究竟是什么？”

 

　　我們使用CPython已經很長時間了，以至于我懷疑我們大多數人都認為“ Python == CPython”。PyPy試圖將兼容做到極致，所以他們打算實現CPython的實現細節?；旧?，我所知道的大多數Python實現都會為通過CPython的測試套件而努力，并盡可能與CPython兼容。

 

　　這就有點可怕了。

 

　　CPython實現的Python非常動態，它公開了許多東西，只有當你以某種方式使用解釋器實現Python才有意義。例如，PyPy有一個基本的解釋器使用JIT，但是你可以通過Python中的很多東西來迫使PyPy關閉JIT并堅持使用字節碼。僅憑REPL就讓Python變得十分動態，因為輸入到REPL的所有內容都會由解釋器動態地解析、編譯和執行。

 

　　因此我開始思考：Python到底是什么的問題？這門語言的核心究竟是什么？究竟Python實現需要覆蓋到哪些基本功能，才能成為人們心目中認可的Python實現？還有以我來看，將Python直接編譯成WebAssembly的實現需要付出多少代價？

 

　　Python是否需要REPL？

 

　　我真正開始思考這個問題是當我開始思考將Python編譯成WebAssembly都需要什么的時候。這并不是要實現另一個解釋器，而是從Python源代碼產生靜態的WebAssembly，并且它依然可以稱為“Python”。

 

　　我知道的，通過eva()或compile()進行動態編譯可能不容易實現，因為WebAssembly的安全模型會在加載時驗證模塊。這意味著沒有辦法在其他代碼的內存空間內運行任意代碼，這可能會加劇實現REPL的難度。

 

　　但這讓我思考：Python真的需要REPL嗎？別誤會我的意思，它非常方便，但是我的意思是，如果某個實現不包含REPL，那么它還是Python嗎？我認為無REPL的Python仍然是Python，只是缺少（可能是關鍵的）功能。

 

　　這不禁讓我思考必須將Python的哪些部分視為“ Python”的想法。

 

　　沒有locals()行不行？能夠將定義的所有局部變量及其值都收集到一個字典中，這是非常動態的東西。如果你使用像CPython這種解釋器，那么只需要從當前的執行幀里取一些東西就能獲得locals。但在編譯語言中，實現這一點需要大量工作，因為你必須知道應當何時收集這些信息，因為調用locals()的時候并不一定所有信息都存在。

 

　　如果有人重載了locals()怎么辦？同樣，在CPython中這也不是什么問題，因為builtins模塊有一個__dict__屬性，只需要重載它，就會向下傳遞到以后的調用中。但在編譯語言中，做類似的檢測需要大量的工作，最終會影響性能。

 

　　那么sys.settrace()呢？它會觸發每個字節的回調，而如果代碼已經編譯，這一點是無法實現的。盡管你可以通過檢查每行末尾是否設置了跟蹤函數來模仿這一行為，但這似乎有點過了，因為絕大多數情況下這種鉤子并不存在（盡管可以實現為編譯器開關）。

 

　　那么sys._getframe()呢？編譯語言并不一定能夠直接訪問每個執行幀，那么你還要不要模擬這一行為？由于任何函數都可以請求執行幀，你必須時刻準備著提供執行幀。

 

　　可見，Python中有很多東西加劇了編譯的難度（因此Nuitka擁有更大的能力來應對這一挑戰）。但是我敢打賭，上面提到的內容在99.9%的情況下都不會使用，因此，如果這些功能沒有實現，那么是否仍可以將其視為“Python”？

 

　　具備多少兼容性才有意義？

 

　　這個問題沒有很好的答案。

 

　　但是這個問題的答案標志著實現Python的難度以及與現有軟件的兼容性。WebAssembly不需要支持大量的Python軟件。WebAssembly可以訪問Rust和JavaScript等其他語言生態系統，因此你需要的某個東西完全有可能在其他語言中已經實現了。

 

　　也許我們可以開發一個將Python代碼直接轉換為WebAssembly并犧牲性能兼容性的編譯器。也許我們可以開發針對WebAssembly設計的解釋器，同時與先前已有的代碼保持兼容性。也許可以僅在其WebAssembly工作中支持RustPython。也許Pyodide可以實現這一點。我認為這些都有可能，這些都有可能激發人們的興趣，進而產生更好的結果。