13 ms·
Ask HN: Which Python type checker should I use?
New to Python but not new to type checking (Rust, Typescript). I don't know which type checker for Python I should invest in.
- catlover76 3y ago[dead]
- theusus 3y agomypy is the most popular but if you want to use an extension then pyright from MS gave best experience for me.
- deleted 3y ago[deleted]
- breakds 3y agoI have been using pyright with lsp in emacs and can recommend.
- thayne 3y agoI've used mypy for a while, but I've wondered if it is worth switching to pyright, pyre, or pytype.
- Zizizizz 3y agoPyright by default because it's a LSP so I get to go definition, find references, etc... as well as the type checking in neovim. It's Pylance as part of the Python plugin in VS Code. Just make sure you go to the settings in Vs code and turn the type checking on to basic or strict. (It's off by default) I tend to run mypy every now and then ad-hoc to check things and it sometimes finds things that need correcting but I wouldn't say it's as worth setting up as the former.
- fbdab103 3y agoWould also be interested in what is friendly with Django. Using VSCode + the Python extension, the default checker (Pylance?) just pukes on the ORM magic.
- josebama 3y agoTo get the type checker to work with Django you need to install django-stubs[1]. It works great with mypy, but should also work well with pyright. [1]: https://github.com/typeddjango/django-stubs https://github.com/typeddjango/django-stubs
- crucialfelix 3y agoThe types will work in pyrite, but there is no pyright support for plugins, so the Django magic doesn't get typed correctly. I'm considering switching to pyright, probably by rewriting code that uses this magic. Or running both in ci with different configurations.
- pepoluan 3y agoPyCharm professional understands Django natively. Maybe try that? PyCharm also has its own type-checker that's a lot less fussy than mypy.
- kelsolaar 3y agoPyright is much faster than Mypy, we changed some times ago and went from something like 20 mins to less than 2.
- zx8080 3y ago> 20 mins to 2 For which codebase size?
- drekipus 3y agoPyright 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, a year or so ago.
- tentacleuno 3y agoCan the extension be used on VSCodium builds? If memory serves, C# tooling extensions are proprietary and are subject to unfortunate treatment when using open-source builds of VSCode.
- giantzoc 3y agoYou are correct. It is not supported on vscodium.
- mdasen 3y agoYea, and if you're a company making more than $1M in revenue or have over 250 PCs, then you need a commercial license. Microsoft definitely seems to be pushing proprietary VSCode extensions where it's free to get users hooked on the product (and kill competitors) and then charge companies lots of money for the tools they got everyone hooked on because they appeared to be free.
- lordkrandel 3y ago[flagged]
- seanhunter 3y agoIt's worth considering whether this is a helpful contribution to the debate. The OP obviously wants to use a type checker and thinks that's a good idea. If you believe there is a particular reason this is a bad idea, we might all learn something if you said why. If you think that type checkers are in themselves not a bad idea but all the existing python type checkers are inadequate or unhelpful, that would be good to know as well. Instead all we have is your snappy/snarky hot take and a bunch of questions.
- subtra3t 3y agoI think you are reading far too much into their comment. I agree that their comment could have benefited from some elaboration but the simple act of them expressing their opinion (especially one that is not seen in the rest of the thread, as of my writing this comment) is a "helpful contribution to the debate", in my opinion.
- triyambakam 3y agoGiven no other context, it's not very helpful
- seanhunter 3y agoAgree. It also seems a direct contravention of the guidance "Please don't post shallow dismissals.... A good critical comment teaches us something. " https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- lordkrandel 3y agoI didn't know about the guideline, so thank you, even if I disagree with it. A shallow dismissal is anyway a signal you can ignore, but meaningful, especially when people flock and say the opposite. Maybe people don't have definite ideas about things, and just want to say "no" because they feel like, and that's freedom, imho. Anyway I don't use types or type checking, I think that they are the crippling reason why I switched to Python in the first place. There are plenty of typed languages or IDEs that do completion nowadays (which I don't use), but the freedom to completely rearrange the architecture of a program that comes from very loose coupling is not easily traded for compilation time warnings. We've been doing tests because typing blocked us from development, and we just wanted to be able to screw things if we wanted. The company I work for, Odoo, big opensource ERP, also doesn't have types at all. If I wanted types, or a fast language, or "precise interfaces" I would definately rewrite. When I developed in C#, most of the coding time was spent on typing, interfaces, adapters, factories.
- _ZeD_ 3y ago(eclipse+pydev - for the IDE part) + mypy (better dmypy for performance) + ruff (both as linter and as formatter) is the way I go. an in my pyproject I set the strict mode for mypy, and almost all rules for rust with extend-select
- deleted 3y ago[deleted]
- MrJohz 3y agoMy experience is pretty negative with all of them, I would be almost more tempted to ignore type checking in Python until it has drastically improved. In particular, if you're experienced with Typescript, you're probably going to be very disappointed when trying to do similar things in Python. The most recent one I've tried was Pyright. Pyright is faster than Mypy, and can also be configured to be quite strict, both big plus points for me. Unfortunately, in practice it ended up being far too strict in weird ways, and therefore difficult to work around with libraries that don't share its idiosyncratic assumptions. For example, in Typescript there's an unknown type, which you can't do anything with unless you check its runtime type first. It's a clever way to add a true dynamic type to the type system without losing type safety. In Pyright there's a similar Unknown type, but in strict mode the type checker simply throws an error if anything is ever unknown. For me, this turned out to be particularly painful when using library types that involved generic state. Because I wasn't using that state, I didn't set a type for it, and it defaulted to Unknown. But that meant that an object had Unknown properties (that I was never using) which meant the type checker kept on failing. Moreover, because Python's generics story is pretty miserable, I couldn't figure out how to set the type to something not Unknown. And I couldn't figure out how to disable the error because Pyright's documentation is so poor. I genuinely spent a day of work on this problem, then disabled type checking completely because that was the easiest option. I haven't used Mypy for over a year at this point, so things may well have changed, but my memory was that where Pyright is overly pedantic, Mypy was overly lax. It was also a lot slower, and had similarly poor documentation. The main reason I switched was that I was still regularly running into runtime type errors - the very errors that the type system was meant to help me avoid. In both cases, I found the biggest problem was that neither tool seemed to go as far as Typescript in terms of modelling real-world Python code. What I mean by that is that idiomatic Typescript usually looks a lot like idiomatic Javascript in terms of the patterns and features used, because the Typescript team have put a lot of effort in to ensure that Typescript types represent how Javascript is actually used. On the other hand idiomatic typed Python typically seems to look very different from idiomatic untyped Python, in large part because with types, you end up limited to about 1/4 of the surface area of the language. (This is why a lot of major libraries or tools come with type checker plugins because their library's behaviour cannot be described purely in terms of types.) Typed Python then ends up looking like a weird Java variant. If I were going to add a type checker to my Python code again, I'd probably go for Mypy because it seems more like the standard and had marginally better documentation. But right now, I have the Pylance plugin installed in my IDE and that's about it - there's no type checking in CI, I just hope that I catch all the obvious cases with good enough testing. Thankfully the Python side of my work is pretty minimal, a few hundred lines of code at most. If I had a bigger Python project I might revisit this situation, but I'd be more tempted to just avoid Python for bigger projects.
- thoaasfwe 3y agopyright 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.
- winrid 3y agoBetter than Pycharm?
- falleng0d 3y agoKind of hard to say. With pylance the type checking will be definitively better in vscode. But pycharm had a lot going on to make up for it. Just as a reference I use pycharm mainly but before sending a PR I will rely on vscode to fix typing issues. Just use what you likes best.
- pepoluan 3y agoI maintain aiosmtpd using PyCharm and... That's it. Playing around with Ruff nowadays. mypy was proposed early during aiosmtpd development but we decided it's not worth the headache.
- frfl 3y agoI 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.
- meitham 3y agoThe only useful types to add are Cython 3, otherwise adding more letters with no benefit reduces readability and reminds me of “public static void main”.
- diarrhea 3y agoSaying it has no benefit is simply arguing in bad faith. It objectively does. Just maybe they’re not worth the trade off for you.
- bravura 3y agoI’ve used mypy for static checking but it’s too fussy. I enjoy typeguard for dynamic checking using the @typechecked decorator. I haven’t tried beartype, but I know lucidrains uses it.
- damezumari 3y agoI 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 rust or go.
- nickm12 3y agoMy 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.
- mixmastamyk 3y agoWhat does this mean, Python 2? Are those the old type comments?
- zo1 3y agoEclipse 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.
- nickm12 3y agoYes. Mypy supports type annotations provided in comments in both Python 2 and Python 3. I have ported a codebase from Python 2 to 3 by annotating it with comment-syntax annotations and it helps a ton to keep your strings and bytes separate. Basically, you annotate with the binary_type, text_type types the six package and typecheck your code on both Python 2 and Python 3. Basically, the steps involved are: 1. set up static analysis (linting and typechecking) for python 2 and python 3 2. get code passing static analysis on Py2 and Py3 3. get code passing tests on Py2 and Py3 4. get code running in production on Py3 5. stop checking and testing on Py2 It's not trivial and it requires some strong Python experience to write code that correctly "straddles" Py2 and Py3. But the advantage of the static checkers is you can slowly dial up their strictness and once they are dialed in, you minimize new regressions (new untyped code, new code that fails typechecking).
- owenpalmer 3y agoNim
- ivalm 3y agoI use mypy. We use tox to run pytest, flake8 (linting), and mypy (typing)
- dlahoda 3y agogo with one which does more inference for you. pyright does more, mypy less.
- IshKebab 3y agoPyright is much much much better than Mypy, and it's easy to use with VSCode. The only reason to use Mypy is if you're adding types to a legacy codebase and don't want to be immediately confronted with a gazillion type errors, because Mypy has "eh whatever" modes and is generally more lax. If it's new code, Pyright hands down.
- smitty1e 3y agoThe recent takeover of rye by the guys doing ruff[1] has some likelihood of rendering the python typing and packaging scene into something more coherent. Having the tool get started with Ronacher, of Flask fame, gives it some mindshare among those paying attention. It would be better still if the PSF were endorsing, but that gets too political, I suppose. [1] https://astral.sh/blog/uv https://astral.sh/blog/uv
- pepoluan 3y agoWell the guys at astral has no plans in the near future to create a static type checker. Ruff is great, though. I now stop using flake8+black+isort and have gone all-in with Ruff.
- pepoluan 3y agoI just use the built-in one in PyCharm. It serves my need, which is to ensure I haven't done mistakes in specifying parameters to functions. I have no desire making Python to be statically-typed.
- softwaredoug 3y agoMy rule for these things is to stay close as possible to the mainstream, boring thing, closest to the Python Software Foundation, unless I have an overwhelming reason to switch. So mypy for me.
- 12_throw_away 3y agoThere 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.
- roland35 3y agoI use LazyVim (neovim) and VS Code for Python work. Pyright and Ruff work well with Neovim, and Pylance works only with VS Code (but you need to enable it, if I remember correctly!) My only issue is I occasionally need to restart Pyright when it fizzes out.