在编写配置文件时使用 ConfigParser 而不是常规的 python.py 文件有什么好处？
我使用 ConfigParser 模块编写配置文件已经有一段时间了。然而，最近我突然想到一个想法：为什么不直接使用纯 Python 呢？以这个配置文件为例：
[parameters]
# Host
host = stackoverflow.com
port = 22
要将这些值读入我的代码，我会这样做
import ConfigParser
config = ConfigParser.SafeConfigParser()
config.read('host.cfg')
host = config.get('parameters', 'host')
port = config.get('parameters', 'port')
另一方面，如果我有一个像这样的配置文件：
# Host
host = 'stackoverflow.com'
port = 22
在我的主代码中，我可以这样做：
from host_cfg import *
那么使用 ConfigParser 模块我能得到什么？每种方法的优点和缺点是什么？
I have been using the ConfigParser module to write configuration files for some time. However, a thought recently struck me; why not just use pure Python instead? Take this example configuration file:
[parameters]
# Host
host = stackoverflow.com
port = 22
To read these values into my code, I do
import ConfigParser
config = ConfigParser.SafeConfigParser()
config.read('host.cfg')
host = config.get('parameters', 'host')
port = config.get('parameters', 'port')
On the other hand, if I had a config file like this:
# Host
host = 'stackoverflow.com'
port = 22
In my main code, I could do this:
from host_cfg import *
So what do I gain from using the ConfigParser module? What are the pros and cons of each approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与 Windows .ini 文件兼容。让一些人感到高兴。
ConfigParser 的语法有限，一些相对简单的事情变得非常做作。查看
日志记录示例。Python 语法更简单，更容易使用。不存在安全漏洞，因为当他们可以简单地破解您的源代码时，没有人会浪费时间破解配置文件。事实上，他们可以破解大部分内置 Python 库。就此而言，他们可以自行编写 Python 解释器。
当应用程序源代码中的其他地方存在非常非常容易的漏洞时，没有人会浪费时间破解配置文件。
Compatibility with Windows .ini files. Makes some people happy.
ConfigParser has limited syntax and some relatively simple things get very contrived. Look at
loggingfor examples.Python syntax is simpler and much easier to work with. There's no security hole, since no one will waste time hacking a config file when they can simply hack your source code. Indeed, they can hack most of the built-in Python library. For that matter, they could cook the Python interpreter itself.
No one wastes time hacking config files when there are much, much easier exploits elsewhere in your application source code.
ConfigParser 解析简单、平面的配置数据。导入 python 模块会运行代码。对于配置文件，您需要数据，而不是代码。案件结案。
好吧，更详细的是：代码可以做各种各样的事情，包括更容易破坏 - 特别是当由非程序员编辑时（尝试向
.inimodders 解释，他们必须使用匹配的引号并转义事物。 ..) - 或导致命名空间与应用程序的其他部分发生冲突（特别是如果您import *）。另请参阅最小功率规则。ConfigParser parses simple, flat configuration data. Importing a python module runs code. For configuration files, you want data, not code. Case closed.
Okay, more detailed: Code can do all kinds of things, including breaking more easily - especially when edited by non-programmers (try explaining
.inimodders that they e.g. have to use matched quotes and escape things...) - or cause namespace conflicts with other parts of your application (especially if youimport *). Also see the rule of Least Power.Python 文件方法的一个潜在“缺点”是您的用户可以将任意代码放入将在您的应用程序上下文中执行的文件中。正如 S. Lott 在这个答案的评论中指出的那样（当我的警告更加有力时），这通常不是问题，因为用户（或黑客）通常可以访问您的整个源代码，并且可以进行任何所需的更改。
但是，我当然可以想象这种方法可能会导致新的安全漏洞的情况，例如当主脚本文件只能由系统管理员写入并且每用户配置文件是最终用户唯一可编辑的文件时。除非你确定你的代码永远不会在这样的环境中运行，否则我不会推荐 Python 模块方法。 “不执行用户提供给您的代码”被广泛认为是最佳实践是有充分理由的。
执行配置文件也会导致处理错误出现问题。如果用户引入了语法错误，您将希望捕获它，并且可以通过在
import周围抛出try来轻松实现此目的，但错误后不会出现任何内容被执行。在配置文件中，通常解析将继续下一行，因此用户最多会错过一个设置，而不是（比如说）一半。有多种方法可以使 Python 模块更像配置文件（例如，您可以将文件作为文本读取，并每行执行 exec() ），但如果您必须做任何工作，使用 ConfigParser 变得更容易。尽管如此，如果您仍然想在配置文件中使用 Python 语法，则可以使用
ast模块（请参阅函数literal_eval()）。A potential "con" of the Python file approach is that your user can put arbitrary code in the file that will be executed in your application's context. As S. Lott points out in the comments to this answer (when I was somewhat more forceful in my warning), this is usually not an issue because the user (or a hacker) will usually have access to your entire source code anyway and can make any desired changes.
However, I can certainly imagine situations in which the approach could result in a new security hole, such as when the main script files are writable only by the system administrator and the per-user config file is the only file editable by the end user. Unless you are certain that your code will never run in such an environment, I would not recommend the Python module approach. There are good reasons that "don't execute code given to you by users" is widely considered a best practice.
Executing the config file also makes handling errors problematic. If the user introduces a syntax error, you will want to trap it, and you can do so easily by throwing a
tryaround yourimport, but nothing after the error will be executed. In a config file, usually parsing will continue with the next line, so the user will miss at most one setting instead of (say) half of them. There are ways to make a Python module work more like a config file (you could read the file as text andexec()each line, for example) but if you have to do any work at all, it becomes easier to useConfigParser.If, despite all this, you still want to use Python syntax in your config file, you could use the
astmodule (see functionliteral_eval()).