使用不同的配置文件 - 应通过命令行参数做出决定

Question

我有一个脚本，它使用一个名为 config.py 的配置文件。实际上，这是一个配置模块。无论如何：配置模块包含很多参数和字典以及字典列表等。

在今天的脚本中是这样使用的

import config

def main(): 
    myParameter = config.myParameter

现在我有这个脚本的另一个应用场景，它使用了相关的配置（'config_advanced.py'，但是参数和字典有不同的值。

我现在的目标是，选择使用的配置模块的名称作为传递的命令行参数：

myScript.py -configuration config_advanced.py

由于配置模块与主脚本位于同一文件夹中，我想我必须先将传递的配置文件重命名为“config.py”。之后我可以执行import config。否则，如果我使用 `import config_advanced，我将无法使用像

这样的调用

config.myParameter

在主脚本中。

另一种可能是将配置模块放在子文件夹中并保留名称 config.py。传递的命令行参数必须包含子文件夹。

无论哪种方式，我都无法在主文件的顶部执行导入，因为我必须先进行参数解析。这不是技术问题，但有人说这至少是不好的做法。

你怎么看？ 有什么更好的方法来不费吹灰之力地做到这一点？ 非常感谢

---

编辑：
一种可行的解决方案是

import sys fullpath = "d:\\python\\scripts\\projectA\\configurationFiles\\" 
sys.path.append(fullpath) 
config = __import__('config_advanced')

如果没有 syspath，它就不起作用，所以下面的尝试将不起作用：

config = __import__('d:\\python\\scripts\\projectA\\configurationFiles\\config_advanced')
config = __import__('d:\\python\\scripts\\projectA\\configurationFiles\\config_advanced.py')

Answer 1

另一种可能与您在问题中的建议类似，但不需要您将内容隐藏在子文件夹中，是将 config_advanced.py 和 config_plain.py 放在与主脚本相同的文件夹中，然后动态制作config.py 指向您要使用的实际配置文件的链接。

不过，martineau 的建议要简单得多。

OTOH，georg 提出了一个非常有效的观点，尤其是如果这个脚本不只是供您个人使用。虽然使用 Python 本身来处理配置数据既灵活又强大，但它可能有点太强大了。配置数据应该只是是数据，而不是实时可执行代码。如果您在修改配置数据时犯了一个小错误，如果它位于可执行文件中，则可能会造成严重破坏。如果恶意用户接触到它，他们可能造成的损害是无限的。

一个普通的旧数据文件中的错误数据最坏的情况是会导致 ValueError，如果它做了一些你的配置解析代码没有怀疑的奇怪事情。但是实时 Python 文件中的不良数据可能会引发各种令人讨厌的错误。或者更糟糕的是，它可以在完全沉默的情况下做一些坏事……

---

回复你的cmets，这里有一些代码来说明第一点：

#! /usr/bin/env python

import os

config_file = "config.py"

def link_config(mode):
    if os.path.exists(config_file):
        os.remove(config_file)

    config_name = "config_%s.py" % mode
    os.symlink(config_name, config_file)

#.... parse command line to determine config_mode string, then do
link_config(config_mode)

#Now import the newly-linked config file
import config

如果 config_mode == "plain" 上述代码将导致 config_plain.py 被导入为 'config'

如果 config_mode == "advanced" 会导致 config_advanced.py 被导入为 'config'

但正如我之前所说，martineau 的方法要简单得多。而 IIRC，os.symlink 可能无法在非 unix 系统上运行。

...

至于你的第二点，请查看the docs for the json module