Python 伪导入器（模块导入子模块？）

我有一个问题，我真的不知道从哪里开始解决。也许它会给某人敲响警钟

TLDR:Django应用程序崩溃，重新启动后运行，但无法导入某些模块。重新启动后，一切又恢复正常

整个故事：

不同Python（2.5.x、2.6.x和2.6.x）和Django版本（分别为1.1.0、1.2.5和1.3.0）上的不同应用程序（我们现在最多有三个）偶尔会出现虚假的导入。例如，其中一个应用程序开始在每个请求中失败，原因是在其中抛出了一个导入错误：

from django.contrib.gis.maps.google import GMarker, GEvent

我们收集了

strace

输出，下面是相关的区块（为了简洁和保护罪犯，绝对路径替换为DIR）

（同样的事情是s/GMarker/GEvent/）

重新启动流程后，一切都会顺利运行，同时也会运行：

python -c 'from django.contrib.gis.maps.google import GMarker'

不会产生错误

GMarker和GEvent类实际上是在

django.contrib.gis.maps.google.overlays

中定义的，并导入到

…maps/google/\uuuuuu init\uuuuuuuuuuuuuy.py

：

from django.contrib.gis.maps.google.gmap import GoogleMap, GoogleMapSet
from django.contrib.gis.maps.google.overlays import GEvent, GIcon, GMarker, GPolygon, GPolyline
from django.contrib.gis.maps.google.zoom import GoogleZoom

因此，完全可以预期加载GMarker.py等人将失败。Python似乎不知何故忘记了

\uuuu init\uuuu.py

及其名称空间

这些应用程序的流量相对较高，可以想象（尽管不确定）它们可能已经超过了虚拟机的限制，并且恢复得非常顺利。此外，至少在两个案例中，该应用程序出现了导致崩溃的早期问题——一个案例是SIGSEGV，另一个案例是err。。。另一个世界里的其他东西）。一次应用程序重启导致它抛出导入程序，另一次重启使它再次运行。损坏的.py[c]？时间戳是古老的

所有这些应用程序都运行在从wsgi到fastcgi服务器的flup上

到目前为止，这些应用程序中的每一个都失败了一次（在完全不同的模块中，有两个案例是

\uuuu init\uuuu.py

被“遗忘”，但我找不到第三个错误），因此我无法判断这些模块是否有意义

---

任何和所有的指针和想法感谢

strace输出在我看来是可疑的：

DIR/django/contrib/gis/...

---

我想知道这个

DIR

部分。您是否可能在某处键入了PYTHONPATH变量，使用了

DIR

而不是

$DIR

？

实际上，您的strace行没有任何帮助；这些访问不会导致导入模块

此类导入错误可能有多种原因：

有人修改了sys.path，它不再在模块路径中

这些模块中的循环导入，由您首先从另一个模块导入触发

您有站点冲突（是的，有那种），同一个模块从不同的站点包位置加载

搜索路径中的某个模块与某处的其他模块或系统模块冲突

如果你粘贴第二组斜线，我们就更接近解决方案了

更新 两个人。我的意思是，如果你有两个具有以下结构的文件

foo.py/init.py:

from bar import baz

import foo
def baz():
     pass

bar.py/init.py:

from bar import baz

import foo
def baz():
     pass

snafu.py：

import bar
import foo

ok.py：

import foo
import snafu

---

运行python snafu.py，您会得到一个崩溃和类似的strace输出，运行python ok.py，一切正常。

我建议您用try来包装导入。。。除了importorror和添加这样做的代码（任何记录而不是打印的东西都可以）

---

这应该让您了解发生了什么。

您能澄清一下您是如何管理多个不同的Python和Django版本的吗？这是在不同的系统上还是在同一个系统上，使用virtualenv或其他一些黑客让它们并行运行？完全不相关的系统（不同的物理机器，不同的DC）。基本映像是相同的，例如，所有Python版本都安装在任何地方。但稳定状态下一切正常（系统路径正确等）。使用100%相同的环境重新启动应用程序“修复”了任何问题。这些不是我要升级的应用程序。我被他们使用的东西困住了。你确定你的Web服务器配置没有使用踏板吗？您是否在报告中看到

'wsgi.multi-thread'：False

？否则，服务器配置（使用apache？、模块、选项、flup版本等）可能比应用程序更重要。试着想想两个常见问题：不，我在准备这篇文章时，为了简洁起见，用“DIR”替换了完整路径$PYTHONPATH是正确的，正如应用程序重新启动后所看到的。这个问题已经有一段时间没有出现了，现在对我来说优先级很低。你说的第二盘到底是什么意思？你提到的所有事情都会导致应用程序无法完全工作，不会在崩溃后无法重新启动，对吧？不一定是真的，除了4个。我相应地更新了我的答案。我试验了我的周期性进口假设，用上面的内容制作foo和bar包；如果我先导入bar，当python试图查找baz.py、baz.so等时，我会得到strace输出。。。这就是我现在倾向于的。