3 ms·
I disagree, as somebody who has also worked with tons of type-hinted Python code. Gradual typing is obviously worse than real static typing, but it's a step up
by LegibleCrimson 3y ago
I disagree, as somebody who has also worked with tons of type-hinted Python code. Gradual typing is obviously worse than real static typing, but it's a step up from full dynamic typing. It has caught many bugs for me before hitting them in runtime, and provides good documentation about what I can expect a function to accept and return without forcing me to read prose.
Type hints don't provide any safety, though. That was never the goal, given that they're strictly optional and don't really exist at runtime anyway (though I have written some experimental monstrosities that used annotations for code generation at runtime). They're documentation in a standard form that static analysis tools can leverage.
I really can't imagine a situation where having type hints in Python is worse than simply not having them. They're not the worst of both worlds, they're a compromise with some of the benefits and drawbacks of each.
- Philpax 3y ago> I really can't imagine a situation where having type hints in Python is worse than simply not having them. Can’t they lie / go out of sync with what’s actually happening? IMO, an unenforced type hint is very dangerous because of this - it can give you a false sense of confidence in a scenario where you would otherwise write more defensive code.
- actuallyalys 3y agoYes, if you don’t run the type-checker regularly and just run the code itself, there’s nothing preventing them from going out of sync. Type hints are similar to tests in that way.
- nicoburns 3y agoI suspect Python is particularly bad in this regard. For example, PHP's gradual typing is enforced with runtime assertions.
- packetlost 3y agoYes, this is my whole point. Mypy by default will silently allow blatantly incorrect typing which is worse than no types IMO.
- LegibleCrimson 3y agoI suppose, if you're relying on type stubs. Ordinary in-line type hints won't lie or go out of sync without complaining somewhere though. Defensive code is good, but I'm absolutely sick of writing code that has to be defensive about the type of absolutely every variable everywhere. It's ridiculous, verbose, and nearly impossible to do universally. THAT is the worst of both worlds. Having to manually fret about the types that every variable may hold. At the point that you're having to write defensive code due to dynamic types, you've already lost the advantages of dynamic types entirely. I use type hints to say "use and expect these types or get Undefined Behavior", and that contract is good enough for me.
- packetlost 3y ago> Ordinary in-line type hints won't lie or go out of sync without complaining somewhere though This is demonstrably untrue with the default configuration of Mypy. It will silently ignore explicit hints, inline or not, in certain situations.
- LegibleCrimson 3y agoI'm going to need an example of that. I tend to use Pyright, but when I used MyPy, I never had it simply ignore explicit hints. If it's demonstrably untrue, you should be able to demonstrate it, right?
- packetlost 3y agoHere's the quickest, simplest example I could come up with off the top of my head: https://paste.sr.ht/~chiefnoah/7e07a961cf266fa620d1fd2d31ba2ce01d492f4a https://paste.sr.ht/~chiefnoah/7e07a961cf266fa620d1fd2d31ba2... This particular issue will get picked up with `--strict`, but it's nearly impossible to do that on a large codebase with typing added post-hoc. Pyright has saner defaults, it catches this particular issue: https://paste.sr.ht/~chiefnoah/80816fded2a08a03ca80804d524ee42ba4ae5fd2 https://paste.sr.ht/~chiefnoah/80816fded2a08a03ca80804d524ee...
- 3y ago