Hacker News Reader

Comment by throwaway290 | Hacker News Reader

The thing with type hints in Python is that it's not enforced unless you make and maintain checking it as part of your workflow. And it comes with a bunch of things, at least: make sure to configure mypy, make sure you run mypy after push (experienced pythonists will forget to run it before), make sure everyone's IDE has it integrated, make sure to be super clear on which version of mypy you run (so errors people see in their IDE are the exact same as on CI). And don't forget to update all this when new version comes out.

View on HN

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) 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.

> 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;)

I 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.

Of 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.

Don't all the exact same problems exist with e.g. what version of Python or what formatter/linter your team uses? I don't see how this is unique to mypy.

There is undoubtedly setup with all these tools, but the benefit massively outweighs the cost to my mind.

Version of Python is a runtime thing that can be checked.

Formatting is not relevant to whether the code is correct, but types are.

The problem compared to static languages is that it does not need to compile, types are completely ignored at runtime and there is no built-in way of checking it (like python binary with a special flag) so everyone does things different.

Having mypy in the pre-commit hook helps a lot! (But I agree that difference between mypy versions is a pain.)

Reply on news.ycombinator.com