我认为可能有两个主要原因（哈哈），一个可能规定避免这种模式。
- 它混淆了您要导入的变量的来源。
- 如果您的程序有多个入口点，它将中断（或至少很难维护）。想象一下，如果有人（很可能是您）想要将功能的某些子集提取到一个独立的库中，他们将不得不删除或重新定义这些孤立的引用中的每个引用，以使其在您的应用程序之外可用。
如果您完全控制该应用程序，并且永远不会再有其他入口点或功能的其他用途，并且您确定自己不介意模棱两可，那么我认为模式错误是没有 客观 原因的
from__main__ import foo。我个人不喜欢它，但是再次，基本上是出于上述两个原因。
我认为，更健壮/对开发人员友好的解决方案可能是这样的，它创建了一个专门用于保存这些超全局变量的特殊模块。然后，您可以导入模块并
module.VAR在需要设置时参考。本质上，只需创建一个特殊的模块命名空间即可在其中存储超全局运行时配置。
# conf.py (for example)# This module holds all the "super-global" stuff.def init(args): global DEBUG DEBUG = '--debug' in args # set up other global vars here.
然后，您将更像这样使用它：
# main.pyimport confimport appif __name__ == '__main__': import sys conf.init(sys.argv[1:]) app.run()
# app.pyimport confdef run(): if conf.DEBUG: print('debug is on')请注意使用
conf.DEBUG而不是
from conf import DEBUG。这种构造意味着您 可以
在程序的生命周期内更改变量，并将更改反映到其他地方（显然，假设单个线程/进程）。
另一个好处是，这是一种相当普遍的模式，因此其他开发人员将很容易认识到它。尽管我避免使用该特定名称，因为它通常是一堆静态对象，而不是运行时参数的命名空间，但它很容易与
settings.py各种流行应用程序（例如
django）使用的文件进行比较
settings.py。例如，上述配置名称空间模块的其他好名字可能是
runtime或
params。
