My fear is that this type hinting pushes #python down the same bad road as #cpp:
Making an originally nice programming language more and more complex and ugly by giving in to the pressure of adding more and more features which don't fit into the original idea of the programming language.
In my view, the core philosophy of #python is that it is a high-level dynamically typed language . And the core philosophy of #cpp is that it is a low-level statically typed language.
Don't mix that.
But you don't have to use type hints at all, even in the latest versions. They're completely optional. You could write an entire new application without a single type hint in it, and it would work just fine. Static linters like mypy wouldn't be able to find as many problems without the hints, but that's a tradeoff.
Or does it somehow bother you when some #dependency has type hints in its code?
No, dependencies have their own coding styles (and often different programming languages) anyway and that's perfectly fine.
But "it's only optional" is an excellent excuse for messing with perfect simplicity and elegance.🙃
I get it; I've been a big fan of Python since 1995. When type hints were first proposed it did seem a little at odds with Python philosophy - but I was reassured by the immediate assurances that they were optional, and were going to stay optional. So I mostly ignored them for a few years.
When I did start using them, it felt a little weird; the code didn't "look" right. But that's the same with any change.
Now I'm a big believer. They have prevented so many bugs...
Do you have representative specific samples of bugs you found that way? Trivial bugs or nasty bugs, dangerous skeletons in the closet? Could automated tests have caught them, too?
Did you consider switching from #python to statically typed languages like #java, #rust or #golang ?
There was a time when I couldn't imagine in the world to use a dynamically typed language for serious programming. I changed my view completely. B
May be the same with type hints. But maybe not.😉
Asking for specific #examples type checking finds is ... unproductive. You write 2 modules of code, run #mypy, and get a list of the 11 places you need to fix - before you've even written unit tests that may or may not have caught the same problem.
If I tried to keep track of them all, I wouldn't have time to write code.
[...]
And yes, many of them are #bugs that would be #agonizing to find by other routes. Your unit test #probably doesn't try passing a #float to that #function you wrote that you only considered using ints with - but with hints, mypy will find that "one weird way" that a float value returned from somewhere else could get passed into the function.
Type hints in code - used well and consistently, no using "#Any" to shut mypy up - make me 50% more productive, I think. </anecdote>
I remember recently learning about one case where some code intentionally mixing integer and float calculations was writing out the wrong type into Elastic Search, causing an inconvenience in Kibana visualizations because integers don't allow the same aggregation functions as floats.
But this is the only case I can remember static type checks probably would have caught, and it was quite harmess.
Maybe I miss something, or maybe our code base is just different, who knows.😉
From the more theoretical perspective - knowing that this is definitely not an exhaustive perspective - right now I cannot imagine situations where a type bug wouldn't be also a functional bug, which would be caught anyway by code review or testing.
Mixing floats and integers comes closest. But also here I think #python does a good job avoiding mistakes. For example, the type of a result of all operations does depend only on the input types, but never on the input values.
@folkerschamel @cazabon @ado I think the main value of static type checking is finding these bugs *faster* and with less effort. I agree that it's not common to have a type mismatch that wouldn't show up as a functional bug under the right circumstances, but code review does not necessarily catch all those bugs, and neither does testing. Or at least, sometimes you have to write a pretty weird test (or expose the program to real live users *gasp*) to find them. I'm envisioning something like a variable which some rarely-executed part of the code sets to None and a different part of the code assumes is always non-None, or passing the wrong number of arguments to a last-resort error-handling function, or stuff like that.
The other main value of type hints IMO is documentation, so that users of a library/function/etc. know what type of thing they're supposed to pass in. I find it a lot easier to understand (and write!) that info in the form of type hints rather than prose.
I see your first point theoretically. But I don't remember situations where I thought "static type checking would have helped us avoiding that trouble". But I keep it in mind.🙂
About documentation, I see the argument in theory. But I think in practice you get that information for free by naming (e.g. "counter" -> int, "name" -> str) or documentation ("number of elements" -> int, "object supporting xyz").
In general, specific real-world examples would be interesting.🙂
Folker
C.
David Zaslavsky