On 2013-05-31, at 19:18 , Philipp A. wrote:
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.
All json strings are unicode literals: JSON strings can embed any unicode character literally aside from the double quote and backslash, and they support \u escapes (identical to Python's). The only major difference is that JSON does not support \U escapes (to escapes can only be used for BMP characters).
(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 has no rawstrings that I know of. It also has no byte literals, there is a working draft for a binary tag encoded in base64[0]. Its failsafe schema only contains strings (unicode), same as JSON.
yaml reports errors and treats ambiguities as errors.
That is not correct, the spec notes:
A YAML processor may recover from syntax errors, possibly by ignoring certain parts of the input, but it must provide a mechanism for reporting such errors.
YAML implementations are absolutely free to resolve ambiguities on their own and not report any error by default, and the spec's "loading failure points" graph clearly indicates parsing a YAML document may yield a partial representation.
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?)