4 ms·
Bingo. I think a big explanation of the wide variance on opinion about type hints is due to reliance on tooling, or lack thereof. Writing type hinted python in
by kortex 6y ago
Bingo. I think a big explanation of the wide variance on opinion about type hints is due to reliance on tooling, or lack thereof.
Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident.
I can see how if you are using a WYSIWYG editor, type hints feel like more text for little gain. But even then, it really helps document intent. In fact switching to IDEs is partly what made me go from someone who hated static typing to loving it.
- codethief 6y ago> Writing type hinted python in Pycharm or Ipython feels like racing in a sports car. Without it, feels like stop and go traffic with the occasional car accident. This is a beautiful analogy! As for the second part, though, I would say that even if your IDE does not provide automatic type checking, type hints will still add some benefit because: - without type hints you have to do all type checking in your head (across all stack frames). - whereas with type hints you only need to do type checking down to the first level of the stack. To illustrate what I mean, consider the following code: def bar(param1, param2): ... # Some complicated code from which it is not immediately clear what values are allowed for param1 and param2, nor what the return type of the function is. def foo(param): return bar(param, param2="some default value") foo("something something") Now, in order to verify that `foo("something something")` is correct, you have to manually look at foo() and then at bar(). Needless to say, this adds a lot of mental overhead to the game. If we added type hints to both foo() and bar(), however, you would only have to check the signature foo() – which, even in IDEs without type checking, usually amounts to hovering over `foo("something something")`.