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

Ask HN: Which Python type checker should I use?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Ask HN: Which Python type checker should I use?

#61

Post by mixmastamyk »

nickm12 wrote: post #30
damezumari wrote: post #28

I would not personally use any of them. Typed python in previous workplace was pretty much shitshow, and if starting from scratch instead of untyped codebase it might be worth it, maybe, for some specific cases, but in general combination of bad library typing and bad type checking tools leads to horrible user experience. So going forward my personal projects continue to be ducktyped, and if I care about types, I use…

My experience couldn't be more different. I've had the experience of introducing type annotations into legacy Python 2 codebases and it's been a godsend and the only way to get them to Python 3. I've also had the experience of writing greenfield Python 3 code fully-typed from the start and its also been a useful tool there.

What does this mean, Python 2? Are those the old type comments?

Re: Ask HN: Which Python type checker should I use?

#62

Post by mixmastamyk »

emblaegh wrote: post #34
damezumari wrote: post #28

I would not personally use any of them. Typed python in previous workplace was pretty much shitshow, and if starting from scratch instead of untyped codebase it might be worth it, maybe, for some specific cases, but in general combination of bad library typing and bad type checking tools leads to horrible user experience. So going forward my personal projects continue to be ducktyped, and if I care about types, I use…

Whatever bad experience you get from the (admittedly) immature tooling, pales in comparison to the intense discomfort or working with an untyped Python code base of even moderate size, specially ones written by many different contributors.

I’ve worked for a while rewriting a large crappy old etl codebase and types were not the problem at all.

Really it needed a huge amount of reorg and refactoring, which a test suite and pyflakes handled quite well.

https://news.ycombinator.com/item?id=39161025

Re: Ask HN: Which Python type checker should I use?

#63

Post by mixmastamyk »

IshKebab wrote: post #47
damezumari wrote: post #28

I would not personally use any of them. Typed python in previous workplace was pretty much shitshow, and if starting from scratch instead of untyped codebase it might be worth it, maybe, for some specific cases, but in general combination of bad library typing and bad type checking tools leads to horrible user experience. So going forward my personal projects continue to be ducktyped, and if I care about types, I use…

I have had the misfortune of having to work with untyped Python code. It is completely awful and I cannot imagine anyone genuinely prefers it. Impossible to navigate. Full of trivial type bugs and typos. Static typing makes Python tolerable.

Pyflakes will catch most of those kinds of bugs. Fast option if for some reason you can’t or don’t have time to type.

Re: Ask HN: Which Python type checker should I use?

#64

Post by zo1 »

mixmastamyk wrote: post #61
nickm12 wrote: post #30

Earlier quoted context omitted.

My experience couldn't be more different. I've had the experience of introducing type annotations into legacy Python 2 codebases and it's been a godsend and the only way to get them to Python 3. I've also had the experience of writing greenfield Python 3 code fully-typed from the start and its also been a useful tool there.

What does this mean, Python 2? Are those the old type comments?

Eclipse with PyDev had awesome support for types in python 2.* before they were a python 3 thing. It actually worked really well for the 90% usecase and was my secret weapon about a decade ago.

Re: Ask HN: Which Python type checker should I use?

#65

Post by a-dub »

MrJohz wrote: post #57
a-dub wrote: post #23

Earlier quoted context omitted.

i've often thought a more interesting approach for python's duck typing would be if the interpreter looked for anomalous types on assignment. so build a compact distribution of type "shape" for every assignment and then either throw exceptions or log warnings when apparent outliers are encountered.

That's roughly a structural type system, and it's part of what makes Typescript work well (although it has some disadvantages in that you can't easily describe the type "an object with only these attributes). You can somewhat get that effect with Protocols in Python, but it often feels a bit boilerplate-y to me.

sortof. except two differences:

1) i'm primarily interested in data types, rather than objects, as i believe most runtime errors are the result of unexpected changes to data types.

2) i'm suggesting a type system that does away with hand annotations and rather builds them on the fly by keeping assignment history and using that to determine when statistically anomalous types appear.

Re: Ask HN: Which Python type checker should I use?

#66

Post by frfl »

winrid wrote: post #41
thoaasfwe wrote: post #22

pyright is state of the art right now thanks to eric. If you use VSCode+Pylance you will feel right at home coming from Rust/TS. just be aware a lot of community packages aren't ready for typed python. if you stick to the good stuff like fastapi and pydantic, you will be fine.

Better than Pycharm?

I used Pycharm briefly in 2017 and thought wow this is great, does a lot of type checking just out of the box.

But after coming back to it in 2024, I found it quite lacking in multiple areas compared to LSP based type checkers. I work on a sizable Python codebase and opening it in Pycharm everything looks great at first glance. Then you open it in an LSP editor and you see warnings and type errors everywhere that Pycharm never caught and everyone using Pycharm never sees.

So, in my opinion, yes, much better than Pycharm, unless you have an affinity for Jetbrains products, LSP type checkers are much better. Again in my opinion, others may disagree.

Re: Ask HN: Which Python type checker should I use?

#67

Post by screye »

drekipus wrote: post #10

Pyright is the Microsoft provided lsp: does anyone else feel uneasy about using this? Especially given the EEE playbook "that we definitely won't do this time" - would love to have a discussion on this if someone could talk me into using it. I just use a combination of black, flake, and mypy. Apparently ruff is quite good as well. For lsp I use Jedi, which actually worked faster on my company's code base than pyright…

This version of Microsoft has learnt from the mistakes of its predecessor, coming up with an even more potent model for making money.

"Embrace + extend + embed" makes more money than "embrace + extend + extinguish".

As long as Microsft controls the data (your vscode actions), they have no need to explicitly destroy their competitors. The data skew gives them a natural advantage. I don't trust their intentions, but I do trust the well-aligned monetary incentives.

Re: Ask HN: Which Python type checker should I use?

#68

Post by 12_throw_away »

There is no perfect solution. However, I actually prefer Pycharm's built-in typechecker, because JetBrains is BY FAR the best at checking syntactically incorrect code, i.e. code that you're in the middle of typing out.

But, Pycharm's still quite limited compared to pyright or even mypy. So I find myself A) doing an extra linting pass with pyright or mypy; and/or B) adding redundant annotations/overloads to help pycharm figure out what's going on.

Re: Ask HN: Which Python type checker should I use?

#69

Post by MrJohz »

a-dub wrote: post #65
MrJohz wrote: post #57

Earlier quoted context omitted.

That's roughly a structural type system, and it's part of what makes Typescript work well (although it has some disadvantages in that you can't easily describe the type "an object with only these attributes). You can somewhat get that effect with Protocols in Python, but it often feels a bit boilerplate-y to me.

sortof. except two differences: 1) i'm primarily interested in data types, rather than objects, as i believe most runtime errors are the result of unexpected changes to data types. 2) i'm suggesting a type system that does away with hand annotations and rather builds them on the fly by keeping assignment history and using that to determine when statistically anomalous types appear.

That would be a structural type system with Hindley-Milner type inference. A good example of that might be OCaml - it's largely structurally typed, and the types can be completely inferred without type annotations.

However, while Hindley-Milner will find all the type errors in your program, it won't necessarily report those errors in the most logical places. That's why it's generally still the norm to annotate functions with type annotations except in the most trivial cases: knowing that a function will take a string and return a number is useful information not just for the compiler, but also the programmer.

To come back to your first point, one common solution here is the "parse, don't validate" mantra for loading data. This is the idea that when accepting unknown data (e.g. from a file or API), you first parse the data and convert it into a representation that enforces the invariants your program believes about that data. For example, that names can never be longer than twenty characters, or that ages are always positive numbers. By doing this parsing as soon as the data enters your program, you immediately handle unexpected changes to the data formats - if data changes such that it can no longer be parsed, this is an immediate error, rather than something that will only show deep in your application.

With something like Pydantic (alternatives are available), you can describe what your data should look like in terms of types, and use Pydantic to do the parsing for you.

Re: Ask HN: Which Python type checker should I use?

#70

Post by IshKebab »

mixmastamyk wrote: post #63
IshKebab wrote: post #47

Earlier quoted context omitted.

I have had the misfortune of having to work with untyped Python code. It is completely awful and I cannot imagine anyone genuinely prefers it. Impossible to navigate. Full of trivial type bugs and typos. Static typing makes Python tolerable.

Pyflakes will catch most of those kinds of bugs. Fast option if for some reason you can’t or don’t have time to type.

No it won't. It won't even catch trivial errors like `import os; os.sdfsdfsdf()`.

Perhaps you haven't used static typing so aren't familiar with the kinds of bugs it can prevent?

Post reply on HN