> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006.
true.
i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be.
we are starting to look like a heavily templatized cpp code.
Type annotations help catch common errors, and they help humans. Maybe it's not as pretty but as someone who often have to read Python, it really helps me understand what the contract is of a function I'm looking at.
As a big fan of statically typed languages, I agree with you on the utility. Especially after having worked on a large Python projects a few years ago and having to spend a lot of time figuring out what, exactly I could do with a argument named “session”. But when you start turning your dynamically types languages into an ugly statically typed one, maybe we should just admit that we’re using the wrong tool for the job.
Is the point where your Python codebase needs type hinting to be readable a signal that you've hit the dynamic language/complexity impedance mismatch?
Or is it a sign that your code's readability could be better?
Your "session" remark reminds me of trying to understand the Ruby IMAP library when the only documentation was autogenerated API docs, I had to follow one variable through the entire stack to figure out what it's original type and thus capability, was.
I taught myself to code in Python, and find that well-written Python makes sense without types (tooling support aside), but then being honest, most of the Python code I meet professionally, is barely okay written.
I guess it's like Java, industrial programming code needs a type system to make code written averagely understandable, but not so much of a type system that you spend your time fighting obscure compiler errors.
Don't mix things, guy!
- asyncio it's one thing: From my point of view it's amazing... makes python be able to compete with nodejs or go.. (not so hard, if you work also on the browser)
- mypy: that's another story, but it's also optional, use it if you want... (my opinion, like in typescript, if I want types I will do it with go or rust)
Honestly, after trying MyPy for a bit, I'm probably going to gradually type. There's some metaprogramming constructs (notably certain class decorators) that are not expressible in the type system, for one. This makes packages like environ-config unusable.
But most importantly, `def foo(lst: list, idx: int):` is fine in 95% of cases. Most of the time, you don't need to go full Java, full verbosity. Document the most important elements - you're taking in a list and an int - and move on.
(Though yeah templates in C++ turn the ugliness to 11)
Not to mention Python is "strongly-typed". But it doesn't require variables to have a pre-determined type and doesn't do compile time type checks by itself.
true.
i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be.
we are starting to look like a heavily templatized cpp code.