On 1/30/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Aha. I am beginning to understand. When people say ConfigParser is
hopeless they mean .INI files are hopeless. I happen to disagree.
(There's also a meme that says that every aspect of an app should be
configurable. I disagree with that
Paul Moore wrote:
On 1/30/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Aha. I am beginning to understand. When people say ConfigParser is
hopeless they mean .INI files are hopeless. I happen to disagree.
(There's also a meme that says that every aspect of an app should be
configurable. I
Tony Meyer wrote:
[Guido van Rossum]
What would break if we rewrote the save functionality to produce a
predictable order?
As a reminder to anyone interested, there are three patches on SF
that provide this (each in a different way):
ConfigParser to accept a custom dict to
Fuzzyman fuzzyman at voidspace.org.uk writes:
In my opinion dictionary syntax is the most natural way to represent a
config file - it is a data structure with named members. This means the
API for accessing the data - whether from a subclass that does
additional value processing or from code
Michael Foord wrote:
Tony Meyer wrote:
[Guido van Rossum]
Add 'surgical editing' to ConfigParser
http://python.org/sf/1410680
Adds an update_file method (no other changes) that updates the given
file to match the current configuration, preserving blank lines,
comments, and order.
[Scott Dial]
[Re: http://python.org/sf/1410680]
I've spent a small amount of time playing with this patch, and the
intent is there, but it appears to have some obvious bugs with adding
blank lines and (at least) making an empty [DEFAULT] section appear
and
disappear. I'm not sure that this
[Paul Moore]
* No way to merge files or sections. Usually to provide default
values. I have a suite of applications, all using the same framework.
I have a hardcoded DEFAULT_CONFIG in the code, overriden by a
suite.ini, overridden again by a app.ini. OK, maybe it's
overengineered, but I do
On 1/31/06, Tony Meyer [EMAIL PROTECTED] wrote:
Why doesn't this work? It does here:
$ cat suite.ini
[sect]
opt1 = 1
opt2 = 2
$ cat app.ini
[sect]
opt1 = 3
opt4 = 5
$ python
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type
2006/1/30, Fredrik Lundh [EMAIL PROTECTED]:
fwiw, I've *never* used INI files to store program state, and I've
never used the save support in ConfigParser.
As a SiGeFi developing decision, we obligated us to keep the program
state between executions (hey, if I set the window this big, I want
Sorry, I didn't follow up here like I should have, and I haven't
followed the rest of this conversation, so apologies if I am being
redundant...
Fuzzyman wrote:
While ConfigParser is okay for simple configuration, it is (IMHO) not a
very good basis for anyone who wants to build better systems,
Vinay Sajip wrote:
Fuzzyman fuzzyman at voidspace.org.uk writes:
Hello Vinjay,
In the past there has been some discussion about a new module to replace
ConfigParser. Most notably at
http://wiki.python.org/moin/ConfigParserShootout
[snip]
It would be possible
Fuzzyman wrote:
The resolution I'm suggesting means that people can continue to use
ConfigParser, with major feature enhancements. *Or* they can migrate to
a slightly different API that is easier to use - without needing to
switch between incompatible modules.
I don't think enhancing
On 1/30/06, Ian Bicking [EMAIL PROTECTED] wrote:
I don't think enhancing ConfigParser significantly is a good way
forward. Because of ConfigParser's problems people have made all sorts
of workarounds, and so I don't think there's any public interface that
we can maintain while changing the
Guido van Rossum wrote:
On 1/30/06, Ian Bicking [EMAIL PROTECTED] wrote:
I don't think enhancing ConfigParser significantly is a good way
forward. Because of ConfigParser's problems people have made all sorts
of workarounds, and so I don't think there's any public interface that
we can
Guido van Rossum wrote:
I don't think enhancing ConfigParser significantly is a good way
forward. Because of ConfigParser's problems people have made all sorts
of workarounds, and so I don't think there's any public interface that
we can maintain while changing the internals without breaking lots
Ian Bicking wrote:
Fuzzyman wrote:
The resolution I'm suggesting means that people can continue to use
ConfigParser, with major feature enhancements. *Or* they can migrate
to a slightly different API that is easier to use - without needing
to switch between incompatible modules.
I don't
Ian Bicking wrote:
Guido van Rossum wrote:
I don't think enhancing ConfigParser significantly is a good way
forward. Because of ConfigParser's problems people have made all sorts
of workarounds, and so I don't think there's any public interface that
we can maintain while changing the
Guido What's so bad about ConfigParser?
My guess is that people find its limited nesting, well, limiting. Python
containers being the arbitrary nesting little devils that they are, I can
understand the desire to push the envelope.
It's my opinion that ConfigParser should stay pretty much
On 1/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Guido What's so bad about ConfigParser?
My guess is that people find its limited nesting, well, limiting. Python
containers being the arbitrary nesting little devils that they are, I can
understand the desire to push the envelope.
Guido van Rossum wrote:
On 1/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Guido What's so bad about ConfigParser?
My guess is that people find its limited nesting, well, limiting. Python
containers being the arbitrary nesting little devils that they are, I can
understand the
Guido van Rossum wrote:
Aha. I am beginning to understand. When people say ConfigParser is
hopeless they mean .INI files are hopeless. I happen to disagree.
(There's also a meme that says that every aspect of an app should be
configurable. I disagree with that too. As Joel Spolski points
Guido van Rossum wrote:
Ah. This definitely isn't what ConfigParser was meant to do. I'd think
for this you should use some kind of XML pickle though. That's
horrible if end users must edit it, but great for saving
near-arbitrary persistent data in a readable and occasionally editable
(for
Guido van Rossum wrote:
On 1/30/06, Michael Foord [EMAIL PROTECTED] wrote:
But like it or not, configuration files are often used to store data
about what a program does - not just the UI options. Storing this in a
human readable and editable format is of great advantage.
Yes, a lot of
[Guido]
What's so bad about ConfigParser?
[Skip Montanaro]
It's my opinion that ConfigParser should stay pretty much as it is
other
than perhaps adding round trip capability.
[...]
If we want more sophisticated functionality a new module should be
written,
or one of the existing
On 1/30/06, Michael Foord [EMAIL PROTECTED] wrote:
I have a feeling that for many complex applications the developer is the
user. Agreed that giving complex configuration data along with program
data to the end-user is not good.
Despite this, data storage that needs to be edited by developers
[Guido van Rossum]
What would break if we rewrote the save functionality to produce a
predictable order?
As a reminder to anyone interested, there are three patches on SF
that provide this (each in a different way):
ConfigParser to accept a custom dict to allow ordering
Guido van Rossum wrote:
On 1/30/06, Michael Foord [EMAIL PROTECTED] wrote:
I have a feeling that for many complex applications the developer is the
user. Agreed that giving complex configuration data along with program
data to the end-user is not good.
Despite this, data storage that
Fuzzyman fuzzyman at voidspace.org.uk writes:
In the past there has been some discussion about a new module to replace
ConfigParser. Most notably at
http://wiki.python.org/moin/ConfigParserShootout
[snip]
It would be possible to extend to the ConfigObj API to be backwards
compatible with
Hello all,
In the past there has been some discussion about a new module to replace
ConfigParser. Most notably at
http://wiki.python.org/moin/ConfigParserShootout
Specific issues that could be addressed include :
* Simpler API
* Nested subsections
* List values
* Storing/converting datatypes
*
29 matches
Mail list logo
