On Sat, 7 May 2016 at 07:49 Nick Coghlan <ncoghlan@gmail.com> wrote:

On 7 May 2016 13:00, "Nathaniel Smith" <njs@pobox.com> wrote:
>
> Here's that one-stop writeup/comparison of all the major configuration
> languages that I mentioned:
>
> https://gist.github.com/njsmith/78f68204c5d969f8c8bc645ef77d4a8f

Thanks for that, and "yikes" on the comment handling variations in ConfigParser - you can tell I've never even tried to use end-of-line comments in INI files, and apparently neither has anyone I've worked with :)

Yeah, that's pretty bad. :/ I checked when ConfigParser was added to Python and it's late 1997: https://hg.python.org/cpython/rev/5b24cbb1f99b, so rather old and predates our stricter code quality rules for additions to the stdlib.

For YAML, my main concern isn't quirkiness of the syntax, or code quality in PyYAML, it's the ease with which you can expose yourself to security problems (even if *pip* loads the config file safely, that doesn't mean every other tool will). Since we don't need the extra power, the easiest way to reduce the collective attack surface is to use a strictly less powerful (but still sufficient) format.

For ast.literal_eval, we'd still need to come up with a way to do sections, key:value mappings and define rules for comments.

For completeness, I'll note that XML combines even more user unfriendly syntax than JSON with similar security risks to YAML.

So with the trade-offs laid out like that (and particularly the inconsistent comment and Unicode handling in ConfigParser), I'm prompted to favour following Rust in adopting TOML.

+1 for TOML from me as well. I know Paul brought up the lack of familiarity, but the format is simple and the Rust community is already fully dependent on it so at worst Rust + us could always just ignore future format versions if necessary.

If TOML is the chosen format we could ask how long until a 1.0 release to know if we waited a month or so to implement we could make sure we're compliant with that version.

I also checked pytoml at https://github.com/avakar/pytoml and it looks like it's pretty stable; no changes in the past 5 months except to support Python 3.5 and only 3 issues. And the format is simple enough that if someone had to fork the code like Nathaniel suggested or we did it from scratch it wouldn't be a huge burden.

-Brett

Cheers,
Nick.

P.S. I particularly like the idea of using extension sections to eventually consolidate other static config into a common file - that nicely addresses my concern with config file proliferation, since it opens the door to eventually subsuming other files like MANIFEST.in and setup.cfg as archiving and build systems are updated

>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> 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