ConfigParser枪战,初步进入 [英] ConfigParser shootout, preliminary entry

查看:51
本文介绍了ConfigParser枪战,初步进入的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

几个星期前,有人建议在Python-Dev上考虑更换ConfigParser模块,并且我们应该持有一个

< ;>
;枪战" (即要求实施,看看我们得到了什么)。


从那以后我一直在玩这个...而不是解析部分(

到目前为止我完全忽略了)但程序员界面。需要

作为存储信息的经过深思熟虑的数据模型,并且用户需要非常容易使用,但不是这样神奇"它变得很难理解。


我把我认为可能是我最好的建议放在一起。它基于ini配置文件和java .property文件的超集基于

。有一个

方便的访问机制(config.my_app.some_value)以及更多

一般方法(config.values [''my_app.serviceByPort 0.80 '']")。我有点b $ b试图考虑像unicode这样的问题(我允许相当宽松地混合

unicode和str),以及单元测试(" ... call config.clear_all( )在使用配置模块的任何单元测试的

tearDown()方法中......。我有点b $ b甚至仔细考虑什么离开OUT(转换为非字符串数据

类型,插值,类似的东西)。


我认为我现在可以真正使用来自

其他人的一些输入。所以我想邀请别人来审查我的设计,然后将您的

建议发送给我。我不希望这是一个*有用的*模块(它还没有
尚未解析文件!),但它似乎是一个很好的阶段,可以要求

反馈。我附加了两个文件,config.py和configTest.py,他们还可以从这些网址获得


http://www.mcherm.com/publish/2004-10-17/config.py
http:// www.mcherm.com/publish/2004-10-17/configTest.py

提前感谢您对此进行审核。


- Michael Chermside

解决方案

Michael Chermside写道:

几周之前,有人建议在Python-Dev上考虑更换ConfigParser模块并且我们应该持有一个枪战模块。 (即要求实施,看看我们得到了什么)。

从那以后我一直在玩这个...而不是解析部分(到目前为止我完全忽略了) )但程序员界面。需要对存储的信息进行深思熟虑的数据模型,并且用户界面需要非常易于使用,但不是那么神奇。它变得难以理解。

我把我认为可能是我最好的建议放在一起。它基于ini配置文件和java .property文件的超集。有一个方便的访问机制(config.my_app.some_value)以及更多
一般方法(config.values [''my_app.serviceByPort.80'']") 。我已经尝试考虑像unicode这样的问题(我允许相当宽松地混合
unicode和str),以及单元测试(&...在
tearDown中调用config.clear_all()) ()使用配置模块的任何单元测试的方法...。我甚至仔细考虑了什么离开OUT(转换为非字符串数据类型,插值,类似的东西)。

我认为我现在在我可以真正使用
其他人的一些意见。所以我想邀请别人来审查我的设计并向我发送你的建议。我不希望这是一个*有用的*模块(它还没有解析文件!),但它似乎是一个很好的阶段,可以请求
反馈。我附加了两个文件,config.py和configTest.py,它们也可以从这些网址获得:

http://www.mcherm.com/publish/2004-10-17/config.py
http://www.mcherm。 com / publish / 2004-10-17 / configTest.py

提前感谢您对此进行审核。

- Michael Chermside




我怀疑它是否符合你对此事的看法,但前段时间我写了并发布了我自己发明的这种生物:

https://www.tundraware.com/Software/tconfpy/


-

-------------------------- --------------------------------------------------

Tim Daneliuk tu **** @ tundraware.com

PGP密钥:
http://www.tundraware.com/PGP/


来自docs:

"配置模块可以读取Microsoft的ini文件格式,java的属性文件格式或其自己的python配置格式的配置文件 - 这些
甚至可以混合。


对我而言,这听起来并不吸引人。人们可能只是结束了对实际文件格式的混淆。

所有这些格式都非常简单,只支持它们所有

使用更复杂。

"只要路径的组件是有效的Python标识符,
就有更方便的属性语法:"




这意味着某些功能只能在参数

名称是有效的python标识符时使用,对吗?当我这样说的时候,

它的吸引力有点小。


Istvan。


配置文件读取是一个区域,其中python被很好地服务,并且

各种选项。

对于纯粹的使用简单,你不能击败我的ConfigObj。它读取

文件并将值显示为字典(通过关键字

课程键入)。它也支持编写hte文件。使用属性名称使用

的麻烦在于你会遇到关键字

的问题 - 例如''print''和''pass''。 />

当然是强制性网址
http://www.voidspace.org.uk/atlantibots/configobj.html


问候,


Fuzzyman

http://www.voidpace .org.uk / atlantibots / pythonutils.html

Michael Chermside< mc **** @ mcherm.com>在消息新闻中写道:< ma ************************************** @ pyt hon。 org> ...

几个星期前,有人建议在Python-Dev上考虑更换ConfigParser模块并且我们应该持有一个
枪战 (即要求实施,看看我们得到了什么)。

从那以后我一直在玩这个...而不是解析部分(到目前为止我完全忽略了) )但程序员界面。需要对存储的信息进行深思熟虑的数据模型,并且用户界面需要非常易于使用,但不是那么神奇。它变得难以理解。

我把我认为可能是我最好的建议放在一起。它基于ini配置文件和java .property文件的超集。有一个方便的访问机制(config.my_app.some_value)以及更多
一般方法(config.values [''my_app.serviceByPort.80'']") 。我已经尝试考虑像unicode这样的问题(我允许相当宽松地混合
unicode和str),以及单元测试(&...在
tearDown中调用config.clear_all()) ()使用配置模块的任何单元测试的方法...。我甚至仔细考虑了什么离开OUT(转换为非字符串数据类型,插值,类似的东西)。

我认为我现在在我可以真正使用
其他人的一些意见。所以我想邀请别人来审查我的设计并向我发送你的建议。我不希望这是一个*有用的*模块(它还没有解析文件!),但它似乎是一个很好的阶段,可以请求
反馈。我附加了两个文件,config.py和configTest.py,它们也可以从这些网址获得:

http://www.mcherm.com/publish/2004-10-17/config.py
http://www.mcherm。 com / publish / 2004-10-17 / configTest.py

提前感谢您对此进行审核。

- Michael Chermside



A few weeks ago, the suggestion was made on Python-Dev that it might be time
to consider replacing the ConfigParser module and that we should hold a
"shootout" (ie ask for implementations and see what we get).

Since then I''ve been playing around with this... not the parsing part (which
so far I have completely ignored) but the programmer interface. There needs
to be a well-thought-out data model for the information stored, and the user
interface needs to be very easy to use, yet not so "magical" that it becomes
difficult to understand.

I have put together what I think is probably my best proposal. It is based
on a superset of ini config files and java .property files. There is a
convenient access mechanism ("config.my_app.some_value") as well as more
general approaches ("config.values[''my_app.serviceByPort.80'']"). I have
tried to consider issues like unicode (I permit fairly lenient mixing of
unicode and str), and unit testing ("... call config.clear_all() in the
tearDown() method of any unittests that use the config module..."). I have
even considered carefully what to leave OUT (converting to non-string data
types, interpolating values, things like that).

I think that I am now at the point where I could really use some input from
others. So I''d like to invite people to review my design and send me your
suggestions. I''m not expecting this as a *useful* module yet (it doesn''t
yet parse files!), but it seemed like a good stage at which to ask for
feedback. I''m attaching two files, config.py and configTest.py, and they
are also available from these urls:

http://www.mcherm.com/publish/2004-10-17/config.py
http://www.mcherm.com/publish/2004-10-17/configTest.py

Thanks in advance for reviewing this.

-- Michael Chermside

解决方案

Michael Chermside wrote:

A few weeks ago, the suggestion was made on Python-Dev that it might be time
to consider replacing the ConfigParser module and that we should hold a
"shootout" (ie ask for implementations and see what we get).

Since then I''ve been playing around with this... not the parsing part (which
so far I have completely ignored) but the programmer interface. There needs
to be a well-thought-out data model for the information stored, and the user
interface needs to be very easy to use, yet not so "magical" that it becomes
difficult to understand.

I have put together what I think is probably my best proposal. It is based
on a superset of ini config files and java .property files. There is a
convenient access mechanism ("config.my_app.some_value") as well as more
general approaches ("config.values[''my_app.serviceByPort.80'']"). I have
tried to consider issues like unicode (I permit fairly lenient mixing of
unicode and str), and unit testing ("... call config.clear_all() in the
tearDown() method of any unittests that use the config module..."). I have
even considered carefully what to leave OUT (converting to non-string data
types, interpolating values, things like that).

I think that I am now at the point where I could really use some input from
others. So I''d like to invite people to review my design and send me your
suggestions. I''m not expecting this as a *useful* module yet (it doesn''t
yet parse files!), but it seemed like a good stage at which to ask for
feedback. I''m attaching two files, config.py and configTest.py, and they
are also available from these urls:

http://www.mcherm.com/publish/2004-10-17/config.py
http://www.mcherm.com/publish/2004-10-17/configTest.py

Thanks in advance for reviewing this.

-- Michael Chermside



I doubt it conforms to your thinking on the matter, but some time ago I
wrote and released such a creature of my own invention:

https://www.tundraware.com/Software/tconfpy/

--
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/


From the docs:

"The config module can read config files in Microsoft''s ini file format,
java''s properties file format, or its own python config format -- these
can even be mixed."
To me this does not sound appealing. People might just end
up being confused of what the actual file format is.
All these formats are so simple that supporting them all
only makes the usage more complicated.
"as long as the components of the path are valid Python identifiers,
there is a more convenient attribute syntax available:"



This means that some features can only be used if the parameter
names are valid python identifiers, right? When I put it that way,
it is a bit less attractive.

Istvan.


Config file reading is an area where python is ''well served'' with
various options.
For sheer simplicty of use you can''t beat my ConfigObj. It reads the
file and presents the values as a dictionary (keyed by keyword of
course). It supports writing hte file as well. The trouble with with
using attribute names is that you will have problems with keywords
that are reserved - like ''print'' and ''pass''.

Of course the obligatory URL
http://www.voidspace.org.uk/atlantibots/configobj.html

Regards,

Fuzzyman

http://www.voidpace.org.uk/atlantibots/pythonutils.html

Michael Chermside <mc****@mcherm.com> wrote in message news:<ma**************************************@pyt hon.org>...

A few weeks ago, the suggestion was made on Python-Dev that it might be time
to consider replacing the ConfigParser module and that we should hold a
"shootout" (ie ask for implementations and see what we get).

Since then I''ve been playing around with this... not the parsing part (which
so far I have completely ignored) but the programmer interface. There needs
to be a well-thought-out data model for the information stored, and the user
interface needs to be very easy to use, yet not so "magical" that it becomes
difficult to understand.

I have put together what I think is probably my best proposal. It is based
on a superset of ini config files and java .property files. There is a
convenient access mechanism ("config.my_app.some_value") as well as more
general approaches ("config.values[''my_app.serviceByPort.80'']"). I have
tried to consider issues like unicode (I permit fairly lenient mixing of
unicode and str), and unit testing ("... call config.clear_all() in the
tearDown() method of any unittests that use the config module..."). I have
even considered carefully what to leave OUT (converting to non-string data
types, interpolating values, things like that).

I think that I am now at the point where I could really use some input from
others. So I''d like to invite people to review my design and send me your
suggestions. I''m not expecting this as a *useful* module yet (it doesn''t
yet parse files!), but it seemed like a good stage at which to ask for
feedback. I''m attaching two files, config.py and configTest.py, and they
are also available from these urls:

http://www.mcherm.com/publish/2004-10-17/config.py
http://www.mcherm.com/publish/2004-10-17/configTest.py

Thanks in advance for reviewing this.

-- Michael Chermside



这篇关于ConfigParser枪战,初步进入的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆