Don't let perfect be the enemy of good. Type hints are usefull especially in large codebases. I find myself using them with minimal effort and they can catch bugs that otherwise wouldn't be catched.
Python’s “type hints” are a bit of a disappointment to me
271–280 of 597 posts
Re: Python’s “type hints” are a bit of a disappointment to me
#272Re: Python’s “type hints” are a bit of a disappointment to me
#273Earlier quoted context omitted.
Not with any TSC settings I've ever used.
noImplicitAny is a very common config option that helps catch a ton of bugs. I wouldn’t use TS without it.
There are lint rules to avoid typing as `any`.
Re: Python’s “type hints” are a bit of a disappointment to me
#274this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…
I don't think this follows by definition. It's common not to check the static hints at runtime, but a dynamic language could choose to treat them as contracts or assertions. Over in Lisp-land, SBCL will enforce static type declarations at runtime [1], contrary to most other Lisp compilers, at least under the default compilation settings (you can force it to skip the checks by compiling with a low "safety" level). If the compiler can prove that a static type declaration always holds, it will omit the runtime check; otherwise it will compile it into a runtime assertion.
Re: Python’s “type hints” are a bit of a disappointment to me
#275I agree. I'm glad that they're optional. One of the main reasons to use Python is to prioritize development speed over performance AND to prioritize read/write-ability over hand jamming mundane syntax. I understand why some who have a background in typed languages might prefer to use Python with type hints, but it should be understood that they aren't very Pythonic.
def create_user(user):
other_function(user)
Then how do I know what `user` is? Is it a dictionary? An object? If it's an object, where's its class definition? To find the answer I need to search for all the code that calls `create_user`, and then code that calls that code, and then code that calls that code, ad nauseam.Onboarding into a huge, untyped codebase is brutal
Re: Python’s “type hints” are a bit of a disappointment to me
#276Earlier quoted context omitted.
The problem I see is that you are trying to peg a square in a round role and thinking that the square is at fault for not being flexible enough. Anyone that has seen the py2 -> py3 debacle will tell you that "let's make python static" is not something that could happen unless you are willing to rewrite the entire ecosystem of libraries and applications, and quite possibly upsetting the majority of current users who w…
I don't want to turn Python into a statically typed language. I think there's valid criticism to be made about the flaws of its type hinting (as does the article's author), and I cannot help but compare its usefulness to static type checking. I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.
But given that your response to the mypy recommendation was to complain (it's slow, it doesn't catch everything) then it makes it difficult to acknowledge the "valid criticism"... as in: people are working on it, what else do you want?
[0] https://mypy.readthedocs.io/en/stable/existing_code.html
Re: Python’s “type hints” are a bit of a disappointment to me
#277And now, just a few years later- Rust, Go are two of the hottest languages around, TypeScript is eating JavaScript, Python/Ruby have added static typing constructs, C# continues to do well in its niche and even Java of all languages has become somewhat cool again even though being Oracle product.
It's been an amazing transition to watch in action play out in front of my career, I can't even imagine those who have been in the industry for 30-40years who have probably been through a dozen of these cycles.
Re: Python’s “type hints” are a bit of a disappointment to me
#278I love type hints. They make the code so much more readable. I wish they could do more, but knowing what the programmer intended for a variable is huge. Now, when I see code without type hints I think, "Oh man, now I have to dig into everything to know what anything is."
Re: Python’s “type hints” are a bit of a disappointment to me
#279Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…
Nice. How do you force types just in the new code?
git diff -U0 --relative origin/master... | flake8 --diff --select
I'll leave the flake8 plugin as an exercise to the reader as ours is intertwined with code I can't share right now.
Re: Python’s “type hints” are a bit of a disappointment to me
#280I find it interesting how we have come full circle on static typing. When I was in University 2009-2013... and years leading up to it, dynamic typing was becoming the hot thing after years of Java/C/C++ dominance. Statically typed languages were looked down upon and talked about as being analogous to "Enterprise", "suit and tie" type soul crushing software development. We had people fulling in Ruby/Rails bandwagon, J…
And maybe a few more decades after that to go back to the dynamic typing of the 1950s, like that of Common Lisp. :)