Yep. It's great. The awesomeness of JSX/TSX without having to deal with client side JavaScript frameworks and their awkward state management systems (does anyone actually like hooks?).

Screenshots. Print screen. Wayland famously doesn't have a way to do this very basic task (all of the desktop environments had to add custom extensions).

Seems like they finally did it though really recently. And it only took 12 years!

I think either is probably fine. Apparently the French stress the syllables equally, not just the second so it's a minor difference.

Actually I just listened to the French pronunciation and it sounds more like they do stress the first syllable to me:

https://youtu.be/fN1VwDpxbXQ?si=1VcffgqbwRelS8zY

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.

Pip and venv have been tools that I’ve found to greatly accelerate dev setup and application deployment.

I'm not saying pip and venv are worse than not using them. They're obviously mandatory for Python development. I mean that compared to other languages they provide a pretty awful experience and you'll constantly be fighting them. Here's some examples:

• Pip is super slow. I recently discovered uv which is written in Rust and consequently is about 10x faster (57s to 7s in my case).
• Pip gives terrible error messages. For example it assumes all version resolution failures are due to requirements conflicts, when actually it can be due to Python version requirements too so you get insane messages like "Requirement foo >= 2.0 conflicts with requirement foo == 2.0". Yeah really.
• You can't install multiple versions of the same dependency, so you end up in dependency resolution hell (depA depends on foo >= 3 but depB depends on foo <= 2).
• No namespace support for package names so you can't securely use private PyPI repositories.
• To make static typing work properly with Pyright and venv and everything you need some insane command like pip install --conf-settings editable-mode=compat --editable ./mypackage. How user friendly. Apparently when they changed how editable packages were installed they were warned that it would break all static tooling but did it anyway. Good job guys.
• When you install an editable package in a venv it dumps a load of stuff in the package directory, which means you can't do it twice to two different venvs.
• The fact that you have to use venvs in the first place is a pain. Don't need that with Deno.

There's so much more but this is just what I can remember off the top of my head. If you haven't run into these things just be glad your Python usage is simple enough that you've been lucky!

I’m actually in the process of making such a push where I’m at, for the first time in my career

Good luck!

We use it for triaging test failure (running tens of thousands of tests for CPU design verification).

That use is acceptable because it is purely informational. In general you should avoid regexes at all costs. They're difficult to read, and easy to get wrong. Generally they are a very big red flag.

Unfortunately they tend to get used where they shouldn't due to lazy developers not parsing things properly.

There aren't many good cross platform GUI toolkits. I mean realistically is there anything other than Qt?

Yeah I get what you're saying. Gitlab can pretty much do that too, you just need a branch & MR for each commit, and then you tell it to merge each branch into the previous one. It automatically rebases them when their dependency merges.

Definitely more tedious to set up than just pushing one branch though. Maybe I should make a tool for that... Does Gerrit test each patch in CI sequentially or just all of them together?

But in any case that wasn't really the problem I was talking about. What I'm saying is that whether or not you should squash a branch depends on what that branch is. Neither "always squash" not "never squash" are right. It depends. And developers seem to have a real problem with knowing when a change is important enough to warrant a commit.

Though I suppose if people have to actually review each commit they would get a lot more push-back to "fix fix fix" type commits so maybe you are right.

Does Gerrit require each individual commit to be approved or can you just approve the whole branch/changeset?

Yeah I agree but in my experience developers seem to struggle with "keep important things in history; squash unimportant things". An open "merges allowed" policy leads to people unthinkingly merging branches with 50 "typo", "fix" commits for a 100 line change.

Dunno what the answer is there.

They're not that simple because of packfiles. But yeah loose files are very simple. Also the documentation for packfiles is pretty bad. You end up reading other people's random notes and the Git source code. (I actually have written a Git client from scratch.)

foo isn't a function, it's a bool. But in any case, as you can see the answer is "with terrible hacks". Python is not a functional language. It is imperative.

It's not. In functional languages there's no special case like this. All if-elses are expressions. It's far superior. For example how do you do this with Python's if-else expression?

let x = if foo {
  let y = bar();
  baz();
  y
} else {
  z
}