在调用ConfigParser.read时,可以传递一个字符串列表作为配置文件的潜在位置,并且该函数返回已成功读取的文件列表。
当加载具有重叠部分/键的多个配置文件时,默认行为是什么?列表中后面的文件是否会覆盖先前已解析的值?整个部分是否被覆盖还是只有冲突的键?
在调用ConfigParser.read时,可以传递一个字符串列表作为配置文件的潜在位置,并且该函数返回已成功读取的文件列表。
当加载具有重叠部分/键的多个配置文件时,默认行为是什么?列表中后面的文件是否会覆盖先前已解析的值?整个部分是否被覆盖还是只有冲突的键?
在测试后,ConfigParser会用每个成功读取的文件中的键值对覆盖之前已经存在的键值对,并且它使用传递给ConfigParser.read方法的文件名列表中的顺序来决定读取文件的顺序。
为了进一步说明,举个例子。
我可以创建以下两个文件:
config1.ini
# ** config1.ini **
[shared]
prop_uniue1 = 1
prop_shared = 10
[unique1]
test_unique = 101
还有config2.ini
:
# ** config2.ini **
[shared]
prop_uniue2 = 2
prop_shared = 14
[unique2]
test_unique = 102
然后,如果我运行以下内容,我可以看到配置如何更新(输出显示为相应的打印语句之后的注释):
那么如果我运行以下内容,我可以看到配置如何更新(输出在各自的打印语句后作为注释显示):
import ConfigParser
config = ConfigParser.ConfigParser()
config.read(['config1.ini', 'config2.ini'])
print config.sections() # ['shared', 'unique1', 'unique2']
print config.get("shared", "prop_uniue1") # 1
print config.get("shared", "prop_shared") # 14
print config.get("unique1", "test_unique") # 101
print config.get("shared", "prop_uniue2") # 2
print config.get("unique2", "test_unique") # 102
综上所述,可以得出以下结论:
ConfigParser
的文献都完全忽略了使用多个文件进行配置设置的能力。这与.NET Core App
设置处理方式非常相似。他们更进一步,允许配置值从环境变量和其他自定义来源中获取。想象一下一个主要的settings.json
文件,然后是特定于环境的设置文件,比如settings-dev.json
或settings-uat.json
或settings-prod.json
,通过确定环境变量的值来动态加载。 - undefined