Question

首先，我无法为此问题提供MCVE，所以请耐心等待。

在Windows 7上安装是Python 2.7.9。

一些背景：似乎Python将.pyc文件缓存在内存中，甚至在解释器会话之间，尽管我无法找到有关此内容的任何信息。这可以看出（我认为），当我在新的启动后启动GTK应用程序时，加载需要大约6秒，此后它需要<1s。

此应用程序是一个测试序列器，它在单独的线程中运行测试以避免阻塞GTK主循环。昨天我遇到了一个奇怪的问题，如果在测试线程运行时命令窗口在某一点被强制关闭，后续运行将在创建dict时引发异常，例如：

TypeError("unhashable type: 'cts: unknown\n  picker: [None|float|boolean|callable]         \n  pickradius: unknown\n  rasterized: [True | False | None]
\n  sketch_params: unknown\n  snap: unknown\n  transform: :class:'~matplotl'",)

单引号内的实际“类型”各不相同，可以是任何内容。实际的dict定义更复杂，但在这种情况下仍然会失败：

comptypevalidity = {'EQ':True,
                    'NE':False,
                    'GT':False,
                    'LT':False,
                    'GE':False,
                    'LE':False,
                    'GELE':False,
                    'GTLT':False,
                    'GELT':False,
                    'GTLE':False,
                    'LOG':True}

你会发现我并没有尝试用一些深奥的对象创建一个Dict键，而只是字符串。大部分时间它都有效，只有在这种情况下，字节码似乎已经被破坏才会失败。

现在，我非常确定这是一个CTypes /指针类型问题，其中DLL未正确关闭。

我正在努力解决的问题是，我能让它再次运行的唯一方法是强制重新编译引发异常的.pyc，删除它。我已经完成了“好”和“坏”文件的文件比较，看看它们是否在硬盘上被破坏了，但正如预期的那样，它们是相同的。

修复程序正在运行带有-B标志的Python，因此没有写入.pyc，这似乎也迫使解释器重新编译，而不是使用缓存在RAM中的版本。

所以，我的问题有两个：

Python缓存到RAM是否属实，如果不是 - 我在这里看到了什么？如何在解释器会话中使用损坏的.pyc持久性

我可以强制Python 不缓存这些文件吗？

缓存.pyc字节码的奇怪腐败

0 个答案: