No but I think this is probably a great use case for AI. Haven't tried it though.

It doesn’t look like it would be hard to have (comment "foo bar baz") in an expression

That is pretty much what the official "solution" is for comments in package.json - add "//": "foo bar baz" keys to dictionaries and NPM will ignore them.

In practice it's terrible. You need real comments.

One nice thing about XML is that there's an official way to link to the schema from within the document. If you do that you can easily automatically validate it, and even better you get fantastic IDE support via Red Hat's LSP server. Live validation, hover for keys, etc.

It's a really nice experience and JSON schema can't really match it.

That said, XML just has the wrong data model for 99% of use cases.

It really depends on the domain. E.g. I wrote a parser and copilot was tremendously useful, presumably because there are a gazillion examples on the internet.

Another case where it saved me literally hours was spawning a subprocess in C++ and capturing stdin/out. It didn't get it 100% right but it saved me so much time looking up how to do it and the names of functions etc.

Today I'm trying to write a custom image format, and it is pretty useless for that task, presumably because nobody else has done it before.

Yeah that's pretty unreadable IMO. I think your second link isn't what you intended?

It's definitely not cheating. But you also do need to understand what you're doing.

I agree. Even when copilot gets something completely wrong it's usually easier to think "no that's wrong, it should be this" than "ok the first line of code should be...".

It completely solves the "blank page" problem.

When they say global state here it's not really global state, it's class members - global to the class. "Why are they calling it global state then, idiots?" you might think. It's because it prevents local reasoning in the same way as global state does (and most people get the implications of "global state" because of experience, so it's a kind of shorthand).

Of course, not many people would recommend "no class variables" (in a classic OOP language anyway), but the point is they have similar downsides to global variables in terms of understanding code (and testing, etc.) so recommending to always use them - even when passing state in and out of functions is perfectly ergonomic - is clearly bonkers.

In fairness for the invalid escape sequence thing static linters (Pylint, Pyright, etc.) should be already telling you about it.

threading bugs are sometimes hard to catch

Putting it mildly! Threading bugs are probably the worst class of bugs to debug

Definitely debatable if this is worth the risk of impossible bugs. Python is very slow, and multi threading isn't going to change that. 4x extremely slow is still extremely slow. If you care remotely about performance you need to use a different language anyway.

Interesting I hadn't heard of these "atomic" distros. There isn't really much description of what exactly is atomic about them though - all you get is "The whole system is updated in one go". Can you explain it?

I can give you some basic Python set-up advice (which is hard-won because nobody tells you this stuff):

1. Use pyproject.toml, not requirements.txt. It's better and it's the recommended way.
2. Always use type annotations. I saw you used it a bit - well done! But just use it everywhere. Add declarations & type annotations for your class member variables. You'll thank me later! Also prefer Pyright to Mypy; it is far far better (and the default for VSCode).
3. I would recommend using Black to autoformat your code. It's easily the best Python formatter. You can automate it using pre-commit.
4. ALWAYS PUT MAIN IN A FUNCTION. You should not run any code at a global scope. Do it like this:

def main():
  ...

if __name__ == "__main__":
    main()

There are two reasons:

1. Generally it's good to keep variables to the smallest scope possible. Putting everything in a global scope will just mean people start using it in their functions, and then you have a mess.
2. Any code you put in a global scope gets run when you import a module. Importing a module should not have any side effects.

Other minor things:

1. Path has a crazy/neat override of the / operator so you can do Path("foo") / "bar" / "baz.txt".
2. Don't use assert for stuff that the user might reasonably do (like not choosing a background image). assert is meant to be for things that you know are true. You are asserting them. Like "hey Python, this is definitely the case".
3. TK is an ancient shitty GUI toolkit. I would recommend QT instead (though it will probably be more pain to set up).