I dunno it looks well designed but I dunno why I would use it instead of Rust.

I've never done it but apparently you can actually gradually transition to Typescript one file at a time by renaming them from .js to .ts. Might help a bit. Good luck anyway!

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

They do have a ton of tests actually. In their defence, if this task is doing Git things then just killing it when it goes badly is probably the best you can do. Git itself is quite buggy if you stray from the most basic setup. I've had it almost completely destroy my .git directory in the past when using submodules.

On the other hand, Gitlab itself is an enormous entirely untyped Ruby monster, with extremely difficult to follow code. Not in terms of individual functions - except for the lack of types mean you can't really know what they do, they are quite clear and well written. The issue is the control flow between parts of the system. It's difficult to know what calls what, so I'm not surprised they occasionally have to give up.

I had a play with Deno's Fresh web framework recently (Typescript/TSX but mainly server rendered). IMO it's light years ahead of other solutions.

You get full amazing Typescript typing, including in templates (unlike Go for example), but unlike React you don't have to deal with JavaScript tooling or complex client side state management. It's a real breath of fresh air. (Ha that wasn't even intentional.)

Yeah I would avoid this. The meaning is not obvious and at least in the examples given there are far better ways to do it.

Nothing else has code completion that even comes close to being that good.

Well, except Visual Studio (for C++), Qt Creator, and every Java IDE in existence.

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).

I was going to say there are about a gazillion free Git tutorials so this seems like a strange thing to charge quite a lot of money for. But it does look very well done.

Git is a graph of commits and you can't really display a graph in any way except visually. Even the CLI has a way of showing it visually (git log --graph).

Think about other graphs you might interact with, e.g. node graphs in 3D graphics of music production. How many of them do you manipulate with a CLI?

This can work for junior devs who aren't stuck in their ways. Unfortunately there are too many "senior" devs who are happy making crap. It's hard to fight them constantly to do things properly (e.g. write actual commit messages rather than just "Fix #836") so using tools like linters where possible is definitely a big improvement.

Note that worktree does not work with submodules. Which IMO is a strong enough reason to never use submodules because worktrees are so useful!