To me it feels like python is running as far away from simplicity as fast as possible.
To me it feels like python is running as far away from simplicity as fast as possible.
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.
def resize_image(image, width, height, strategy):
pass
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.
In the field, Python stays mostly simple. All those stuff are optional, and they are used in this spirit.
In fact, most Python code I see out there seldom even use lambdas, comprehension lists or yield.
You gotta remember a huge part of the Python user base are not programmers, and they don't have the time to figure those things out.
That's one of the reason of Python success: it scales up, and it scales down.
> 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.
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.
[1] https://mail.python.org/pipermail/python-dev/2015-April/1392...
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...
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.
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.
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.