3 ms·

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 beh

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.

robjwells 2y ago
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.
- rrr_oh_man 2y ago
  What did you end up choosing & why?
  - robjwells 2y ago
    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.
    - rrr_oh_man 2y ago
      Thanks for sharing! Asking because I was really, really annoyed by the non-helpfulness of the type hints in practice, contrary to the theory.
- gizmo385 2y ago
  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
  - robjwells 2y ago
    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?"
Lutger 2y ago
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.
zelphirkalt 2y ago
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.
Hackbraten 2y ago
> 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/5ca04e070f56bf794c382c9a4c04de3d5d9a4308/itchcraft/stubs/usb/core.pyi https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c38... [1]: https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c382c9a4c04de3d5d9a4308/pyproject.toml#L15 https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c38...
coldtea 2y ago
>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.
- deleted 2y ago
  [deleted]
- wenc 2y ago
  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.
thebigspacefuck 2y ago
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.
ratmeadow 2y ago
I believe there's a mode for VS Code type checking which ignores untyped code - have you tried that?
hermitdev 2y ago
FWIW, you have some control over how this inference is done. Search your settings in vscode for `@ext:ms-python.vscode-pylance strict`.

robjwells 2y ago

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.

rrr_oh_man 2y ago
What did you end up choosing & why?
- robjwells 2y ago
  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.
  - rrr_oh_man 2y ago
    Thanks for sharing! Asking because I was really, really annoyed by the non-helpfulness of the type hints in practice, contrary to the theory.
gizmo385 2y ago
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
- robjwells 2y ago
  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?"

Lutger 2y ago

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.

zelphirkalt 2y ago

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.

Hackbraten 2y ago

> 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/5ca04e070f56bf794c382c9a4c04de3d5d9a4308/itchcraft/stubs/usb/core.pyi https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c38... [1]: https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c382c9a4c04de3d5d9a4308/pyproject.toml#L15 https://github.com/claui/itchcraft/blob/5ca04e070f56bf794c38...

coldtea 2y ago

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

deleted 2y ago
[deleted]
wenc 2y ago
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.

thebigspacefuck 2y ago

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.

ratmeadow 2y ago

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

hermitdev 2y ago

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