Hacker News Reader

Comment by packetlost | Hacker News Reader

As someone who has worked with massive typed Python codebases, I 100% agree with the author on Gradual Typing. It's literally the worst of both worlds. It's actually even worse than that because it gives the illusion of some safety when there isn't any, especially in Python where most of the tooling "fails open" by default and won't tell you something is wrong despite having annotations.

View on HN

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.

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

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.

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

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.

Any? I regularly find bugs. I don’t find every bug, but finding some bugs is better than none. Especially for the minimal cost of writing annotations.

> I don’t find every bug, but finding some bugs is better than none.

I used to think this, but based on experience I'm now less convinced. Finding most bugs, like real static typing does, is great; you can significantly reduce your test coverage and iterate with more confidence. Finding a few bugs is pretty useless if you're not finding enough to actually change your workflow.

Finding a few bugs is very useful if they're the kind of bugs that can cause problems in production but usually not in development or testing, like not checking an optional that is very rarely null.

It's not about workflow or finding enough bugs, but finding bugs that you might not have otherwise seen can be monumentally beneficial.

> Finding a few bugs is very useful if they're the kind of bugs that can cause problems in production but usually not in development or testing, like not checking an optional that is very rarely null.

There's a kind of excluded middle here though. Either that kind of bug hits production often enough to matter - in which case a checker that catches it sometimes isn't good enough, you need a checker that eliminates it completely. Or it doesn't hit production often enough to matter, in which case a checker is of limited use.

How is it worse than no typing? If you're not testing adequately because you think type safety is enough, you done f'd up.

Gradual typing is great. The parts you want precision on are statically typed, the parts that don't matter dynamic, and they fit together sanely at the language level.

Writing type annotations in comments for an optional preprocessor to pass judgement on before the actual implementation ignores them is a bad thing. But that's on python, not on gradual typing.

(An any type + static is also fine if you have a way to retrieve type information at runtime, and there's a sense in which template instantiations of a generic function and a function taking arguments of type any are the same thing as each other)

Python's type hints are just that, hints. They aren't static type annotations. Cython uses gradual typing, but the mainstream Python implementation does not actually offer gradual typing. It's still dynamically typed, but with an annotation mechanism that lets other tools do some analysis for you.

It's not the gradual typing. It's that static typing gives you the illusion of some safety where there isn't any.

I know someone that was on the Dart team and they say the same thing.

Reply on news.ycombinator.com