Python 2.5的.pyc文件与Python 2.6的.pyc文件兼容吗？

Question

之前我需要把一些服务器的Python版本从2.4升级到2.5。结果发现，Python 2.4生成的.pyc文件在Python 2.5运行时会崩溃。

那我从2.5升级到2.6的时候，会不会再出现这种情况呢？

补充说明一下：

我有一台文件服务器，里面存放着Python代码。这个服务器被Ubuntu和Windows的服务器访问，用来运行这些Python代码。当它们运行代码时，会在文件服务器上生成.pyc文件。

我发现，当我把其中一台服务器从Python 2.4升级到2.5时，.pyc文件出现了问题。我现在不太确定是2.5的机器尝试运行2.4的字节码，还是2.4的机器尝试运行2.5的字节码，但如果我删除了字节码，问题就解决了，直到下次再出现字节码冲突。

后来我把所有机器都升级到2.5，问题就消失了。

Answer 1

创建文件的Python版本信息其实是保存在.pyc文件里的。通常情况下，这意味着.pyc文件会被一个正确版本的文件替换掉。

但是，有一些原因可能导致这种替换没有发生：
- 权限问题
- .py文件不可用

如果是权限问题，Python会直接使用.py文件，而忽略.pyc文件（这样会影响性能）。

不过，我觉得在小版本之间是可以的，比如Python2.6.2的.pyc文件应该可以在Python2.6.4中正常工作。

这里有一段来自/usr/share/file/magic的摘录：

# python:  file(1) magic for python
0   string      """ a python script text executable
0   belong      0x994e0d0a  python 1.5/1.6 byte-compiled
0   belong      0x87c60d0a  python 2.0 byte-compiled
0   belong      0x2aeb0d0a  python 2.1 byte-compiled
0   belong      0x2ded0d0a  python 2.2 byte-compiled
0   belong      0x3bf20d0a  python 2.3 byte-compiled
0   belong      0x6df20d0a  python 2.4 byte-compiled
0   belong      0xb3f20d0a  python 2.5 byte-compiled
0   belong      0xd1f20d0a  python 2.6 byte-compiled

所以你可以看到，.pyc文件的前4个字节就表示了正确的Python版本。

Answer 2

如果你有源代码，那么它会为你重新编译。所以一般来说，你是没问题的。

但是，如果不同版本的Python用户都从同一个安装目录运行，那可能会有问题。

如果你只有pyc文件，那也可能会出问题。我为你做了个简单测试。我创建了两个.pyc文件，一个是2.5版本的，另一个是2.6版本的。2.5版本的文件在2.6版本上无法运行，2.6版本的文件在2.5版本上也无法运行。它们都会报错“ImportError: Bad magic number in ..”，这很正常，因为从2.5到2.6，魔法数字（magic number）发生了变化。

如果你想提前确定这个问题，可以按以下方式获取你的Python的魔法数字：

$ python -V
Python 2.6.2
# python
>>> import imp
>>> imp.get_magic().encode('hex')
'd1f20d0a'

要获取pyc文件的魔法数字，你可以这样做：

>>> f = open('test25.pyc')
>>> magic = f.read(4)
>>> magic.encode('hex')
'b3f20d0a'
>>> f = open('test26.pyc')
>>> magic = f.read(4)
>>> magic.encode('hex')
'd1f20d0a'

Answer 3

一般来说，.pyc 文件是针对特定的 Python 版本的（不过在不同的机器架构上是可以通用的，只要它们运行的是相同的版本）。这些文件在头部包含了相关 Python 版本的信息。所以，如果你把对应的 .py 文件和 .pyc 文件放在一起，每次用不同的 Python 版本导入这些模块时，.pyc 文件都会被重新生成。我从来没有听说过“尝试运行”错误版本的 .pyc 文件。那涉及到哪些架构呢？.py 文件是否都在应该在的地方呢？

编辑：因为提问者澄清了崩溃发生在他同时运行 Python 2.4 和 Python 2.5 程序时，使用的是同一组 .py 文件（来自两个不同的服务器，共享一个网络驱动），所以崩溃的原因变得很简单。.py 文件一直在被重新编译——当 2.5 版本最近运行过这些文件时，2.4 版本会重新编译它们，反之亦然——因此 .pyc 文件一直在忙着被重写。在网络驱动上实现正确的文件锁定（尤其是在不同操作系统之间）是非常困难的。所以接下来发生的事情可能是这样的（角色可以互换）：2.4 服务器刚刚确定一个 .pyc 文件对它来说是好的，并开始读取；在它完成读取之前，2.5 服务器（之前已经确定该模块需要重新编译）覆盖了它；结果 2.4 服务器得到的内存缓冲区可能包含了（比如说）前 4K 字节是 2.4 版本的，接下来的 4K 字节是 2.5 版本的。当它使用这个混乱的缓冲区时，毫无疑问…… 崩溃！！！

如果你发现自己不断尝试从两个或多个不同版本的 Python 运行同一组 .py 文件（即使在同一台服务器上，没有网络驱动的额外复杂性），这可能会成为一个真正的问题。“正确”的解决方案应该是类似于 virtualenv 的东西。我们在工作中采用的（简单但有点脏的）解决方法是给每个版本的 Python 打补丁，让它们生成和使用不同的扩展名来表示它们的编译字节码文件：.pyc（或 .pyo）用于 Python 1.5.2（这是我们开始做这个临时解决方案时最稳定的“系统”版本），.pyc-2.0 用于 2.0，.pyc-2.2 用于 2.2，依此类推（当然也可以是等效的 .pyo-X.Y）。我听说这个方法终于要结束了（谢谢你，Thomas！），但它确实在很多年里帮助我们解决了这个棘手的问题。

一个更简单的解决方案是，如果你的系统允许的话，保持只有一个版本的 Python；如果你的系统有任何复杂性使得无法只使用一个 Python 版本（就像我们的系统一样），那么现在我强烈推荐使用 virtualenv，我之前已经提到过了。

---

随着在 Python 3.2 中采用的 PEP 3147，不同 Python 版本的 pyc 文件会通过文件名自动区分。这应该能解决大部分不同 Python 版本互相覆盖 pyc 文件的问题。