Learned about toml the other day, looks like it could be useful for packaging. It is an .ini-style language that maps unambiguously to a dict, supports comments, and is used by rust's packaging system "cargo". https://github.com/toml-lang/toml Unfortunately at least 3 of the Python implementations don't seem to be up to date with the current version of the spec specifically regarding triple-""" strings.
On Oct 27, 2014, at 3:16 PM, Daniel Holth <dholth@gmail.com> wrote:
Learned about toml the other day, looks like it could be useful for packaging. It is an .ini-style language that maps unambiguously to a dict, supports comments, and is used by rust's packaging system "cargo". https://github.com/toml-lang/toml
Unfortunately at least 3 of the Python implementations don't seem to be up to date with the current version of the spec specifically regarding triple-""" strings. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 27 October 2014 19:23, Donald Stufft <donald@stufft.io> 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
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 <p.f.moore@gmail.com> wrote:
On 27 October 2014 19:23, Donald Stufft <donald@stufft.io> 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 <dholth@gmail.com> 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 <p.f.moore@gmail.com> wrote:
On 27 October 2014 19:23, Donald Stufft <donald@stufft.io> 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
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. cheers, holger
On Mon, Oct 27, 2014 at 4:23 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 27 October 2014 19:23, Donald Stufft <donald@stufft.io> 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
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 2:59 AM, holger krekel <holger@merlinux.eu> 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? Thanks, --Chris
On Tue, Oct 28, 2014 at 07:43 -0700, Chris Jerdonek wrote:
On Tue, Oct 28, 2014 at 2:59 AM, holger krekel <holger@merlinux.eu> 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
participants (6)
-
Chris Jerdonek -
Daniel Holth -
Donald Stufft -
holger krekel -
Paul Moore -
Piotr Dobrogost