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 syste
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 wan
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
[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
> .ini, overridden again by a .ini. OK, maybe it's
> overengineered, but I do use th
[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
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,
Fuzzyman 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 that ju
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
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
>>
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
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 sto
[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
http://python.o
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 deve
[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
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.
>>
>>
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
> (f
> 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 Spo
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
>> und
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 env
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 a
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 cha
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
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 breaki
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
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 t
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 Co
Vinay Sajip wrote:
Fuzzyman 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 to extend
Fuzzyman 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 ConfigPar
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
* C
29 matches
Mail list logo
