On 7 May 2016 at 04:14, Donald Stufft <donald@stufft.io> wrote:
While I personally prefer YAML to any of the options on a purely syntax based level, when you weigh in all the other considerations for this I think that it makes sense to go with TOML for it.
The only other option I think that could work is what Chris (I think?) suggested and just use a Python literal evaluated using ``ast.literal_eval()`` this is safe to do but it would make it harder for other languages to parse our files. It's similar to the approach taken by Lua Rocks for how their packaging system works (although their uses variables instead of one big dictionary which I think looks nicer) but Lua is much better suited for trying to execute safely outside of ``ast.literal_eval()`` too.
All in all, I think TOML is the right answer (and that's why my partially written PEP used TOML).
FWIW (and because obsessing about config formats is a long-running hobby of mine :-)) my view is: - JSON sucks as a human-editable format, because it's too strict over things like commas and has no comments. It's supported by the stdlib, though, which is nice. - YAML ought to be wonderful, but it ended up over-engineered (yes, we can ignore the bits we don't care about). Also, pyYAML is a bit of an annoying dependency (big, reportedly slow unless you use the C version) - not something I'd want pip to have to vendor. - INI (ConfigParser) format is too simple for many use cases. It has stdlib support, though. - Python literals are good, but they define values, they aren't a file format. We'd need to write a parser for "the rest" - TOML seems pretty good, but is immature (I remember when YAML seemed like TOML does now...) Also, it's unfamiliar to people (I wasn't aware of the use in Rust) - Just for a laugh, can I mention XML? :-) Overall, *any* choice feels like I'm choosing the "best of a bad job" :-( With all that said, I'm inclined to agree that TOML looks good. Paul