让python将编译代码存储在文件流而不是pyc文件中是个好主意吗？

Question

我在想，如果Python将编译后的代码存储在原始源文件的文件流中，是否会更好。这将在支持分叉/数据流的文件系统上工作，如果这是不可能的，则将其退回。

• 在Windows上使用ADS (可选数据流)
• 使用资源叉的OS
• 在Linux上使用扩展文件属性，如果编译的文件低于32k

这样做将解决污染源树的问题，或者出现问题，比如在删除.py之后，.pyc仍然存在并被加载和使用。

你怎么看，听起来是不是个好主意？有什么问题要看。

Answer 1

您确实以这种方式牺牲了大量的可移植性--现在.pyc文件是不常见的可移植的(例如，通过某种网络文件系统安排，局域网上的异构系统经常使用它，尽管我从来都不喜欢这种方法的性能特性)，而您的方法只能在非常特定的文件系统上工作，而且(我怀疑)永远不会跨网络安装在异类机器上。

所以，做出你想要的默认行为是一个可怕的错误--但是如果你的部署环境不关心上面提到的所有问题，并且关心你提到的一些问题，那么将它作为一个可供特定请求使用的选项无疑是很好的。另一个“很酷的选项”，实际上我会更经常地使用它，就是将.pyc“文件”放在数据库中，而不是将它们放在文件系统中。

最酷的是，这是(相对地)很容易作为一种附加的“导入黑客”(取决于Python )的方式来实现的--在最近的版本中--与布雷特·坎农的杰作--足够多的版本(但这可能会使支持旧版本的Python版本比其他方式更难.这在很大程度上取决于您需要支持哪些版本，我在您的Q中没有看到这个细节，所以我不会详细介绍实现细节，但是总体思想在不同的实现中不会有太大变化)。

Answer 2

我忽略的一个问题是，这意味着每个平台都有不同的行为。

其次，并不是每个文件系统OS支持的文件系统都支持资源分叉(并且它在非hfs文件系统中存储它们的方式被其他人普遍讨厌：._ )。

尽管如此，我经常被apache使用的.pyc文件咬伤，因为apache进程无法读取我所替换的.py文件。但我认为这不是解决办法:一个更好的部署过程是;)