> It allows you to find bugs in your code without running it. I’ve concluded that my workflow must be different from people who make this claim - I never write code without testing it.
Neither do I. IDE integrated typecheckoing still finds the kinds of bugs typing can find faster than IDE integrated unittesting, and often as they are being typed.
> This is more comprehensive than relying on a type checker, because it finds all kinds of errors, not just type errors.
It's still slower for the very broad class of errors a typechecker can highlight than static analysis, and unless you are very good at writing tests, far less comprehensive in that subcategory.
> It’s a form of documentation of function parameter and return types. This is better served by comments, because type hints are usually inaccurate in a duck-typed language like Python.
Conversely, it's better served by analytically confirmed annotations, because comments are usually inaccurate in most languages.
> For example, I see hints like `def twice(x: int) -> int: return x+x`. The correct type for a function like that isn’t `int`, it’s something like `addable`.
It's `int` if that's the promise I want to make to users that they can rely on and that I will fix bugs against and that I will adhere to in future changes that aren't SemVer major. That the implementation can supporting something broader is a private detail, not part of the API presented. It might use an optimized routine that relies on implementation details of Python ints tomorrow and just be using + today because correctness and delivery schedule beats optimization in this case. In fact, that possibility would be the only reason to a abstract something a simple as application of a simple binary operator
OTOH, I frequently see argument or return value specs in comments that include types that are plain wrong, not subsets of what the underlying code supports.