On Oct 27, 2014, at 4:45 PM, Daniel Holth <dholth@gmail.com> wrote:
I liked it because I agree with the TOML author that the YAML spec gives rage; YAML seems to be defined as a bunch of things that the end user is supposed to think are intuitive, but try understanding and correctly parsing the full set of what is allowed... TOML on the other hand is short.
On Mon, Oct 27, 2014 at 4:23 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 27 October 2014 19:23, Donald Stufft <donald@stufft.io> wrote:
Ugh, I hate TOML. I’m -1 on any of the standards using it, but I also think the standards should be around data exchange and should just use JSON and leave front end stuff like that up to the implementations.
I had a quick glance at TOML, and I can't say I was particularly enamoured by it. I don't see that it has any particularly huge benefits over "plain" ini files (if your needs are simple) or YAML (ignoring the over-complicated stuff that nobody actually needs).
+1 on JSON for "internal" format, and tools deciding for themselves on the best user-facing format.
I'm also not sure I see the value of mapping directly to a dict. Surely internal formats should be isolated from the user interface, not exposed directly? Paul
The YAML spec isn’t for end users any more than the various HTTP RFCs are for end users. The spec is for people implementing a yam parser/encoder and when implementing a spec the less ambiguity and the more verbose the spec is, the better. It’s not a very good argument though, because JSON is the better format for data exchange and that’s all the standards should be focused on. If someone wants to make a tool that uses TOML and emits standard metadata (when that becomes a thing outside of Wheels) more power to them. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA