Reasons to avoid static type checking in Python
typing.readthedocs.io
Reasons to avoid static type checking in Python
1–10 of 60 posts
Re: Reasons to avoid static type checking in Python
#2[flagged]
Re: Reasons to avoid static type checking in Python
#3Feels like a bunch of BS excuses.
Re: Reasons to avoid static type checking in Python
#4[flagged]
So are dozens of statically, strongly typed languages. I’d rather write Python than php or c++.
Re: Reasons to avoid static type checking in Python
#5> Pleasing static type checkers requires a non-zero amount of busy work
Heck yeah! Why would I want to find problems ahead of time when the whole thing could blow up at runtime with cryptic errors. Or better yet, no errors because I’m such a ducking elite programmer that I never make mistakes. Read the code. The code don’t lie!
This is a lame, low effort blog post. Jesus Christ.
Re: Reasons to avoid static type checking in Python
#6Re: Reasons to avoid static type checking in Python
#7I eagerly await ruff-but-for-type-checking. Python type checkers are all excruciatingly slow at the moment.
Re: Reasons to avoid static type checking in Python
#8Feels like a bunch of BS excuses.
Which is great as it documents that there aren't any real ones.
Re: Reasons to avoid static type checking in Python
#9Feels like a bunch of BS excuses.
Yeah the formulation is quite biased, but to some extent there is some truth in the statements:
> Your codebase is old, large and has been working fine without static type checking for years. While Python’s type system is designed to allow gradual adoption of static type checking, the total cost of adding type annotations to a large extant codebase can be prohibitive.
That's a convoluted and quite dishonest way of warning that you're trapped if you don't enforce types from the start; but it does have the merit of being on the list.
Re: Reasons to avoid static type checking in Python
#10I eagerly await ruff-but-for-type-checking. Python type checkers are all excruciatingly slow at the moment.
Yep. Speed is one factor, but also standardisation.
I’ve always been using mypy, but heard good things about pyright. It’s what VSCode uses by default as well, unless you jump through hoops. So I have pyright in the IDE and mypy everywhere else, yet they don’t agree with one another in various cases. Exhaustiveness checking and type inference in structural pattern matching, and async TaskGroups are some examples. One of my code bases has mixed “type: ignore” and “pyright: ignore” (forget the exact syntax) for that reason. Pretty bizarre and not something you’d see in any other language!
I wonder why mypy isn’t the blessed standard and pyright was able to catch up on (and in parts overtake) it. Mypy had a large head start and enjoys tons of development effort. Good job to Microsoft I suppose?