For what it's worth, I've been following this thread, and I like the idea of using TOML for all the "pro" reasons posted so far. It's newness or not reaching 1.0 yet don't bother me as I believe the plans to specify TOML 0.4 or optionally support the later versions if they don't cause problems makes a lot of sense. The fact that the parser is 300+ lines of code and can be easily vendored is also a big plus. Given that rust is using TOML, if Python adopts it as well, that is big enough "market share" for me and people will get used to it soon enough.

Randy Syring
Husband | Father | Redeemed Sinner

"For what does it profit a man to gain the whole world
and forfeit his soul?" (Mark 8:36 ESV)

On 05/10/2016 03:38 AM, Alex Grönholm wrote:

A few facts:

YAML is good enough for Salt, Ansible and numerous other common tools

The YAML standard has been stable for many years, unlike TOML which still hasn't even reached 1.0

YAML has widespread tooling support, unlike TOML

We all agree that JSON is not the solution. No comments, trailing commas etc.
TOML isn't much better than ConfigParser in terms of representing nested structures.
So far the ONLY objective problems with YAML seems to be the problematic implementation named PyYAML. If this is really the case, I'd gladly help build a better one just to prevent TOML from being chosen for this task. That we're even considering building something as important as this on an unstable standard is pretty horrifying to me in itself.

10.05.2016, 06:37, Chris Barker kirjoitti:
Really?

writing Yet Another Markup Language (YAML :-) ) CAN'T be the simplest, best option.

> After further consideration, and pytoml's author's comment about the spec changing without a version increase, I think we might be better off rolling our own.

I like the general simplicity, and would stick with that, but I'd be a lot more comfortable if we had our spec that was more consistent.

If we're going to do that, then why not the 'simple part of yaml'.

or Python literals. (if I recall, the main reason not to do that was that no other language has a lib to read it -- rolling out own does not solve that!)

Or just go with JSON -- I'm annoyed by it at times, but it's not SO bad.

(and you can kinda-sorta simulate comments with useless keys :-)

{ "comment": "this is just something i wanted to say here",
...
}

or we could do "JSON with comments" -- not hard to write a tiny pre-processor before passing it off to the json lib.

Anyway -- let's avoid the temptation to role your own everything, and use something standard!

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA 98115   (206) 526-6317   main reception

Chris.Barker@noaa.gov
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig