你知道在终端执行 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 解决方案理想，但它确实可行，并且在这种情况下算得上是优雅的。

文章转载于马哥教育官网！