The config parser doesn't handle saving yet, but it does lay the groundwork for being able to handle far more structured config files, and will eventually be able to save them.
We decided against configobj, mainly because the way it adds structure is fugly; it nest sections like this:
[section]
[[subsection]]
[[[subsubsection]]]
You can see this quickly getting ridiculous. It also means a lot of our existing configs will break, since it'll parse something like "background_color = #000" as an empty value followed by a comment "000".
The new parser copes with this, and a few other special cases, can recover gracefully from most errors, and does nesting in a much more pleasing manner:
[section]
[subsection]
[subsubsection]
i.e. it uses indenting, just like Python. This isn't yet enabled in trunk, but the code to add it is already there, and quite modest Our problem now is working out exactly *how* we should make use of this.
The config parser doesn't handle saving yet, but it does lay the groundwork for being able to handle far more structured config files, and will eventually be able to save them.
We decided against configobj, mainly because the way it adds structure is fugly; it nest sections like this:
[section] ion]]]
[[subsection]]
[[[subsubsect
You can see this quickly getting ridiculous. It also means a lot of our existing configs will break, since it'll parse something like "background_color = #000" as an empty value followed by a comment "000".
The new parser copes with this, and a few other special cases, can recover gracefully from most errors, and does nesting in a much more pleasing manner:
[section] subsubsection]
[subsection]
[
i.e. it uses indenting, just like Python. This isn't yet enabled in trunk, but the code to add it is already there, and quite modest Our problem now is working out exactly *how* we should make use of this.