| Thanks for your reply. > I view them as similar to python's "private" functions, which are really just functions starting with an underscore Good analogy! I wish they were more like "private" class methods, which are prefixed by a double underscore and result in name-mangling: you can still access them from outside if you want, but the code will really look ugly. And you absolutely cannot access them accidentally. Which is what type checking should be all about, right? Preventing accidental misuse? > Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need. That's what drives me crazy. I come from the statically typed world. This bit of Python's philosophy really clashes with my world view. "These types are just something someone wrote, they may or may not accurately describe the code" seems so wasteful and unhelpful to me... |
That’s the kind of the culture shock you get learning dynamic type languages with a static type pov. Type hinting is not really the problem here, but can seem that way because it makes dynamically typed code too superficially similar that it enters the uncanny valley if you treat it like statically typed.
One way that might make this easier is to forget about type hinting entirely at first and learn the language “from scratch”, and add the types back after you get used to write dynamically typed code. Dynamically typed code have its advantage and isn’t bad without type hints (well, at least you have to convince yourself on this, or you’ll never be able to learn a dynamic type language), and the type hints just add back some of the nice things static type provides without compromising dynamic type benefits.