Item — HN Reader

> 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.

4 comments

I 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.

> 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.

I'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?

Here's the quickest, simplest example I could come up with off the top of my head:

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/80816fded2a08a03ca80804d524ee...

Thanks for the example. That's happening because the `main` function is an untyped function. You can fix that by changing `def main():` to `def main -> None:` You can also make it pick up with `--check-untyped-defs`. I always used mypy with --strict, so I forgot that it wasn't the default configuration.

I agree, though. Pyright has better defaults. It's not great that mypy just completely skips all functions without typing information given. It makes a lot more sense for it to just check everything and assume Any on all unspecified arguments and returns. It's still valuable to type-check the contents of functions with unspecified types.

Yes, this is my whole point. Mypy by default will silently allow blatantly incorrect typing which is worse than no types IMO.

Yes, 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.

I suspect Python is particularly bad in this regard. For example, PHP's gradual typing is enforced with runtime assertions.