如何将已编译的 python 文件放在单独的文件夹中？
是否可以让 Python 将 .pyc 文件保存到 sys.path 中的单独文件夹位置？
/code
foo.py
foo.pyc
bar.py
bar.pyc
致：
/code
foo.py
bar.py
/code_compiled
foo.pyc
bar.pyc
我想要这个，因为我觉得这样会更有条理。 感谢你给与我的帮助。
Is it possible to have Python save the .pyc files to a separate folder location that is in sys.path?
/code
foo.py
foo.pyc
bar.py
bar.pyc
To:
/code
foo.py
bar.py
/code_compiled
foo.pyc
bar.pyc
I would like this because I feel it'd be more organized. Thanks for any help you can give me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
更新：
在 Python 3.8 中，
-X pycache_prefix=PATH命令行选项允许将.pyc文件写入以给定目录为根的并行树到代码树。 请参阅$PYTHONPYCACHEPREFIXenvvarcredits: @RobertT' 答案缓存的位置在
sys.pycache_prefix（None表示__pycache__[自 Python 3.2] 子目录中的默认位置）。要关闭缓存已编译的Python字节码，可以设置
-B，然后Python将不会尝试在导入源模块时写入.pyc文件。 请参阅$PYTHONDONTWRITEBYTECODEenvvar学分：@Maleev 的回答旧的 [Python 2] 答案：
有PEP 304：控制字节码文件的生成。 其状态为
撤回，相应的补丁被拒绝。 因此可能没有直接的方法来做到这一点。如果您不需要源代码，那么您可以删除
*.py文件。*.pyc文件可以按原样使用，也可以打包在 Egg 中。Update:
In Python 3.8
-X pycache_prefix=PATHcommand-line option enables writing.pycfiles to a parallel tree rooted at the given directory instead of to the code tree. See$PYTHONPYCACHEPREFIXenvvarcredits: @RobertT' answerThe location of the cache is reported in
sys.pycache_prefix(Noneindicates the default location in__pycache__[since Python 3.2] subdirectories).To turn off caching the compiled Python bytecode,
-Bmay be set, then Python won’t try to write.pycfiles on the import of source modules. See$PYTHONDONTWRITEBYTECODEenvvarcredits: @Maleev's answerOld [Python 2] answer:
There is PEP 304: Controlling Generation of Bytecode Files. Its status is
Withdrawnand corresponding patch rejected. Therefore there might be no direct way to do it.If you don't need source code then you may just delete
*.pyfiles.*.pycfiles can be used as is or packed in an egg.在 2003 年黑暗而古老的日子里，PEP 304 的出现来挑战这个问题。 发现它的补丁有缺陷。 环境变量平台依赖性和版本偏差将其撕成碎片，并将其碎片散布在荒原上。
经过多年的苦难，新的挑战者在 2009 年的最后几天崛起。巴里·华沙 (Barry Warsaw) 召唤了 PEP 3147 并发送了它可以熟练地使用简单的武器进行战斗。 PEP 粉碎了杂乱的 PYC 文件，让警惕的 Unladen Swallow 和 CPython 解释器保持沉默，每个解释器都试图争论其 PYC 文件应该取得胜利，并让 Python 可以高枕无忧，让它的死鬼偶尔在深夜运行。 PEP 3147 被独裁者发现有价值，并在 3.2 时代被封为官方角色。
从 3.2 开始，Python 将模块的 PYC 文件存储在模块目录下的
__pycache__中。 每个PYC文件包含解释器的名称和版本，例如__pycache__/foo.cpython-33.pyc。 您可能还拥有由早期版本的 Python 编译的 __pycache__/foo.cpython-32.pyc。 正确的魔法发生了：如果与源代码不同步，则使用正确的魔法并重新编译。 在运行时，查看模块的mymodule.__cached__中的 pyc 文件名，并使用imp.get_tag()解析它。 有关详细信息，请参阅新增功能部分。TL;DR - 仅适用于 Python 3.2 及更高版本。 糟糕的黑客替代了之前的版本。
In the dark and ancient days of 2003, PEP 304 came forth to challenge this problem. Its patch was found wanting. Environment variable platform dependencies and version skews ripped it to shreds and left its bits scattered across the wastelands.
After years of suffering, a new challenger rose in the last days of 2009. Barry Warsaw summoned PEP 3147 and sent it to do battle, wielding a simple weapon with skill. The PEP crushed the cluttering PYC files, silenced the waring Unladen Swallow and CPython interpreter each trying to argue its PYC file should be triumphant, and allowed Python to rest easy with its dead ghosts occasionally running in the dead of night. PEP 3147 was found worthy by the dictator and was knighted into the official roles in the days of 3.2.
As of 3.2, Python stores a module's PYC files in
__pycache__under the module's directory. Each PYC file contains the name and version of the interpreter, e.g.,__pycache__/foo.cpython-33.pyc. You might also have a__pycache__/foo.cpython-32.pyccompiled by an earlier version of Python. The right magic happens: the correct one is used and recompiled if out of sync with the source code. At runtime, look at the module'smymodule.__cached__for the pyc filename and parse it withimp.get_tag(). See the What's New section for more information.TL;DR - Just works in Python 3.2 and above. Poor hacks substitute for versions before that.
仅仅十年后，Python 3.8 终于通过设置环境变量 PYTHONPYCACHEPREFIX 或使用 -X pycache_prefix=PATH 参数（官方文档）提供了将字节码保存在单独的并行文件系统树中的支持此处）。
And only almost ten years later, Python 3.8 finally provides support for keeping bytecode in separate parallel filesystem tree by setting environment variable
PYTHONPYCACHEPREFIXor using-X pycache_prefix=PATHargument (official doc here).如果您愿意为此完全牺牲字节码生成，那么有一个命令行标志：
可以放入 IDE 的构建/运行首选项中
If you're willing to sacrifice bytecode generation altogether for it, there's a command line flag:
Can be put into IDE's build/run preferences
我同意，将代码作为鸡蛋分发是保持代码井井有条的好方法。 还有什么比包含您需要的所有代码和元数据的单个文件更有组织性的呢？ 改变字节码编译器的工作方式只会引起混乱。
如果您确实不喜欢这些 pyc 文件的位置，另一种方法是从只读文件夹运行。 由于 python 无法写入，因此不会生成 pyc 文件。 你遭受的打击是，每个 python 文件在加载后都必须重新编译，无论你是否更改过它。 这意味着你的启动时间会更糟。
I agree, distributing your code as an egg is a great way to keep it organized. What could be more organized than a single-file containing all of the code and meta-data you would ever need. Changing the way the bytecode compiler works is only going to cause confusion.
If you really do not like the location of those pyc files, an alternative is to run from a read-only folder. Since python will not be able to write, no pyc files ever get made. The hit you take is that every python file will have to be re-compiled as soon as it is loaded, regardless of whether you have changed it or not. That means your start-up time will be a lot worse.
我不同意。 理由是错误的，或者至少没有很好地阐述； 但方向是有效的。 能够将源代码与编译对象分离是有充分理由的。 以下是其中的一些（我曾在某一时刻遇到过所有这些）：
所有这些问题都有解决方法，但它们大多是解决方法而不是解决方案。 在大多数情况下，正确的解决方案是让软件接受替代位置来存储和查找这些过渡文件。
I disagree. The reasons are wrong or at least not well formulated; but the direction is valid. There are good reasons for being able to segregate source code from compiled objects. Here are a few of them (all of them I have run into at one point or another):
There are workarounds for all these problems, BUT they are mostly workarounds NOT solutions. The proper solution in most of these cases would be for the software to accept an alternative location for storing and lookup of these transitional files.
由于Python 3.2已经实现PEP 3147：这意味着所有.pyc文件在 __pycache__ 目录中生成（对于您所在的每个目录，都会有一个 __pycache__ 目录）有 Python 文件，并且它将保存源中使用的每个 Python 版本的 .pyc 文件）
Since Python 3.2 has been implemented PEP 3147: this means that all .pyc files are generated inside a __pycache__ directory (there will be a __pycache__ directory for each directory where you have Python files, and it will hold .pyc files for each version of Python used on the sources)
正在进行的 pep 将启用将字节码构建到 magic 目录。
基本上所有的Python文件都会被编译到目录
__pythoncache__。There is ongoing pep that will enable building bytecode to magic directory.
Basically all python files will be compiled to directory
__pythoncache__.对于 Python 3.8 或更高版本：
PYTHONPYCACHEPREFIX设置（也可用作 -Xpycache_prefix）将隐式字节码缓存配置为使用单独的文件系统树，而不是每个源目录中默认的__pycache__子目录。缓存的位置在
sys.pycache_prefix中报告（None表示__pycache__子目录中的默认位置）。For Python 3.8 or higher:
The
PYTHONPYCACHEPREFIXsetting (also available as -Xpycache_prefix) configures the implicit bytecode cache to use a separate filesystem tree, rather than the default__pycache__subdirectories within each source directory.The location of the cache is reported in
sys.pycache_prefix(Noneindicates the default location in__pycache__subdirectories).“我觉得这样会更有条理”为什么？ 如何？ 你想达到什么目的？
保存编译器输出的目的是在导入模块时节省一点点加载时间。 为什么要让这个变得更加复杂？ 如果您不喜欢 .pyc，请定期运行“删除所有 .pyc”脚本。
它们不是必需的；而是必需的。 他们很有帮助。 为什么要关闭该帮助？
这不是 C、C++ 或 Java，其中结果对象是必不可少的。 这只是Python碰巧使用的一个缓存。 我们在 Subversion 中将它们标记为“忽略”，这样它们就不会意外地被签入。
"I feel it'd be more organized" Why? How? What are you trying to accomplish?
The point of saving the compiler output is to save a tiny bit of load time when the module gets imported. Why make this more complex? If you don't like the .pyc's, then run a "delete all the .pyc's" script periodically.
They aren't essential; they're helpful. Why turn off that help?
This isn't C, C++ or Java where the resulting objects are essential. This is just a cache that Python happens to use. We mark them as "ignored" in Subversion so they don't accidentally wind up getting checked in.