I also strongly dislike the idea that static type systems are only being added to Python because spoilsports from other languages are forced to use Python and don't want to. Not true. That's especially strange considering Python is one of the only traditionally dynamic languages that has mostly led it's own static typing system, joined mainly by just PHP in that regard. Why does it not support features like kwargs? Dunno. TypeScript has no trouble supporting
tons of JavaScript patterns you could
never do in other languages, even C# from which it is heavily influenced due to its heritage, and TypeScript is a fully separate effort from JS.
On the contrary, static typing in Python is still extremely nice to have. When I was at the peak of my Python career, I had a bug where I changed the return type of a function to be a tuple, and somehow unit tests missed one of the worst possible invocations, leading to an awful failure that occurred after a payment was processed but before actually completing the task, causing it to be retried repeatedly. To be clear, like any failure of this nature, it is one caused by many different problems, and we employed many different solutions; we started paying attention to test coverage, we began using MyPy (it was still quite new; this was also in Python 2 so it needed type erasure compilation among other things) and we made our payment processing logic more robust to prevent processing the same payment twice even in the case of everything else (like retry logic) failing to stop it again. But the thing that sucks is, fairly simple type inference without any additional type annotations could've detected that sort of bug without a potential for false positives.
So I feel like it's silly the way that some dynamic language proponents feel like static typing systems on top of dynamic languages is all from outsiders. On the contrary, the relative weakness of MyPy is actually what ultimately made me quit using Python, and if I had to use it today, then yes, of course I would opt for the highest degree of type safety, as a primary concern above being "pythonic." I like pretty code, but I like correct code more.
Sometimes this does prevent "better" solutions from working, but in my opinion nearly 100% of the time that this is the case, it's because:
- The type system in question is not sufficiently advanced to express the types elegantly.
OR
- The approach is inherently not safe and probably not a good idea. Like patching the request object inside of middleware in Django, for example.
I think TypeScript proves that with a sufficiently advanced type system, even arguably bad ideas can be type safe. For example, the ability to express dotted object paths safely in modern TypeScript is pretty impressive, and lets you map out older JS that does this accurately, but in general that seems like an unnecessary trick that will just make your code slower at runtime for the slightest terseness improvement over alternatives, lacking a language with sufficiently advanced metaprogramming.
The thing is though, eventually this thought process comes true. If a given programming language community winds up bleeding members who are moving on due to the lack of better static type checking systems, then the people left will invariably be much more likely to be against static type systems.