你知道在終端執行 Python 代碼的方式嗎?
1、通過標準輸入和管道因為如何用管道傳東西給一個進程是屬于 shell 的內容,我不打算深入解釋。毋庸置疑,你可以將代碼傳遞到 Python 中。
# 管道傳內容給 pythonecho "print('hi')" | python
如果將文件重定向到 Python,這顯然也可以。
# 重定向一個文件給 pythonpython < spam.py
歸功于 Python 的 UNIX 傳統,這些都不太令人感到意外。
2、通過 -c 指定的字符串如果你只需要快速地檢查某些內容,則可以在命令行中將代碼作為字符串傳遞。
# 使用 python 的 -c 參數python -c "print('hi')"
當需要檢查僅一行或兩行代碼時,我個人會使用它,而不是啟動 REPL(譯注:Read Eval Print Loop,即交互式解釋器,例如在 windows 控制臺中輸入python, 就會進入交互式解釋器。-c 參數用法可以省去進入解釋器界面的過程)
3、文件的路徑最眾所周知的傳代碼給 python 的方法很可能是通過文件路徑。
# 指定 python 的文件路徑python spam.py
要實現這一點的關鍵是將包含該文件的目錄放到sys.path里。這樣你的所有導入都可以繼續使用。但這也是為什么你不能/不應該傳入包含在一個包里的模塊路徑。因為sys.path可能不包含該包的目錄,因此所有的導入將相對于與你預期的包不同的目錄。
4、對包使用 -m執行 Python 包的正確方法是使用 -m 并指定要運行的包名。
python -m spam
它在底層使用了runpy[5]。要在你的項目中做到這點,只需要在包里指定一個__main__.py文件,它將被當成__main__執行。而且子模塊可以像任何其它模塊一樣導入,因此你可以對其進行各種測試。
我知道有些人喜歡在一個包里寫一個main子模塊,然后將其__main__.py寫成:
from . import mainif __name__ == "__main__": main.main()
就我個人而言,我不感冒于單獨的main模塊,而是直接將所有相關的代碼放入__main__.py,因為我感覺這些模塊名是多余的。
(譯注:即作者不關心作為入口文件的"main"或者“main”模塊,因為執行時只需用它們的包名即可。我認為這也暗示了入口模塊不該再被其它模塊 import。我上篇文章 [6]比作者的觀點激進,認為連那句 if 語句都不該寫。)
5、執行一個壓縮文件如果你確實有多個文件和/或依賴模塊,并且希望將所有代碼作為一個單元發布,你可以用一個__main__.py,放置在一個壓縮文件中,并把壓縮文件所在目錄放在 sys.path 里,Python 會替你運行__main__.py文件。
# 將一個壓縮包傳給 Pythonpython app.pyz
人們現在習慣上用 .pyz 文件擴展名來命名此類壓縮文件,但這純粹是傳統,不會影響任何東西;你當然也可以用 .zip 文件擴展名。
為了簡化創建此類可執行的壓縮文件,標準庫提供了zipapp[7]模塊。它會為你生成__main__.py并添加一條組織行(shebang line),因此你甚至不需要指定 python,如果你不想在 UNIX 上指定它的話。如果你想移動一堆純 Python 代碼,這是一種不錯的方法。
不幸的是,僅當壓縮文件包含的所有代碼都是純 Python 時,才能這樣運行壓縮文件。執行壓縮文件對擴展模塊無效(這就是為什么 setuptools 有一個 zip_safe[8]標志的原因)。(譯注:擴展模塊 extension module,即 C/C++ 之類的非 Python 文件)
要加載擴展模塊,Python 必須調用 dlopen()[9]函數,它要傳入一個文件路徑,但當該文件路徑就包含在壓縮文件內時,這顯然不起作用。
我知道至少有一個人與 glibc 團隊交談過,關于支持將內存緩沖區傳入壓縮文件,以便 Python 可以將擴展模塊讀入內存,并將其傳給壓縮文件,但是如果內存為此服務,glibc 團隊并不同意。
但是,并非所有希望都喪失了!你可以使用諸如shiv[10]之類的項目,它會捆綁(bundle)你的代碼,然后提供一個__main__.py來處理壓縮文件的提取、緩存,然后為你執行代碼。盡管不如純 Python 解決方案理想,但它確實可行,并且在這種情況下算得上是優雅的。
好啦!今天的分享到這里就結束了,希望大家持續關注馬哥教育官網,每天都會有大量優質內容與大家分享!
版權聲明:轉載文章來自公開網絡,版權歸作者本人所有,推送文章除非無法確認,我們都會注明作者和來源。如果出處有誤或侵犯到原作者權益,請與我們聯系刪除或授權事宜。