4 ms·
I've found that even when I write code intended to be statically checked from the beginning, mypy often misses stuff. I was enthusiastic about mypy at first an
by throwaway81523 5y ago
I've found that even when I write code intended to be statically checked from the beginning, mypy often misses stuff. I was enthusiastic about mypy at first and I still use it, but I'm not sure at this point that it is worth it.
- the_af 5y agoSame here. And I come from (and am a fan of) statically typed languages. The type hinting story for Python seems confusing and not completely useful to me.
- seti0Cha 5y agoI just started using type hinting in Python and I love it. Maybe it's your tooling? I'm using neovim with LSP and pyright and the experience is very much like writing code in a Java IDE. As I code, it informs me where there are mistakes or pieces of code that need to be updated, catches typos, reminds me about forgotten imports, etc. It makes refactoring way easier because as you change signatures or object types it flags all the places in your code that need to be updated. Seems like a real game changer to me.
- the_af 5y agoI want automated type checking outside the IDE. I want something that will catch other programmer's mistakes, not just mine. Without enforcing a specific IDE.
- seti0Cha 5y agoLSP support exists for many editors so you are not tied to a specific IDE. It can catch other programmers mistakes if you run it against their code. It doesn't turn Python into a statically typed language, but it's a lot better than nothing.
- the_af 5y agoSorry, I wasn't clear. I don't want to mess with each individual developers IDE or setup. I want to enforce type checking at the same place we also run mandatory tests: in the automated build pipeline (think CI/CD).
- throwaway81523 5y agoNo it's not the tooling, unless by tooling you mean mypy. The issue is that you can write code with type errors that mypy doesn't catch. In what I usually think of as static typing, that would be impossible: type errors are simply not allowed, even if that means the compiler rejects some otherwise-valid code. I think mypy has to let some potential errors through because otherwise it would spew 1000's of spurious error messages on perfectly good, unannotated legacy code. Something similar happens with the Erlang dialyzer. The same thing applies to tools like Coverity, that aim to find potential bugs in legacy C code. You could instead imagine a version of mypy that makes no concessions at all to legacy code, and insists that your code be 100% free of type errors, even if that means that some older constructs and styles no longer work. Would that be a good thing? Probably not: we have Haskell for that. Mypy's leaking errors is probably a practical necessity in retrospect. But, I wasn't expecting the leakage, so it surprised and disappointed me when I encountered it. I had thought I was getting something more like Haskell. Mypy still has attractions, but it's less great than I had hoped.
- noitpmeder 5y agoI think this is only going to happen in reality if you're doing funky type hacks in the first place. Mypy definitely has rough edges, but it works perfectly in 95% of every codebase I've seen. Type hints (with mypy) aren't going to save you from becomming a bad programmer. But they _do_ help you become a better one!