我们在Windows XP 32bit上有一个基于Excel 2003和Python 2.4的应用程序。 该应用程序由大量的Python函数组成，可以从许多Excel工作表中调用。
我们没有发现一个exception的行为，有时在这些调用的中间，python解释器会开始寻找模块，这些模块几乎可以肯定已经被加载并且在内存中。
我们知道这一点，因为我们能够将Sysinternal的进程监视器连接到进程，并观察到进程（被调用的时候）开始围绕一堆目录搜寻，并为某些.py文件find蛋。
显而易见的事情是要看是否pythonsearchpath已被修改，但我们发现情况并非如此。 这正是我们所期望的。 奇怪的是：
这种search行为被触发的场合似乎是随机的，也就是说，它不是每次都发生或者有任何明显的模式。
行为不会影响函数的结果。 无论文件search行为是否被触发，它都返回相同的值。
在J驱动器不包含这种文件夹的机器上，被扫描的文件夹是不存在的（例如J：/ python-eggs）。 自然procmon报告，这产生了一个文件找不到错误。
这一切都非常神秘，所以我不指望有人能够提供一个明确的答案，可能会出错。 我将不胜感激关于如何debugging这个问题的任何build议。
谢谢！
评论的答案
所有正在search的东西都是实际的，已知的Python文件，它们存在于主项目的.egg文件中。 奇怪的是，当他们被搜查的时候，那些特殊的模块已经被导入了。 他们必须记住这个过程才能工作。
是的，这会影响性能，因为有时候这种search行为试图打击networking驱动器。 同样，通过search不可能包含某些模块的鸡蛋，该过程被公司强制的病毒扫描程序中断。 这减慢了通常是无害的瞬间中断。
这是股票蟒2.4.4。 没有修改。
Python程序可以随时导入模块，而不仅仅是在程序加载期间。 尝试搜索您用于import的模块。
如果这不起作用，您可以编写一个导入挂钩来捕获并报告所有尝试的导入。 例如，如果您在其他任何操作之前运行此操作，您将获得每个尝试导入及其源代码的转储。
import sys, traceback class ImportDebugger: def find_module(self, fullname, path=None): print "Attempting to import %s:" % fullname traceback.print_stack() sys.meta_path.insert(0, ImportDebugger())
“可以从许多Excel工作表中调用的Python函数”
而且你不是指责Excel随机运行Python模块？ 为什么不？ 你如何证明Excel的行为正确？