On May 10, 2016, at 10:30 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 10 May 2016 10:24:10 -0400 Donald Stufft <donald@stufft.io> wrote:
TOML is infinitely better at nested structured that ConfigParser, given that TOML actually *supports* nested structures beyond a level of 1. The only way to get anything like:
[package.build] dependencies = ["setuptools", "wheel"]
In ConfigParser is to add post-processing to the values, which then you're no longer a "ConfigParser" file, you're a "ConfigParser + Whatever random one off code you wrote to do post processing" file.
The post-processing doesn't seem difficult enough to make any fuss about it, IMHO. The most important concern here should be how usable the format is for end users, not whether implementations need 20 additional lines of code to work with it.
I think TOML is more usable than ConfigParser and in particular I think that the adhoc post processing step makes ConfigParser inherently less usable because it forces a special syntax that is specific to this one file. It also means that there's no "right" answer for when you have two different implementations that interpret the same file differently. There's no spec to work off of so it ends up regressing to a smaller version of one of our current problems with the toolchain-- Everything is implementation defined by whatever the most popular tool at the time is.
(also, what is wrong with providing a pypa-specific library for parsing required configuration? are distlib / distil / pkgutil / the distutils-competitor-du-jour still alive?)
While we are providing unopinionated bindings like that for the PEPS, we don't want to make that "special" any more than it's just a reference implementation. Tools in languages other than Python will be expected to parse and read these files. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA