python - 使用 Python 编写的配置文件

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




我注意到一些使用 Python 编写的配置文件的 Python 包。除了明显的特权升级之外，这种方法的优缺点是什么？

这有很多优先权吗？是否有任何指南可以说明实现这一点的最佳方法？

澄清一下:在我的特定用例中，这只会由程序员或知道他们在做什么的人使用。它不是将分发给最终用户的软件中的配置文件。

Answer 1

我能想到的最好的例子是 django settings.py 文件，但我确信还有很多其他使用 Python 文件进行配置的示例。

与其他解决方案相比，使用 Python 作为配置文件有几个关键优势，例如:

不需要解析文件:由于文件已经是 Python，因此您不必编写或导入解析器来从文件中提取键值对。

配置设置可以不仅仅是键/值:虽然让设置定义自己的类是愚蠢的，但您可以使用它们来定义设置的元组、列表或字典，从而允许比其他选项更多的选项和配置。对于 django 尤其如此，其中设置文件必须适应框架设计者最初不知道的各种插件。

编写配置文件很容易:这是虚假的，但由于配置是一个 Python 文件，它可以在程序本身的 IDE 中进行编辑和调试。

隐式错误检查:如果您的程序需要一个名为 FILE_NAME 的选项这不在程序会抛出异常的设置中。这意味着设置成为强制性的并且设置的错误处理可以更加明确。这可能是一把双刃剑，但手动更改配置文件应该适用于能够处理异常后果的高级编辑器。

配置选项很容易访问和命名空间:一旦你去import settings你可以疯狂地开始拨打 settings.UI_COLOR或 settings.TIMEOUT .这些很清楚，使用正确的 IDE，跟踪这些设置的位置比使用平面文件更容易。

但最有力的理由: 覆盖，覆盖，覆盖 .这是一种非常高级的情况，可以是特定于用例的，但 django 在一些地方鼓励这种情况。

想象一下您正在构建一个 Web 应用程序，其中有一个开发和生产服务器。这些都需要自己的设置，但其中 90% 是相同的。在这种情况下，你可以做一些事情，比如定义一个涵盖所有开发的配置文件并使其(如果它更安全)成为默认设置，然后覆盖它的生产，像这样:

PORT = 8080
HOSTNAME = "dev.example.com"
COLOR = "0000FF"

if SITE_IS_LIVE:
    import * from production_settings.py

做一个 import * from将导致在 production_settings.py 中声明的任何设置文件以覆盖设置文件中的声明。

我还没有看到涵盖如何执行此操作的最佳实践指南或 PEP 文档，但如果您需要一些通用指南，django settings.py 是一个很好的示例。

使用一致的变量名称，最好是大写，因为它们被理解为设置或常量。

期待奇怪的数据结构，如果您使用 Python 作为配置语言，那么尝试处理所有基本数据类型。

不要尝试制作一个界面来更改设置，这不是一个简单的文本编辑器。

什么时候不应该使用这种方法？ 当您处理需要由新手用户更改的简单键/值对时。 Python 配置仅是高级用户选项。新手用户会忘记结束引号或列表，不一致，会删除他们认为不适用的选项，并且会提交最邪恶的东西，并且只会混合制表符和空格。因为您实际上是在处理代码而不是配置文件，所以所有这些都会破坏您的程序。另一方面，编写一个工具来解析 python 文件以找到合适的选项并更新它们可能比它更麻烦，你最好重用像 ConfigParser 这样的现有模块。