>> downvotes are because you're sort of insulting Lisp (which is older than you and all your "best practices") with an ignorant complaint.

I recognized it as lisp right away, but I share the complaint about the format. If you want to write a lisp program then do so. If you want to format something for human readability it's probably a good idea to do it differently. This is just a opinion of course, but I suspect it's not an uncommon one.

Maybe uncommon over all, but you should definitely expect the GNU project to use Guile for scripting needs. In this context, it's the obvious choice.

Furthermore, anything that tricks you into learning Scheme is a good thing. Like eating vegetables.

Are you suggesting that Lisp programs aren't readable by humans?

So all I asked is whether it was possible to roundtrip an edit to one of these files from Python without writing an AST visitor, and without losing formatting and comments. I have absolutely no idea how this could be considered ignorant.

Ignorant of the cave-dwelling depths some would go to ensure the practicality of the arcane religious icon that is LISP as a massively overgeneral solution to a problem, at the cost of all downstream users who must now "just switch to Guile" or link against chunks of a C compiler just to introspect a config? Maybe, but I'm content with that.

So the example you showed with XML uses XPath, what do you think that does? I am sure something similar can be created in python for editing lisp code as easily as this.

> My first thought is how I'd parse, modify and write it back without losing user's comments, formatting, changes and suchlike. Is this some well understood format with libraries for common programming languages? If not, it is just likely to proliferate more crappy config management with chunks of regexes and suchlike

> Elsewhere people are saying it's just Scheme. I'm sure I could find a parser for that in Python, and maybe if I'm really lucky that parser will record whitespace and comment nodes, and have a reverse transformation, but do I really want to be writing error prone 20-line AST visitors just to tweak an integer setting? (No, I most certainly do not, and I consider design decisions like this a massive code smell that'd ward me off any further investigation of a system)

XML satisfies all the above: no AST visitors, no custom parsing routines, no attempting to solve the halting problem in order to introspect a simple scalar value.

What you're saying is that the same is "possible" with Scheme. At least one followup comment (finally) described an algorithm that would actually allow machine-driven file changes, but we're still left with rather than a working out of the box solution, a description of an algorithm that "might someday work" and that's not the sort of thing I want to be dealing with while building business solutions on somebody else's dime, which drives my conclusion above: this config file syntax is not for me, and my original comment explained precisely why.

You're complaining that there isn't good tooling around the config file format for a project that is described as "in its early development stages" and provides "alpha releases". If you're talking about using this "while building business solutions on somebody else's dime" your getting way ahead of yourself. I'm sure they will expose a library for parsing and editing the config format before a general release.

You're right, I can't find a python library with the exact functionality you want. But a solution does exist, you would just have to write it yourself. It takes about 200 lines of python, less if you use a parser generator. But if you don't want to do that (nothing wrong with that! Why do work when you don't have to, after all), well then you'll have to either ask someone else to do it for you or just not use this project, assuming this functionality is critical for you. Or you could use sed or a templating system, up to you.

I have little doubt it could be written, but at risk of going blue in the face, this was irrelevant to the original question ("what do you dislike about this syntax?"). Never mind, 'truth' has won out in the end regardless, and I note for future that the presence of Lisp on a CV is fair reason to pause and reconsider.

"My first thought is how I'd parse, modify and write it back without losing user's comments, formatting, changes and suchlike. Is this some well understood format with libraries for common programming languages?"

Sorry for trying to answer your question then...