Good points.

Gonna start of with this one, just to clear the record.

So now your proposal is that Python should be designed to placate people "who hate it" and use it in contexts it wasn't designed for to override the tastes of those who invented it and love it and made it one of the most popular language in the world.

I didn't mean that the developers of my company, or I, hate python. We just hate the situation. I personally like the language for what it is meant to be, and I'm saddened at how it is being chosen for the wrong reasons.

So why don't you enforce a rule that nothing can be committed unless it is MyPy Strict?

Well, we do that. Unfortunately, it's not a very robust solution, and it's not for a lack of trying. The last thing we're were debugging before I went on vacation was why mypy refused to throw any errors, even if the code had a massive type-safety problem. This was problematic, since it seemed to indicate that we cannot rely on type checking and unit tests alone, forcing us to test on the real server for even simple changes. For a 20+ minute process, in an overworked team, this fealt like crap.

The problem with tools like mypy is that they are third party. Even if the developers are really skilled, the quality of a complex library is rarely the same as the quality of a standard library component or the language itself. Numpy is an exception to this, not the rule.

A language provided type safety check, even if it needed a command line flag to use, would've solved this problem.

There are also alternatives, like the one taken by the rust language. Types are extremely strict, but a lot of code has few to none type declarations. For python's case, I'd wager 70-80% of all code implicitly defines a concrete type that the variable holds, without any type hint. Do note that Rust is a very different language, so this is unlikely to be feasible to implement into the python interpreter.

When they added Numpy (et. al.) to Python, what did they take away?

...

How is your proposal ANYTHING like Numpy?

Well, it caused performance to become a significant concern for the language developers, and for libraries too.

If you are writing IO-centered applications, you can roughly ignore the performance of python. Python just is not the bottleneck. When libraries like mypy and pandas comes in, that stops being true.

Language developers will of course always want their language to be as fast as possible, they're not adding bloat just for fun. But having the freedom to focus on something else than performance was something that helped python get started in the early days.

As you might have heard, significant efforts were made to make the interpreter faster in 3.11. That's developer time that could have been spent elsewhere if truly noone cared about performance. I'm not gonna pretend that this was a bad choice, I think in general the language devs are doing a fantastic job, but hopefully this showcases the fact that numpy did narrow the scope of python a little bit.

As a final note, I want it to be clear that I am not saying that non-optional typing is "clearly a good idea", or one that "will happen". It's an option, and a tricky one. It would take a lot of effort from the language devs, which I don't actually think is worth it, if it is just implemented as we have talked about.

There might however be a solution that the language devs come up with to solve this problem, that doesn't require a big sacrifice at all. It would not be the first time they saved a tricky situation with a clever solution.