On 27 October 2014 19:23, Donald Stufft 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

On Oct 27, 2014, at 4:45 PM, Daniel Holth 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 wrote:

...

On 27 October 2014 19:23, Donald Stufft 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

There's also AXON ("It tries to combine the best of JSON, XML and YAML.") – http://intellimath.bitbucket.org/axon/

On Tue, Oct 28, 2014 at 07:43 -0700, Chris Jerdonek wrote:

On Tue, Oct 28, 2014 at 2:59 AM, holger krekel wrote:

...

On Mon, Oct 27, 2014 at 16:45 -0400, Daniel Holth 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.

Don't know but TOML could work well as a user facing config syntax. Seems to be reasonably well defined and more expressive than plain ini files. Would be curious if it could be used for tox for example.

Daniel, Holger, et al., what is wrong with ini out of curiosity?

E.g. There are no types with normal ini files, so integers, strings, lists etc. all have to be done manually, i.e. without support from the parser. best, holger

Thanks, --Chris