Uv is the best thing to happen to the Python ecosystem in a decade

I'm not sure immortality is a good standard to hold forks to. the original project won't last forever either.

You updated _production_ before _testing_? Sorry but that just sounds like asking for a disaster.

Many competent contributors have left or were silenced by the politicians. PyPI had multiple severe vulnerabilities. pip has no adequate story for the scientific ecosystem. Building from source via pip usually fails, unlike around 2010 when it usually worked.

The only thing that prevents lock-in is the religious zeal of most Python users to use anything presented by the PSF high priests, not technical merit.

The reason uv exists is the utter incompetence of PyPA.

It seems like you're reading things that people aren't writing.

I don't know how the author's company manages their stack, so I can't speak to how they do their testing. But I do know that in many companies run-time environment management in production is not owned by engineering and it's common for ops and developers to use different methods to install run-time dependencies in the CI environment and in the production environment. In companies that work that way, testing changes to the production runtime environment isn't done in CI; it's done in staging.

If that's at all representative of how they work, then "we didn't test this with the automated tests that Engineering owns as part of their build" does not in any way imply, "we didn't test this at all."

Tangentially, the place I worked that maintained the highest quality and availability standards (by far) did something like this, and it was a deliberate reliability engineering choice. They wanted a separate testing phase and runtime environment management policy that developers couldn't unilaterally control as part of a defense in depth strategy. Jamming everything into a vertically integrated, heavily automated CI/CD pipeline is also a valid choice, but one that has its roots in Silicon Valley culture, and therefore reaches different solutions to the same problems compared to what you might see in older industries and companies.

> the lack of update operators (like `a ||= (i > 0)`)

What would that even do? Is that the equivalent of `a = a or (i > 0)`? Python does not have a "||" operator.

> the `a if b else c` confusion

I'll agree that Python really dropped the ball on implementing a ternary operator, but I guess Guido really didn't want the C version.

> the weirdness of comprehensions (particularly nested `for`s)

If a comprehension is getting weird because of nesting, then I'd change it to not be a comprehension. I'd rather have nested `for` loops than nested comprehensions.

> the exceptions that are raised for non-exceptional cases

I'd be interested in an example of this.

> like trying to delete a non-existing dict entry (need an additional `if` or a `try` block) or access a non-existing map entry (need to use `.get()` instead of `[]` or a `try` block)

I suggest thinking more about the Zen of Python. Specifically, explicit is better than implicit, and errors should never pass silently. If you're trying to delete a non-existing dict entry, or trying to access a non-existing entry, then in most cases, you have a bug somewhere. Basically, Python believes that your code is expecting that dict entry to exist. Forcing you to use .get or use an `if` is a measure to make your code explicitly declare that it's expected that the dict entry might not exist.

> But if I write `a = b +` in Python on one line, then I get a syntax error [..]

Yeah, the parser could certainly be written to handle this case, but it was deliberately written not to.

> It feels to me like a dangerous toy language

Toy language, I could see. Dangerous? Not at all. I could call it opinionated, though.

> and I am never sure which of my stupid mistakes will be found by the compiler/interpreter, and which will just silently misinterpreted.

Meanwhile, I'd look at C and think "I'm not sure which of my mistakes will lead to a memory leak or an exploitable buffer overflow."

> In some aspects it feels less safe than C, particularly due to the lack of scoping and the danger of reuse of variables or introduction of new function local variables when actually, outer 'scope' variables were intended to be written.

I'd argue the exact opposite: It's more dangerous to allow you to accidentally clobber a global variable when you meant to create a local one.

> This is not really meant as a rant, but it is a personal opinion, and I try to lay out my reasons.

I think the core issue is that Python tries to adopt a different paradigm than languages like C, and it's a paradigm that you just strongly disagree with. Personally, I love it. What's funny is that when I first saw Python, I was like "This language sucks, it makes things too easy and it holds your hand." After using it extensively at work though, I find myself saying "This language is great! It makes things so easy and holds your hand!"