[Distutils] comparison of configuration languages

[Randy Syring]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160510/c6d10d13/attachment-0001.html>