> Just the type hints were wrong. > warnings of IDEs are simple to ignore This is unusual. In my experience, of codebases I have worked with or have seen, whe

> Just the type hints were wrong. > warnings of IDEs are simple to ignore This is unusual. In my experience, of codebases I have worked with or have seen, when there are type hints, there are almost all perfectly correct. Also, you can setup the CI to check also for IDE warnings. For example, we use this script for PyCharm: https://github.com/rwth-i6/returnn/blob/master/tests/pycharm-inspect.py https://github.com/rwth-i6/returnn/blob/master/tests/pycharm... The test for PyCharm inspections only passes when there are no warnings. Although, I have to admit, we explicitly exclude type warnings because here we have a couple of false positives. So in this respect, it actually agrees with the article. But then we also do code review and there we are strict about having it all correct. Yes, I see the argument of the article that the typing in Python is not perfect and you can easily fool it if you want, so you cannot 100% trust the types. But given good standard practice, it will only rarely happen that the type is not as expected and typing helps a lot. And IDE type warnings, or mypy checks still are useful tools and catch bugs for you, just not maybe 100% of all typing bugs but still maybe 80% of them or so. > Isn’t it better to detect at least some errors than to detect none at all? > You can not be sure that they are correct. As such, you must always treat them as if they were wrong. I don't get this argument. Isn't this the case for all other code as well? Most code has not been formally verified to work 100% correct. So you assume always all code is wrong? This doesn't make sense. > They [type hints] waste mental energy when reading code How? The author even acknowledges that you could just treat them as code comments if you like. By that argument, all code comments waste mental energy?