Python：'import *‘vs execfile

Question

在我的一些Django应用程序中，我使用settings_local.py文件来覆盖在不同环境(例如开发、测试和生产)上不同的设置。我最初使用以下代码将其内容包含在settings.py中

try:
    from settings_local import *
except ImportError:
    sys.stderr.write("The settings_local.py file is missing.\n")
    DEBUG=False

我最近找到了execfile函数，并切换到如下所示：

try:
    execfile(path.join(PROJECT_ROOT, "settings_local.py"))
except IOError:
    sys.stderr.write("The settings_local.py file is missing.\n"
    DEBUG=False

这两种方法都能按预期工作，但我想知道我是否遗漏了任何陷阱，以及通常哪种方法更受推荐以及原因。

Answer 1

每次对设置文件求值时，使用execfile函数都会导致对Python源文件(.py)求值。您每次都在执行Python解析器。使用import不一定能做到这一点(可以使用.pyc文件)。通常，在Python (至少是cPython)中第一次运行项目时，它会被编译成字节码，并且不会再次重新编译。你打破了这一点。这不一定是问题，但您应该意识到这一点。

使用execfile还会导致在settings.py文件的模块范围内重新评估settings_local.py文件中的所有导入。使用import *将包含settings_local.py模块作用域中的所有项。净效果是相同的( settings_local.py模块作用域中包含的所有项都包含在settings.py中)，但方法不同。

最后，模块作为模块执行而不是包含在其中是很正常的。代码包含诸如os.path.dirname(__file__)之类的内容是合理的。如果任何代码确实使用了它，您可能会混淆它，因为代码将不再在作者可能合理地预期的模块中执行。

根据我的经验，人们使用import而不是execfile。Django在很大程度上是“约定优于配置”。遵循惯例。

Answer 2

另一个不同之处是: execfile获取上下文字典；默认情况下是全局上下文或指定的字典。这可能会导致一些奇怪的事情

dont_do_this.py

# Probably not a good thing to do
z=x+1  # an expression that involves an un-defined field

显然，

from dont_do_this import *

失败。

然而，

d={'x':1}
execfile( 'dont_do_this.py', d )

是OK的，结果是d=={'x':1, 'z':2}

请注意，

x=1
execfile( 'dont_do_this.py' )

是OK的，并导致变量z被添加到全局变量中。

Answer 3

第一个版本(from settings_local import *)是每个人都期望看到的。它还可以让代码分析员找到模块。