On Sat, 7 May 2016 at 07:49 Nick Coghlan <ncogh...@gmail.com> wrote: > > On 7 May 2016 13:00, "Nathaniel Smith" <n...@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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
