>>11706986>This is much more clumsy than having first class static typing. It makes keeping up on your types a burden rather than a happy symbiosis between developer and type checker.I'd argue the opposite, honestly.
Python's typechecking is relatively more descriptive rather than prescriptive compared to that of primarily statically typed languages. It's designed to work well with the patterns people already use, rather than forcing them into new ones.
You get ergonomic sum types, with advanced detection for when you narrow them down. You get type inference even for containers that are initially empty. You get protocols, which are like interfaces that are detected whether or not they're explicitly part of the class definition.
It doesn't feel like any more of a burden than keeping up with types in a statically typed language.
>You get the worst of both unless everyone tries to use static typing all the time. Optional dynamic typing is far better because the biggest benefit of static types is only felt when almost the entire program is statically typed. This benefit being a massive improvement in developer intuition about what's happening out of their current view.If you use static typing you're better off using it throughout your program, not just part of it. I agree with that.
But even in that case it can help that it's optional. I like to add type hints only once my code starts to stabilize.
This is a sequence I often go through with new projects:
- Rapidly iterate through different ideas without static typing and without much worry about breaking things, until I find an approach I'm happy with
- Add type hints everywhere to sort out all the edge cases I missed and so on
- Refactor the program now that the type hints make that safe to do
The first stage goes much quicker than it would with static typing. The code doesn't have to work well yet, and I still remember the way everything works because I just wrote it, so type hints aren't worth the trouble yet.
