[Python-Dev] YAML (was Re: Extension to ConfigParser)

Tim Parkin tim at pollenation.net
Wed Feb 1 00:09:46 CET 2006

Georg Brandl wrote:
> 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 the developer) form.
> While we're at it, is the Python library going to incorporate some YAML
> parser in the future? YAML seems like a perfectly matching data format
> for Python.

Unfortunately, YAML still doesn't have a fully featured pure python
parser (pyyaml works on simple yaml documents).

The specification also doesn't have a blueprint implementation (there
was talk about one at some point) and the fact that the specification
has a context sensitive grammar and quite a large lookahead means that
writing parsers with standard components is a little tricky (I know I
tried for some time). The defacto standard implementation is 'syck'
which is a c library that is used in the ruby distribution and works
very well. Up until recently the only python wrapper that didn't
segfault for syck was our own pyrex wrapper. Forunately, Kirill Simonov
has written an excellent wrapper (which handles load and dump) which is
available at http://xitology.org/pysyck/.

Although we make extensive use of yaml and it is definitely the best
human editable data format I've used - and our non techy clients agree
that it's pretty simple to use - it is a lot more complicated than ini
files. Our opinion is that it undoubtedly has it's bad points but that
it makes complex configuration files easy to write, read and edit.

If you want a human readable serialisation format, it's way, way better
than xml. If you want to create config files that have some nesting and
typing, have a look and see what you think.

Tim Parkin

p.s. JSON is 'nearly' a subset of YAML (the nearly point is being
considered by various parties).

More information about the Python-Dev mailing list