优点：
首先：温和的、可克服的混淆。
第二：如果编译后的文件明显更小，您将获得更快的加载时间。非常适合网络。
第三：Python可以跳过编译步骤。在初始负载下更快。非常适合 CPU 和网络。
第四：评论越多，.pyc 或.pyo 文件与源.py 文件相比就越小。
第五：手头只有.pyc 或.pyo 文件的最终用户不太可能向您展示由于他们忘记告诉您的未还原更改而导致的错误。
第六：如果你的目标是嵌入式系统，获得更小的尺寸
要嵌入的文件可能是一个显着的优点，而且架构是稳定的，所以下面详述的缺点之一不会发挥作用。
顶级编译
知道您可以通过这种方式将顶级 python 源文件编译成.pyc 文件是很有用的：
python -m py_compile myscript.py
这会删除 cmets。它使docstrings 完好无损。如果您也想摆脱docstrings（您可能要认真考虑为什么要这样做），那么请改用这种方式编译...
python -OO -m py_compile myscript.py
...你会得到一个.pyo 文件而不是.pyc 文件；在代码的基本功能方面同样可分配，但比剥离的 docstrings 的大小更小（如果它首先具有体面的 docstrings，那么以后的工作就不太容易理解）。但请参阅下面的缺点三。
请注意，python 使用 .py 文件的日期（如果存在）来决定它是否应该执行 .py 文件而不是 .pyc 或 .pyo 文件 --- 所以编辑你的 .py文件，而 .pyc 或 .pyo 已过时，您获得的任何好处都将丢失。您需要重新编译它才能再次获得 .pyc 或 .pyo 的好处，就像他们可能的那样。
缺点：
首先：.pyc 和 .pyo 文件中有一个“magic cookie”，它指示编译 python 文件的系统架构。如果将其中一个文件分发到不同类型的环境中，它将休息。如果您分发 .pyc 或 .pyo 而没有关联的 .py 重新编译或 touch 以取代 .pyc 或 .pyo，最终用户也无法修复它。
第二：如果docstrings 如上所述使用-OO 命令行选项跳过，则没有人能够获得该信息，这会使代码的使用更加困难（或不可能。 )
第三：Python的-OO选项也按照-O命令行选项实现了一些优化；这可能会导致操作发生变化。已知的优化有：
-
sys.flags.optimize = 1
-
assert 语句被跳过
-
__debug__ = 错误
第四：如果你故意让你的 python 脚本在第一行使用#!/usr/bin/python 的顺序执行，这将在.pyc 和.pyo 文件中被删除，并且该功能将丢失。
第五：有些明显，但如果你编译你的代码，不仅会影响它的使用，而且其他人从你的工作中学习的可能性也会降低，通常会很严重。