3 ms·
It's not that many steps. You already have CI - adding mypy is one extra line, you should already have a way to keep track of versions in your project - keeping
by jstx1 3y ago
It's not that many steps. You already have CI - adding mypy is one extra line, you should already have a way to keep track of versions in your project - keeping track of the mypy version isn't any additional overhead.
If your team uses VSCode, you can have a devcontainer for the project (https://code.visualstudio.com/docs/devcontainers/containers https://code.visualstudio.com/docs/devcontainers/containers) to make sure that it's in everyone's IDE along with your other linters, formatters etc and you can also have pre-commit hooks.
- throwaway290 3y ago> You already have CI Don't worry about me. I mean all projects that do not have people and resources for this stuff. People just want to write Python and be done with it. Without type hints they wrote Python and if they run it and tests pass then it works. Now they write Python code that can be wrong but they don't find out unless they also run an extra tool. The fact that it requires CI now is a good illustration of the problem;)
- jstx1 3y agoI don't understand who the "just want to write Python and be done with it" demographic is. If you're a developer, it makes sense to do things well, if you aren't and you're writing small one-off scripts, you can do fine without type hints. Anyone who can write and run a test can also call "mypy ." on their project.
- throwaway290 3y agoOf course, but they forget. So when you see type declarations in Python, you cannot trust them the way you can trust them in Rust or TypeScript. Outright wrong types that make zero sense cause no errors, no test failures, etc. Type validation is reduced to the level of linter, and no one really cares about the linter the same way as they care about working code. This gets people new to static typing into bad habits and loses the main benefit of type system.