我认为可能有两个主要原因（哈哈），一个可能规定避免这种模式。
如果您完全控制该应用程序，并且永远不会再有其他入口点或功能的其他用途，并且您确定自己不介意模棱两可，那么我认为模式错误是没有 客观 原因的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.py
import conf
import app
if __name__ == '__main__':
import sys
conf.init(sys.argv[1:])
app.run()
# app.py
import conf
def run():
if conf.DEBUG:
print('debug is on')
请注意使用conf.DEBUG而不是from conf import DEBUG。这种构造意味着您 可以 在程序的生命周期内更改变量，并将更改反映到其他地方（显然，假设单个线程/进程）。
另一个好处是，这是一种相当普遍的模式，因此其他开发人员将很容易认识到它。尽管我避免使用该特定名称，因为它通常是一堆静态对象，而不是运行时参数的命名空间，但它很容易与settings.py各种流行应用程序（例如django）使用的文件进行比较settings.py。例如，上述配置名称空间模块的其他好名字可能是runtime或params。
602392714
清零编程群