Hacker News Reader

Comment by agubelu | Hacker News Reader

Type hints are nice, until you have to interact with a library that isn't type-hinted, and then it very quickly becomes a mess.

I don't know how other IDEs behave, but VScode + the Python extensions try to infer the missing hints and you end up with beauties such as `str | None | Any | Unknown`, which of course are completely meaningless.

Even worse, the IDE marks as an error some code that is perfectly correct, because it somehow doesn't match those nonsensical hints. And so it gives you the worst of both worlds: a lot of false positives that you quickly learn to ignore, dooming the few actual type errors to irrelevance, because you'll ignore them anyways until they blow up at runtime, just as it'd happen without typehints.

View on HN

> Type hints are nice, until you have to interact with a library that isn't type-hinted, and then it very quickly becomes a mess.

Whenever I find myself in that situation, I usually write a typing stub for the parts that I use from that library (example: [0]) and then let `mypy_path` point to that directory [1].

VS Code will then pick up the hints from those stubs.

[0]: https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c38...

[1]: https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c38...

>I don't know how other IDEs behave, but VScode + the Python extensions try to infer the missing hints and you end up with beauties such as `str | None | Any | Unknown`, which of course are completely meaningless.

Are they correct? If they're correct (even though they are a superset of the actual intended type) then what's the problem?

At worst, it's like not having type checks for that particular package.

They are verbose but correct. I've caught some errors this way.

I usually don't think of None as a potential return value (= voids in C) but the LSP code analysis usually picks up on code paths that don't return a value.

I don't find Python's typing valuable for Jupyter type explorations, but they're immensely valuable for catching little issues in production code.

For example in mypy the default is to not check procedures, which have no argument type annotations and no return type annotation. That gets rid of your whole problem of untyped library, if you have a wrapper procedure.

If VSCode still highlights it, then it is time to configure VSCode properly.

I believe VSCode by default uses pyright which is fast but shitty in that it gives a lot of false positives. If you want the most correct typing experience, use mypy. Even then you may need a config.

I get what you need, yet I find these cases aren't all that often, and when it happens it doesn't bother me as I quickly recognize where the type system is somewhat failing and either ignore it or add a type hint.

But maybe if you have a codebase with a lot of magic of certain libraries, you experience is different. I also don't really depend on the typing treat it the same as C# or Java.

FWIW, you have some control over how this inference is done. Search your settings in vscode for `@ext:ms-python.vscode-pylance strict`.

I believe there's a mode for VS Code type checking which ignores untyped code - have you tried that?

Worst of both worlds is right. I came back to a Python project with a couple of critical but untyped dependencies recently after writing mostly Rust, and to clear up a large number of these (particularly “type is partially unknown”) I had the choice between lots of purely type-checking ceremony (`typing.cast`) or going without.

The third option here is writing type stubs for the library, which you can sometimes find community versions of as well. They’re not too time consuming to write and generally work well enough to bridge the gap

Yeah, I think this may be a good option when actively working on a project. Sadly at the moment, it's mostly a case of "I just need to make a couple of bug fixes in this old project, why is my editor shouting at me?"

What did you end up choosing & why?

It's only a personal side project and I have a good handle on the untyped modules in question, so in the end I suppressed most of the errors with `# type:ignore` and friends.

I'd reconsider that if I was doing more than the odd bug fix on the project. I still like Python, and started using type hints early, but there's enough added friction to make me question using them in the future.

I imagine on big projects the benefit is clearer.

Thanks for sharing!

Asking because I was really, really annoyed by the non-helpfulness of the type hints in practice, contrary to the theory.

Reply on news.ycombinator.com