Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python type hints may not be not for me in practice

utcc.utoronto.ca

Post reply on HN
Print view View original

31–40 of 209 posts

Re: Python type hints may not be not for me in practice

#31

Post by thebigspacefuck »

agubelu wrote: post #7

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, beca…

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.

Re: Python type hints may not be not for me in practice

#34

Post by rrr_oh_man »

robjwells wrote: post #17
rrr_oh_man wrote: post #15

Earlier quoted context omitted.

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 b…

Thanks for sharing!

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

Re: Python type hints may not be not for me in practice

#35

Post by craftkiller »

> In writing this it occurs to me that I do often know that I have distinct types (for example, for what functions return) and I shouldn't mix them, but I don't want to specify their concrete shape as dicts, tuples, or whatever. [...] Type aliases are explicitly equivalent to their underlying thing, so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them.

It sounds to me like you're describing the NewType pattern which is just slightly farther down the page you linked in the article.

https://docs.python.org/3/library/typing.html#newtype

Re: Python type hints may not be not for me in practice

#36

Post by wenc »

coldtea wrote: post #19
agubelu wrote: post #7

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, beca…

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

Re: Python type hints may not be not for me in practice

#37

Post by belorn »

tasn wrote: post #21

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

Looking at that blog post, I find it illustrative in how people who like strong types and people who dislike strong types are addressing different form of bugs. If the main types of issues comes from bugs like 1 + "2" == 12", then strong types is a big help. It also enables many developers who spend the majority of time in a programming editor to quickly get automatic help with such bugs.

The other side is those people who do not find those kind of bugs annoying, or they simply don't get hit by such bugs at a rate that is high enough to warrant using a strong type system. Developers who spend their time prototyping in ipython also get less out of the strong types. The bugs that those developers are concerned about are design bugs, like finding out why a bunch of small async programs reading from a message buss may stall once every second Friday, and where the bug may be a dependency of a dependency of a dependency that do not use a socket timeout. Types are similar not going to help those who spend the wast majority of time on bugs where someone finally says "This design could never have worked".

Re: Python type hints may not be not for me in practice

#38

Post by robjwells »

gizmo385 wrote: post #30
robjwells wrote: post #10

Earlier quoted context omitted.

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?"

Re: Python type hints may not be not for me in practice

#39

Post by wenc »

greatgib wrote: post #8

The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. I'm missing a lot simple functions with explicit argument names and docstrings with arguments types and descriptions clearly but discreetly documented. It was one big strength of Python to have so simple and clean code without too much boilerplate. Also, I have the feeling that static typing extremis…

> The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable.

Compared to legacy Python, yes.

Compared to verbose language like Java, no. Python typing is equal or less verbose than Java (unless you use "var" in Java).

Re: Python type hints may not be not for me in practice

#40

Post by ansgri »

tasn wrote: post #21

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

If it’s 100x better than no types, then probably 10x better than C++ type system. It takes some time to unlearn using dicts everywhere, but then namedtuples become your best friend and noticeably improve maintainability. Probably the only place where python type system feels inadequate is describing json-like data near the point of its (de)serialization.
Post reply on HN