json is both subset of python literals (pyon, if you want) and yaml, but stricter than both: it doesn’t allow typewriter apostrophes (') for strings like python, and doesn’t allow unicode, raw strings or byte literals. (yaml afaik knows all of those, albeit with different syntax than python. but it has them, allowing to easily represent more of python’s capabilities)

yaml reports errors and treats ambiguities as errors. with “strictness”, i mean the ways something can be written: both python and yaml allow for synonymous ways to write the same object, whereas JSON only accepts variable whitespace: hardly a source of error!

and of course there’s value in a stdlib yaml parser: as i said it’s much more human friendly, and even some python projects already use it for configuration because of this (i say “even”, because of course JSON being in the stdlib is a string aargument to use it in dependecy-free projects). also YAML is standardized, so having a parser in the stdlib doesn’t mean it’s a bad thing when development stalls, because a parsing library doesn’t need to evolve (was it kenneth reitz who said the stdlib is where projects go to die?)

2013/5/31 Bruce Leban <bruce@leapyear.org>

On May 31, 2013 9:46 AM, "Philipp A." <flying-sheep@web.de> wrote:
>
> I’m no big fan of JSON, because it’s so strict and comparatively verbose compared with YAML. I just think YAML is more pythonic, and a better choice for any kind of human-written data format.
>

Considering json values are Python literals and yaml isn't I'd say you have the first part backwards. And as far as human-written data goes strictness helps prevent errors.

But it doesn't have to be a competition. If there's value in having a standard yaml parser or value in accepting yaml in specific cases that value should stand by itself.

--- Bruce
(from my phone)