I too would much rather work in a statically typed language, but sometimes you have to work with what you’ve got.
These systems are part of the core banking platform for a bank so I’d rather some initial developer friction over runtime incidents.
And I say initial friction because although developers are sometimes resistant to it initially, I’ve yet to meet one who doesn’t come to appreciate the benefits over the course of working on our system.
Different projects have different requirements, so YMMV but for the ones I’m working on type hints are an essential part of ensuring system reliability.
I'm not opposed to type hints, I use them everywhere. It's specially the strict linting.
But it's a fair point. If you truly have no option it's better then absolutely nothing. I really wish people would stop writing mission critical production code in Python.
I feel like it's more often a result of suffering from success that leads to these situations, rather than a lack of foresight to begin with.
For example I work on a python codebase shared by 300+ engineers for a popular unicorn. Typing is an extremely important part of enforcing our contracts between teams within the same repository. For better or for worse, python will likely remain the primary language of the company stack.
Should the founder have chosen a better language during their pre-revenue days? Maybe, but at the same time I think the founder chose wisely -- they just needed something that was _quick_ (Django) and capable of slapping features / ecosystem packages on top of to get the job done.
For every successful company built on a shaky dynamic language, there's probably x10 more companies that failed on top of a perfect and scalable stack using static languages.
A statically typed language doesnt prevent developers from using the equivalent of dict[str, Any].
Well, some do. Let's not pretend all static type systems are the same.