What YAML engine do you use?

[Reinhold Birkenfeld]

Hello,

I know that there are different YAML engines for Python out there (Syck,
PyYaml, more?).

Which one do you use, and why?

For those of you who don't know what YAML is: visit http://yaml.org/!
You will be amazed, and never think of XML again. Well, almost.

Reinhold

 

[Diez B. Roggisch]

I know that there are different YAML engines for Python out there (Syck,

PyYaml, more?).

Which one do you use, and why?

I first used yaml, tried to migrate to syck. What I like about syck is that
it is faster and doesn't try to create objects but only dicts - but it
crashed if the number of yaml objects grew larger. So I still use yaml.

For those of you who don't know what YAML is: visit http://yaml.org/!
You will be amazed, and never think of XML again. Well, almost.

It is certainly nice.

 

[Jonas Galvez]

I first used yaml, tried to migrate to syck. What I like about
syck is that it is faster and doesn't try to create objects but
only dicts - but it crashed if the number of yaml objects grew
larger. So I still use yaml.

Hmm.. I've never had any problems with syck. In fact, I'm using it in
a small project now where I store a helluva of data in yaml files...

Strange.

 

[Istvan Albert]

You will be amazed, and never think of XML again.

XML with elementtree is what makes me never have think about XML again.

Istvan.

 

[Irmen de Jong]

XML with elementtree is what makes me never have think about XML again.

+1 QOTW

-Irmen

 

[Paul Rubin]

For those of you who don't know what YAML is: visit http://yaml.org/!
You will be amazed, and never think of XML again. Well, almost.

Oh please no, not another one of these. We really really don't need it.

 

[rm]

Oh please no, not another one of these. We really really don't need it.

well, I did look at it, and as a text format is more readable than XML
is. Furthermore, XML's verbosity is incredible. This format is not.
People are abusing the genericity of XML to put everything into it.

Parsing and working with XML are highly optimized, so there's not really
a problem in that sector. But to transfer the same data in a YAML
format, rather than a XML format is much more economic. But networks are
getting faster, right?

Nowadays, people are trying to create binary XML, XML databases,
graphics in XML (btw, I'm quite impressed by SVG), you have XSLT, you
have XSL-FO, ... .

And I think, YAML is a nice initiative.

bye,
rm

 

[Fredrik Lundh]

well, I did look at it, and as a text format is more readable than XML is.

judging from http://yaml.org/spec/current.html (750k), the YAML designers are
clearly insane. that's the most absurd software specification I've ever seen. they
need help, not users.

</F>

 

[A.M. Kuchling]

Nowadays, people are trying to create binary XML, XML databases,
graphics in XML (btw, I'm quite impressed by SVG), you have XSLT, you
have XSL-FO, ... .

Which is an argument in favor of XML -- it's where the activity is, so it's
quite likely you'll encounter the need to know XML. Few projects use YAML,
so the chance of having to know its syntactic details is small.

--amk

 

[A.M. Kuchling]

judging from http://yaml.org/spec/current.html (750k), the YAML designers are
clearly insane. that's the most absurd software specification I've ever seen. they
need help, not users.

IMHO that's a bit extreme. Specifications are written to be detailed, so
consequently they're torture to read. Seen the ReStructured Text spec
lately?

The basic idea -- a data dumping format that's human-readable -- isn't a bad
one. OTOH, I can't recall wanting such a thing -- when I want readable
output I'm happy using
unreadable pickle files, unpickling the object and calling a .dump() or
..as_text() method.)

But YAML seems to have started out with the goal of being human-writable,
something you would write in Emacs, and that seems to have gotten lost; the
format is now just as complicated as Restructured Text, but more cryptic
(the URI namespacing for tags, for example), not really simpler than
XML and in some ways weaker (e.g. only two encodings supported, more
complicated escaping rules).

For a pure Python application, I can't see a need for YAML; use
pickle/cPickle instead, because they're already there. Exchanging
serialized objects between Python/Perl/Ruby scripts might be a good use case
for YAML, but XML has wider software support and S-expressions are simpler,
so my inclination would be to use them instead of YAML.

--amk

 

[Reinhold Birkenfeld]

IMHO that's a bit extreme. Specifications are written to be detailed, so
consequently they're torture to read. Seen the ReStructured Text spec
lately?

Agreed. If you just want to use it, you don't need the spec anyway.

The basic idea -- a data dumping format that's human-readable -- isn't a bad
one. OTOH, I can't recall wanting such a thing -- when I want readable
output I'm happy using
unreadable pickle files, unpickling the object and calling a .dump() or
.as_text() method.)

But YAML seems to have started out with the goal of being human-writable,
something you would write in Emacs,

Exactly. I use it as a format for config files the user can edit
directly without much thinking (the explanation on top of the file are 3
lines).

and that seems to have gotten lost; the
format is now just as complicated as Restructured Text, but more cryptic
(the URI namespacing for tags, for example), not really simpler than
XML and in some ways weaker (e.g. only two encodings supported, more
complicated escaping rules).

In most cases you don't need the complicated things, and the
http://www.yaml.org/refcard.html isn't very complex either.

Reinhold

 

[Fredrik Lundh]

IMHO that's a bit extreme. Specifications are written to be detailed, so
consequently they're torture to read. Seen the ReStructured Text spec
lately?

I've read many specs; YAML (both the spec and the format) is easily
among the worst ten-or-so specs I've ever seen.

ReST and YAML share the same deep flaw: both formats are marketed
as simple, readable formats, and at a first glance, they look simple and read-
able -- but in reality, they're messy as hell, and chances are that the thing
you're looking at doesn't really mean what you think it means (unless you're
the official ReST/YAML parser implementation). experienced designers
know how to avoid that; the ReST/YAML designers don't even understand
why they should.

But YAML seems to have started out with the goal of being human-writable,
something you would write in Emacs, and that seems to have gotten lost; the
format is now just as complicated as Restructured Text, but more cryptic
(the URI namespacing for tags, for example), not really simpler than
XML and in some ways weaker (e.g. only two encodings supported, more
complicated escaping rules).

http://www.modelsmodelsmodels.biz/images/hmo033.jpg

</F>

 

[Daniel Bickett]

XML with elementtree is what makes me never have think about XML again.

I second that. I heard about yaml and I read into it, but when I tried
to use it I didn't seem to get in touch with all of the glory
surrounding it. The yaml module -- when I tried to use it -- was very
error prone, and simply didn't work. I didn't have the time to go
through and try to tweak it because I was pressed for time and need a
quick solution. As for syck, I don't know if it was just me, but when
I downloaded it I got a whole lot of directories with obscure names
and files with .c extensions. So, discouraged, I gave up on yaml.

Elementtree, on the other hand, is wonderful

+1 QOTW

I second that, as well.

here's-to-appreciating-the-end-without-having-to-be-interested-in-the-means-ly
y'rs
Daniel Bickett

 

[Bengt Richter]

Which is an argument in favor of XML -- it's where the activity is, so it's
quite likely you'll encounter the need to know XML. Few projects use YAML,
so the chance of having to know its syntactic details is small.

<rant>
I thought XML was a good idea, but IMO requiring quotes around
even integer attribute values was an unfortunate decision. I don't buy
their rationale of keeping parsing simple -- as if extracting a string
with no embedded space from between an equal sign and terminating white
space were that much harder than extracting the same delimited by double quotes.
The result is cluttering SVG with needless cruft around numerical graphics parameters.
</rant>

OTOH, I think the HTML XML spec is very readable, and nicely designed.
At least the version 1.0 spec I snagged from W3C a long time ago.
.... I see the third edition at http://www.w3.org/TR/REC-xml/ is differently styled,
(I guess new style sheets) but still pretty readable (glancing at it now).

Regards,
Bengt Richter

 

[Peter Hansen]

judging from http://yaml.org/spec/current.html (750k), the YAML designers are
clearly insane. that's the most absurd software specification I've ever seen. they
need help, not users.

IMHO that's a bit extreme. Specifications are written to be detailed, so
consequently they're torture to read. Seen the ReStructured Text spec
lately? [...]
But YAML ... the format is now ... not really simpler than
XML and in some ways weaker (e.g. only two encodings supported, more
complicated escaping rules).

As I recall, one of the key original goals for XML was that the
parsers be relatively easy to write (relative to SGML).

Judging by that YAML spec, I can imagine that a YAML parser could
well be much more difficult to write than an XML parser would be.

Anyone have personal experience with this?

(Yes, I know people don't write parsers as often as they use
them, and that's probably some of the justification behind YAML,
but looking at that YAML spec, I find it hard to imagine I could
ever remember enough of it to write a YAML file by hand, and
yet I can and do write XML files by hand often.)

-Peter

 

[Fredrik Lundh]

Agreed. If you just want to use it, you don't need the spec anyway.

but the guy who wrote the parser you're using had to read it, and understand it.
judging from the number of crash reports you see in this thread, chances are that
he didn't.

</F>

 

[Steve Holden]

<rant>
I thought XML was a good idea, but IMO requiring quotes around
even integer attribute values was an unfortunate decision. I don't buy
their rationale of keeping parsing simple -- as if extracting a string
with no embedded space from between an equal sign and terminating white
space were that much harder than extracting the same delimited by double quotes.

It isn't that much harder, but if there are two ways to do the same
thing then effectively one of them has to become a special case, thereby
complicating the code that has to handle it (in this case the parser).

"There should be one (and preferably only one) ..." should be a familiar
mantra around here

The result is cluttering SVG with needless cruft around numerical graphics parameters.
</rant>

It seems to me the misunderstanding here is that XML was ever intended
to be generated directly by typing in a text editor. It was rather
intended (unless I'm mistaken) as a process-to-process data interchange
metalanguage that would be *human_readable*.

Tools that *create* XML are perfectly at liberty not to require quotes
around integer values.

OTOH, I think the HTML XML spec is very readable, and nicely designed.
At least the version 1.0 spec I snagged from W3C a long time ago.
.... I see the third edition at http://www.w3.org/TR/REC-xml/ is differently styled,
(I guess new style sheets) but still pretty readable (glancing at it now).

Regards,
Bengt Richter

regards
Steve

 

[Doug Holton]

A.M. Kuchling wrote:




I've read many specs; YAML (both the spec and the format) is easily
among the worst ten-or-so specs I've ever seen.

What do you expect? YAML is designed for humans to use, XML is not.
YAML also hasn't had the backing and huge community behind it like XML.
XML sucks for people to have to write in, but is straightforward to
parse. The consequence is hordes of invalid XML files, leading to
necessary hacks like the mark pilgrim's universal rss parser. YAML
flips the problem around, making it harder perhaps to implement a
universal parser, but better for the end-user who has to actually use
it. More people need to work on improving the YAML spec and
implementing better YAML parsers. We've got too many XML parsers as it is.

 

[rm]

What do you expect? YAML is designed for humans to use, XML is not.
YAML also hasn't had the backing and huge community behind it like XML.
XML sucks for people to have to write in, but is straightforward to
parse. The consequence is hordes of invalid XML files, leading to
necessary hacks like the mark pilgrim's universal rss parser. YAML
flips the problem around, making it harder perhaps to implement a
universal parser, but better for the end-user who has to actually use
it. More people need to work on improving the YAML spec and
implementing better YAML parsers. We've got too many XML parsers as it is.

100% right on, stuff (like this)? should be easy on the users, and if
possible, on the developers, not the other way around. But developers
come second. Now, I didn't check the specs, they might be difficult,
they might be incorrect, maybe their stated goal is not reached with
this implementation of their idea. But I'd love to see a generic,
pythonic data format.

bye,
rm

 

[Fredrik Lundh]

100% right on, stuff (like this)? should be easy on the users, and if possible, on the developers,
not the other way around.

I guess you both stopped reading before you got to the second paragraph
in my post. YAML (at least the version described in that spec) isn't easy on
users; it may look that way at a first glance, and as long as you stick to a
small subset, but it really isn't. that's not just bad design, that's plain evil.

and trust me, when things are hard to get right for developers, users will
suffer too.

</F>