我有2个不同的文件: 一种是从CI构建: build.py
ABC_ACTIVATE = False
def activate_abc():
global ABC_ACTIVATE
ABC_ACTIVATE = True
# Maybe some more very long code.
一个来自定制 custom.py
from build import *
activate_abc()
print ABC_ACTIVATE
这个想法是通过1个函数(而不是很长的代码)为每个环境自定义激活。但这是行不通的,因为ABC_ACTIVATE
始终是False
。
似乎全局变量不能在另一个文件中接收相同的上下文。可能有一些“周期性依赖”问题。
所以我的问题是:有没有更好的结构解决方案?这个想法仍然可以通过函数来激活,而customize.py将是apache构建的最后一个设置。
答案 0 :(得分:1)
全局似乎无法在其他文件中接收相同的上下文。也许是一些“周期性依赖”问题。
导入后,ABC_ACTIVATE
在该脚本的上下文中变为本地。因此,对build.py
中的变量进行更改不会反映在您的其他模块中。
所以我的问题是:有没有更好的结构解决方案?
您可以做的一件事是创建一个中介方法,该方法在您的ABC_ACTIVATE
中返回build.py
布尔值。
def is_abc_activated():
return ABC_ACTIVATE
然后将其导入,
from build import activate_abc, is_abc_activated
print(is_abc_activated())
activate_abc()
print(is_abc_activated())
>>>>
False
True
基本上,这将删除您的无条件导入from build import *
,这在Python中是一种反习惯用法。另外,由于访问ABC_ACTIVATE
可能会使您对您正在执行的操作感到困惑,因此它将提高可读性。
答案 1 :(得分:0)
经过一番讨论,我的朋友找到了一个相当不错的解决方案:
build.py:
ABC_ACTIVATE = False
def activate_abc(other_context):
other_context.ABC_ACTIVATE = True
在custom.py中:
from build import *
activate_abc(sys.modules[__name__])
print ABC_ACTIVATE
现在可以使用。
答案 2 :(得分:-1)
对于build.py中的函数定义来说,语法似乎不正确:第一个{应该是:,第二个}则不需要,因为python使用缩进来表示代码块
ACTIVATE = False
def activate():
global ACTIVATE
ACTIVATE = True
也许你也可以做...
import build
build.activate()
...就像build.py中的脚本使用同一文件中的变量,而您导入的变量是不同的变量一样,因为它被导入到当前文件的命名空间中。