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

你肯定会牺牲很多的可移植性——现在 .pyc 文件是不寻常的可移植的(通常由局域网上的异类系统通过某种网络文件系统安排使用,例如,尽管我从来都不喜欢这种方法的性能特征),而您的方法只适用于非常特定的文件系统和(USPECT)永远不要跨网络安装在异构机器上。

所以,做出你想要的默认行为是一个严重的错误——但是把它作为一个 选项 如果您的部署环境不关心上述所有问题,并且确实关心您提到的一些问题,那么可以用于特定的请求。另一个“很酷的选择”,我会经常使用大约100次,是把 PYC A中的“文件” 数据库 而不是把它们放在文件系统中。

很酷的是,这是(相对而言)很容易作为一个附加的“导入黑客”一种或另一种方式(取决于python版本)完成的——在最近足够多的版本中, importlib Brett Cannon的杰作(但这可能会使恢复到旧的python版本比其他方式更困难…过多地依赖于您需要支持的具体版本,一个我在您的Q中没有看到的细节,所以我不会深入讨论实现细节,但是整个实现的总体思想不会有太大的改变)。

我放弃的一个问题是,它意味着每个平台都有不同的行为。

下一个问题是,不是每个OS X支持的文件系统都支持资源分叉(而且它将资源分叉存储在非HFS文件系统中的方式是其他人普遍讨厌的:.\

尽管如此,我经常被Apache使用的.pyc文件咬到,因为Apache进程无法读取我替换的.py文件。但我认为这不是解决方案:更好的部署过程是;)