使用以Python编写的配置文件 [英] Using config files written in Python

问题描述

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

I've noticed a few Python packages that use config files written in Python. Apart from the obvious privilege escalation, what are the pros and cons of this approach?

此方法是否有很多优先事项？

Is there much of a precedence for this? Are there any guides as to the best way to implement this?

是否有实现最佳方法的指南？只是要澄清一下：在我的特定用例中，将仅使用由程序员或知道自己在做什么的人。它不是分发给最终用户的软件中的配置文件。

Just to clarify: In my particular use case, this will only be used by programmers or people who know what they're doing. It's not a config file in a piece of software that will be distributed to end users.

推荐答案

我能想到的最好的例子为此是 django settings.py 文件，但我敢肯定还有大量其他示例将Python文件用于

The best example I can think of for this is the django settings.py file, but I'm sure there are tons of other examples for using a Python file for configuration.

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

There are a couple of key advantages for using Python as config file over other solutions, for example:

• 无需解析文件：由于文件已经是Python，因此您无需编写或导入解析器即可从中提取键值对


• 配置设置可以不仅仅是键/值：尽管设置定义自己的类是很愚蠢的，但是您可以使用它们来定义设置的元组，列表或字典提供比其他选项更多的选项和配置。对于django尤其如此，其中设置文件必须适应框架设计人员最初不知道的所有插件。


• 编写配置文件是容易：这是虚假的，但是由于配置是Python文件，因此可以在程序本身的IDE中对其进行编辑和调试。


• 隐式错误检查：：如果您的程序需要一个名为 FILE_NAME 的选项，而该选项不在设置中，则该程序将引发异常。这意味着设置成为强制性的，并且设置的错误处理可以更加明确。这可能是一把双刃剑，但是手动更改配置文件应该适合能够处理异常后果的超级编辑者。


• 易于使用的配置选项和名称空间：一旦进入导入设置，您就可以疯狂地开始调用 settings.UI_COLOR 或 settings.TIMEOUT 。这些内容很清楚，并且使用正确的IDE，跟踪这些设置的位置要比使用平面文件更容易。

• There is no need to parse the file: Since the file is already Python, you don't have to write or import a parser to extract the key value pairs from the file.
• Configuration settings can be more than just key/values: While it would be folly to have settings define their own classes, you can use them to define tuples, lists or dictionaries of settings allowing for more options and configuration than other options. This is especially true with django, where the settings file has to accommodate for all manner of plug-ins that weren't originally known by the framework designers.
• Writing configuration files is easy: This is spurious, but since the configuration is a Python file it can be edited and debugged within the IDE of the program itself.
• Implicit error-checking: If your program requires an option called FILE_NAME and that isn't in the settings the program will throw an exception. This means that settings become mandatory and error handling of the settings can be more explicit. This can be a double edged sword, but manually changing config files should be for power editors who should be able to handle the consequences of exceptions.
• Config options are easily accessed and namespaces: Once you go import settings you can wildly start calling settings.UI_COLOR or settings.TIMEOUT. These are clear, and with the right IDE, tracking where these settings are made becomes easier than with flat files.

但是功能最强大原因： 覆盖，覆盖，覆盖 。这是一种非常高级的情况，可以针对特定的用例，但是在某些地方django鼓励这样做。

But the most powerful reason: Overrides, overrides, overrides. This is quite an advanced situation and can be use-case specific, but one that is encouraged by django in a few places.

您正在构建Web应用程序的图片，那里有开发和生产服务器。它们每个都需要自己的设置，但是其中90％是相同的。在这种情况下，您可以执行以下操作：定义一个涵盖所有开发的配置文件，并将其设置为默认设置（如果更安全），然后覆盖 if 的生产方式，例如：

Picture that you are building a web application, where there is a development and production server. Each of these need their own settings, but 90% of them are the same. In that case you can do things like define a config file that covers all of development and make it (if its safer) the default settings, and then override if its production, like so:

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

if SITE_IS_LIVE:
    import * from production_settings.py

执行 import * from 将导致 production_settings.py 文件中声明的所有设置都将覆盖设置文件中的声明。

Doing an import * from will cause any settings that have been declared in the production_settings.py file to override the declarations in the settings file.

我尚未看到涵盖如何执行此操作的最佳做​​法指南或PEP文档，但是如果您需要一些通用指南，则django settings.py是

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


• 如果您使用Python作为c，则期望奇数数据结构


• 不要尝试创建用于更改设置的界面，这不是简单的文本编辑器。

何时不应该使用这种方法？当您处理需要由新手更改的简单键/值对时用户。 Python配置是高级用户选项，仅 。新手用户将忘记引号或列表的结尾，不一致，会删除他们认为不适用的选项，并且会犯下最讨厌的错误，并且只会混用制表符和空格^仅空格。因为您本质上是在处理代码而不是配置文件，所以所有 都会破坏您的程序。另一方面，编写一个可以通过python文件进行解析以找到合适的选项并更新它们的工具可能比它值得的麻烦更多，并且最好重用现有的模块，例如 ConfigParser

When shouldn't you use this approach? When you are dealing with simple key/value pairs that need to be changed by novice users. Python configs are a power user option only. Novice users will forget to end quotes or lists, not be consistent, will delete options they think don't apply and will commit the unholiest of unholies and will mix tabs and spaces ^{spaces only}. Because you are essentially dealing with code not config files, all off these will break your program. On the otherside, writing a tool that would parse through through a python file to find the appropriate options and update them is probably more trouble than it is worth, and you'd be better of reusing an existing module like ConfigParser

这篇关于使用以Python编写的配置文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！