I don't understand why anyone would want type hints. It makes the code so ugly and complex. Pythons appeal for me was always that it is "runnable pseudocode" with a strong object system and great libraries.
To me it feels like python is running as far away from simplicity as fast as possible.
The perfect level for types is at the function or interface level.
I'm not a PL theory guy (so correct me if I'm theoretically wrong), but it turns out you can usually infer types for everything as long as methods and functions are annotated. It only breaks down in the case of complicated generics or heterogeneous containers, and in those cases often only when there are chained method calls that prevent inference of the intermediate calls.
Typing at the function level is extremely useful for all languages, both statically and dynamically typed. Python, TypeScript, Rust, Java, etc. all benefit.
A broad class of errors are caused by passing the wrong types into functions. In scripting languages, these creep in due to mistakes or refactors. Types on functions can prevent this. It also helps you avoid writing tests or precondition checks for the wrong type of input.
Speaking of refactors, having type information on function calls lets you do codebase-wide function signature changing, method renaming, etc. with the assurance you won't break your code or miss any calls. It's a killer feature.
Even if you gained nothing from the practice, you always want to know what you're required to pass a function.
What do any of those parameters mean? Do you want to rely on documentation? That can get out of sync, especially during refactors or in multi-engineer projects.
Types on functions are the way to go. Once you try it, you'll never look back.
Well, before, I had docstrings that describe the interface and what types it would accept. Now I do the same, more compactly and easier, using type hints. And since it's machine readable, linters can how help you to identify some simple problems. I think it's a win all around. I think the right way to look at type annotations is as part of the documentation, not as part of the code.
Spot on. Static typing has benefits, but it also has a cost. Python's optional type hints have all the complexity but only some of the benefits - in my experience, runtime type errors are still common.
> To me it feels like python is running as far away from simplicity as fast as possible.
Despite its reputation, Python hasn't been a simple language for a long time.
There really is a cost, in the form of having to rerun code a dozen more times to catch unresolved type errors. But AFAIK, that's it. Can I ask what I'm missing? What cost of this (optional) static typing are folks talking about?
IMO this is worth it, since the goal is less about eliminating runtime errors or other errors, and more about encouraging documentation in code rather than in comments/docstrings. This makes reading code simpler, not less so.
In a language like Python that encourages duck typing, type hints can become extremely complex [1] and can get in the way of the ideal of "executable pseudocode" [2].
Thanks for the links! Those fully specified frankentypes are indeed atrocious, and no sane person should ever need to read them. That being said, isn't "Any" meant to act as a wildcard, used precisely for ignoring the unimportant parts of the type? Specifying huge and rigorously correct types just seem like an eager misuse of type hints to me.
At the same time, adding the capabilility for complexity the language does encourage complexity, doesn't it? (Rust comes to mind.) So I admit what I just said isn't much of an argument -- frankentype hints _will_ be written, and therefore we _will_ have to suffer them someday...
[2] is (1) horrifying, and (2) descriptive of something Python is really good at (handling complexly-typed input datasets without requiring complex declarations).
The solution to that code is to remove the type hint, because you don't need it, because it simply describes the type of the input data.
edit: Several far better Python developers than I also said as much in the tweet replies.
Does anyone think it is a good idea to accept anything with a __str__ in requests.get? That seems like an awful idea. I am more of a dynamically but strict kind of guy, and this seems like a good way to get weird behaviour.
Simplicity comes at a cost. The pros of simplicity outweigh the cons in many cases for a small codebase. On the other hand, I have a lot of difficulty wrapping my head around how you scale a dynamically typed program with a large codebase without driving yourself crazy.
Because people like to find type errors at compile time, not runtime, they want to know which types a function uses, and they like to have usable code intelligence in their IDEs (code completion, find usages, rename symbol, etc.). VSCode with Pyrite is the best option I've found for this. It makes Python feel less like stabbing in the dark.
The fact that you like Python for being "runnable pseudocode" suggests to me that you only use it for very small scripts, in which case it is true you don't really need static types or type hints. But many people use Python for much larger programs and in that case it is really indispensable.
The amount of mental overhead that type hints reduce is staggering. I love being able to interrogate a variable, function or class and learn about its properties right in the IDE, or have autocomplete let me mangle the name of an attr and tab-complete and correct it (regardless of lang). The alternative is going back and forth from documentation to code, and having to type everything perfectly.
Even just a smattering of type hints helps dramatically, as a few well placed hints on the APIs I know the least, gives me a huge boost.
To me it feels like python is running as far away from simplicity as fast as possible.