使用Python文件作为配置文件有多么糟糕的主意？

#1 楼

乍一看，使用脚本语言代替配置文件看起来很不错：您拥有该语言的全部功能，可以简单地对其进行eval()或import的处理。实际上，有一些陷阱：


它是一种编程语言，需要学习。要编辑配置，您需要充分了解此语言。配置文件通常具有更简单的格式，更容易出错。
这是一种编程语言，这意味着配置可能很难调试。使用普通的配置文件，您可以查看它并查看为每个属性提供了哪些值。使用脚本，您可能需要先执行它才能查看值。
这是一种编程语言，这使得很难在配置和实际程序之间保持清晰的分隔。有时您确实想要这种可扩展性，但是到那时，您可能正在寻找一个真正的插件系统。
它是一种编程语言，这意味着config可以执行该编程语言可以完成的任何工作。因此，要么您使用的是沙箱解决方案，否定了该语言的大部分灵活性，要么是您高度信任config作者。

因此，如果听众喜欢使用脚本进行配置您的工具是开发人员，例如Sphinx配置或Python项目中的setup.py。其他具有可执行配置的程序是Bash这样的shell，以及Vim这样的编辑器。

如果配置包含许多条件部分，或者提供回调/插件，则必须使用编程语言进行配置。直接使用脚本而不是eval（）-某些配置字段通常更易于调试（请考虑堆栈跟踪和行号！）。

如果您的配置如此重复，以至于您正在编写脚本以自动生成配置，那么直接使用编程语言也可能是一个好主意。但是，也许更好的配置数据模型可以消除对此类显式配置的需求？例如，如果配置文件可以包含稍后扩展的占位符，则可能会有所帮助。有时会看到的另一个功能是，具有不同优先级的多个配置文件可以相互覆盖，尽管这会带来一些自身的问题。

在大多数情况下，INI文件，Java属性文件或YAML文档更适合配置。对于复杂的数据模型，XML也可能适用。正如您已经指出的那样，尽管JSON是一种很好的数据交换格式，但它在某些方面使它不适合用作人类可编辑的配置文件。

#2 楼

对amon的答案中的所有内容+1。我想添加以下内容：

您将第一次使用Python代码作为配置语言时感到遗憾，因为您希望从用另一种语言编写的代码中导入相同的配置。例如，如果代码是项目的一部分，并且是用C ++或Ruby编写的，或者需要其他配置来提取配置，则需要将Python解释器链接为一个库，或在Python协同进程中解析配置，笨拙，困难或高开销。

今天导入此配置的所有代码都可能是用Python编写的，您也许认为明天也是如此，但是您知道吗肯定吗？

您说过，如果可以的话，请在配置中谨慎使用逻辑（除静态数据结构以外的任何方式），这很好，但是如果有任何一点，您将发现将来很难撤消它，因此您可以返回到声明性配置文件。

编辑记录：好几个人已对该答案发表评论，表明该项目的可能性或可​​能性不大会成功地完全用另一种语言重写。可以公平地说，可能很少看到完整的向后兼容重写。实际上，我想到的是同一项目的零碎片段（需要访问相同的配置）是以不同的语言编写的。例如，在C ++中提供堆栈以提高速度，在Python中提供批处理数据库清理，一些shell脚本作为胶水。因此，请为这种情况花点时间：)

#3 楼

其他答案已经非常好，我将在一些项目中介绍我在现实世界中的使用经验。 br />

如果您使用的是Python程序，则解析起来很容易（eval）;它甚至可以自动处理更复杂的数据类型（在我们的程序中，我们有几何点和变换，可以通过repr / eval进行正确的转储/加载）；
只需几行即可创建“假配置”代码是微不足道的；
与JSON相比，您拥有更好的结构，并且IMO的语法也更好（jeez甚至仅具有注释并且不必在字典键周围加上双引号是可读性的一个重大胜利）。

缺点


恶意用户可以执行您的主程序可以执行的任何操作；我认为问题不大，因为通常，如果用户可以修改配置文件，则他/她已经可以执行应用程序可以执行的任何操作；
如果您不再使用Python程序，则现在可以一个问题。尽管我们的几个配置文件保留了其原始应用程序的私有性，但其中一个特别用于存储供多个不同程序使用的信息，其中大多数程序当前都在C ++中，而这些程序现在都有一个共同使用的解析器，用于定义不明确的小程序。 Python repr的子集。这显然是一件坏事。
即使您的程序仍使用Python，也可以更改Python版本。假设您的应用是从Python 2开始的；经过大量测试后，您设法将其迁移到Python 3-不幸的是，您并未真正测试所有代码-您所有的配置文件都位于客户计算机上，是为Python 2编写的，而您没有真的没有控制权。除非您愿意捆绑/调用Python 2解释器，否则您甚至无法提供“兼容模式”来读取旧的配置文件（通常是针对文件格式进行的操作）！

即使您使用的是Python，也无法通过代码修改配置文件，因为……好吧，修改代码根本不是一件容易的事，尤其是语法丰富且不在LISP或类似语言中的代码。我们的一个程序有一个配置文件，它是Python，最初是手工编写的，但后来证明通过软件进行操作将很有用（一个特定的设置是一系列的事情，使用GUI可以更轻松地对其进行重新排序）。这是一个大问题，因为：


即使只是执行解析→AST→重写往返也不是一件容易的事（您会注意到，提议的解决方案中有一半后来被标记为“过时” ，不要使用它，在所有情况下都无法正常工作”）；
即使它们有效，AST也是如此低级；您通常对操纵文件中执行的计算结果感兴趣，而不是对其执行的步骤感兴趣；
这使我们想到了一个简单的事实，即您不能仅编辑感兴趣的值，因为它们可能由一些您无法通过代码理解/操作的复杂计算生成。

与JSON，INI或（禁止上帝！）XML进行比较，可以随时编辑和编写内存中表示形式返回或者不丢失数据（XML，大多数DOM解析器可以在文本节点和注释节点中保留空白），或者至少丢失某些格式（JSON，其中格式本身所允许的内容比读取的原始数据多得多） ）。



因此，像往常一样，没有明确的解决方案；我目前在此问题上的政策是：



如果配置文件是：


对于Python应用程序肯定是私有的，它-就像其他人一样，永远不会尝试读取它；
手写的；
来自受信任的来源；
使用目标应用程序数据类型确实是一种溢价；

Python文件可能是一个有效的主意；


如果相反，则：


可能有其他应用程序从中读取；
有可能该文件可能由应用程序编辑，甚至可能是我的应用程序本身；
由不受信任的来源提供。 br />
“仅数据”格式可能是一个更好的主意。


请注意，不必做出单一选择-我最近编写了一个应用程序方法。我有一个几乎没有修改过的文件，它具有首次设置，手写设置，这些设置具有获得不错的Python奖金的优势，还有一个用于从UI编辑的用于配置的JSON文件。

#4 楼

主要问题是：您是否希望配置文件使用某种图灵完整的语言（例如Python）？如果您确实希望这样做，则还可以考虑嵌入其他（如Turning完整的）脚本语言，例如Guile或Lua（因为使用或嵌入比Python更“简单”；请阅读“扩展和嵌入Python）。我将不做进一步讨论（因为其他答案，例如Amon进行了深入讨论），但是请注意，在应用程序中嵌入脚本语言是主要的体系结构选择，因此应尽早考虑。我真的不建议以后再做选择！

通过“脚本”可配置的程序的一个众所周知的例子是GNU emacs编辑器（或专有领域中的AutoCAD）；它可能是一个可配置的程序。因此请注意，如果您接受脚本编写，则某些用户最终会广泛使用该工具（可能会滥用），并制作成千上万行的脚本；因此，选择足够好的脚本语言非常重要。

但是（至少在POSIX系统上），您可能认为方便在初始化时动态计算配置“文件”（当然） ，将合理配置的负担留给了系统管理员或用户；实际上，它是来自某些文件或命令的配置文本）。为此，您可以简单地采用（并记录下来）约定以配置文件路径开头，例如一个!或一个|实际上是一个您将被视为管道的shell命令。这使您的用户可以选择使用他最熟悉的“预处理器”或“脚本语言”。

（如果您接受动态计算的配置，则需要让用户信任安全问题）

因此，在您的初始化代码中，您的main将（例如）接受一些--config参数confarg并从中获取一些FILE*configf;。如果该参数以!开头（即(confarg[0]=='!') ....），则可以使用configf = popen(confarg+1, "r");并使用pclose(configf);关闭该管道。否则，您将使用configf=fopen(confarg, "r");并使用fclose(configf);关闭该文件（不要忘记进行错误检查）。参见pipe（7），popen（3），fopen（3）。对于使用Python编码的应用程序，请阅读有关os.popen的信息，等等...

（也为想要传递名为!foo.config的配置文件以传递./!foo.config来绕过上述popen技巧的怪异用户提供文档）<顺便说一句，顺便说一句，这只是一种方便（避免要求高级用户例如编写一些Shell脚本来生成配置文件）。如果用户要报告任何错误，则应将生成的配置文件发送给您。

请注意，您还可以在初始化时使用和加载插件的能力来设计应用程序，例如使用dlopen（3）（并且您需要信任该插件的用户）。同样，这是一个非常重要的体系结构决策（并且您需要定义并提供有关这些插件和应用程序的相当稳定的API和约定）。

对于以脚本语言（如Python）编码的应用程序，也可以接受一些用于eval或exec或类似基元的程序参数。同样，（高级）用户也要关心安全问题。

关于配置文件的文本格式（无论是否生成），我认为您最需要将其文档化（并且某些特定格式的选择并不那么重要；但是我建议您让用户能够输入里面有一些跳过的注释）。您可以使用JSON（最好是使用某些JSON解析器通过通常的//接受和跳过注释，直到eol或/* ... */ ...），YAML，XML，INI或您自己的东西。解析配置文件相当容易（并且您会发现许多与此任务相关的库）。

#5 楼

除了amon的答案，您是否考虑过替代方案？ JSON可能超出了您的需要，但是由于上述原因，Python文件将来可能会给您带来问题。

但是Python已经具有用于非常简单的配置语言的配置解析器，可以满足所有要求您的需求。 ConfigParser模块实现了一种简单的配置语言。

#6 楼

我使用某些知名软件工作了很长时间，该软件的配置文件用TCL编写，因此这个想法并不新鲜。这非常有效，因为不了解该语言的用户仍然可以使用单个set name value语句来编写/编辑简单的配置文件，而更高级的用户和开发人员可以使用此技巧获得复杂的技巧。

我不要以为“配置文件可能难以调试”是一个有效的问题。只要您的应用程序不强迫用户编写脚本，您的用户就可以始终在其配置文件中使用简单的分配，与JSON或XML相比，这几乎很难解决。

重写该配置是一个问题，尽管它没有看起来那么糟糕。更新任意代码是不可能的，但是从文件中加载配置，更改并保存回去是可以的。基本上，如果您在非只读的配置文件中执行一些脚本编写，则一旦保存，您将最终得到等效的set name value语句列表。一个很好的暗示，即将发生的是在文件开头的“请勿编辑”注释。

要考虑的一件事是，基于简单正则表达式的配置文件无法可靠地读取您的配置文件工具，例如sed，但据我所知，当前的JSON文件已经不是这种情况了，因此不会有太多损失。配置文件。

#7 楼

除了这里其他所有好的答案的所有有效点（哇，他们甚至提到了图灵完备的概念），实际上还有一些可靠的实际原因，即使在使用Python时，也不使用Python文件作为配置-


Python源文件中的设置从技术上讲是可执行源代码的一部分，而不是只读数据文件。如果走这条路，通常会执行import config，因为这种“便利”可能是人们首先使用Python文件作为配置的主要原因之一。现在，您倾向于将该config.py提交到您的存储库中，否则最终用户在首次运行程序时会遇到一个令人困惑的ImportError。
假设您实际上将该config.py提交到了存储库中，现在您的团队成员可能在不同的环境中具有不同的设置。想像一下，有一天某位成员不小心将其本地配置文件提交到了仓库中。
最后但并非最不重要的是，您的项目可能在配置文件中包含密码。 （这本身是值得商de的做法，但是还是会发生这种情况。）而且，如果您的配置文件存在于回购中，则您可能会将凭证提交到公共回购中。

现在，仅使用数据配置文件（例如通用JSON格式）可以避免上述所有3个问题，因为您可以合理地要求用户提供自己的config.json并将其输入到程序中。

PS ：JSON确实有很多限制。 OP提到的2个局限性可以通过一些创造性来解决。


如何将注释放入JSON文件（正确）

我通常有一个占位符，以绕过尾随逗号规则。像这样：

{
    "foo": 123,
    "bar": 456,
    "_placeholder_": "all other lines in this file can now contain trailing comma"
}