> and in new versions of your type checker, you have to make sure that they didn’t change their meaning and that they didn’t introduce new flags that you really

> and in new versions of your type checker, you have to make sure that they didn’t change their meaning and that they didn’t introduce new flags that you really, really should use. That's what the --strict flag is for, which the author even quietly uses in a later example without explaining it. Though it may be too noisy to immediately turn it on in some projects. As for the example of getting something returned from the network that has a mismatching type, there's no way mypy could guess that. You'd have to add an explicit `isinstance(foo, int)` check or use a runtime type checker. The author does have a point that people might simply use wrong type hints if they don't have a proper type checker set up though. I've seen so much code with `any` instead of `Any`, `[foo]` instead of `list[foo]`, etc. as type hints. Using something like pre-commit and/or editor plugins to run mypy automatically while editing is probably the best. But it's true that even then, without --strict or equivalent, you can too easily satisfy the type checker by simply annotating something as a `dict` or `list`, without explicitly using `Any`. Still, I don't think this means we shouldn't use type hints at all. It could definitely be more beginner-friendly, but most of the mentioned issues can be addressed with proper configuration.