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.bar...@noaa.gov <mailto:chris.bar...@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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
