ty - Python type checker
44 points by tffr
44 points by tffr
Pyright hits the Internet every single time you run it, and it's «by design». That's enough for me to ditch it regardless of technical merits. Ty works fast and well enough for me, although I'm not fond of the formatting of its error messages.
That's wild. Is that documented anywhere?
So, pyright is written in TypeScript/JavaScript, and the "Python" package for it wraps around that. Which means on first use it has to actually download and install the TS/JS bits and a runtime (if necessary), and it looks like it uses npx as its runner, which lets you invoke an installed JS package as a command-line tool but I believe also checks for updates periodically. There's a similar pipx wrapper for invoking Python packages from the command line which definitely checks for updates when running.
So it's not some sort of hidden nefarious tracking, it's just a side effect of the way the thing is packaged and how the tools work.
Shameless plug: last year I repackage pyright properly for python in order to avoid these network calls: for those curious it's pyright-alright.
I haven't touched it since then, but if some are interested I can take time to restore regular release of the pyright releases like I do for pybun (Bun as a python package)
EDIT: Or maybe basedpyright is already doing it and it's not needed anymore !
Ah, thanks! Yes, it's worth pointing out that I'm referring to the Python package. I was implicitly taking that for granted as the thread's title mentions Python. See for example this issue.
I'm impressed by the Markdown test suite: https://github.com/astral-sh/ruff/blob/main/crates/ty_python_semantic/resources/mdtest/typed_dict.md and parent folder.
Anyone know if ty has LSP support for jumping to definitions etc? I am chomping at the bit to drop pyright once and for all
Why do you want to drop pyright?
I certainly got better experience with (based)pyright than with lsp-python that I was using before but I see your point here.
Yeah it's like... pyright is better than some of the other stuff (tho it being written in JS got on my nerves) but the license structure means that if I hit an issue I do not feel like contributing upstream to get it fixed.
I am glad ty , at least for now, is different (and I had already made a small contribution to it because I'm excited about having a real LSP option here)
(based)pyright is slow as LSP - once you try stuff like pyrefly the jump to definition is istantaneous
I should definitely try.
As an aside I find it cool that so many python tools recently are going for speed (among other things) and making people much happier doing this!
ty seems really good. One question -- if I want formatting and linting as well as type checking, am I supposed to use both ty and ruff, both via LSP?
Still alpha, it seems. I have considered moving my projects away from mypy, but I will wait a bit more I guess. I should start by moving them to strict mypy anyway.
this became trending because Charlie posted today on Twitter that they are going to release it (I suppose in beta) soon! https://x.com/charliermarsh/status/1995153742040330467
Has anybody tried it and compared it against zuban? I barely code in Python anymore, but whenever I've had to use it it worked without hitches
My current impressions are that zuban's semantic analysis is significantly further along than ty, but ty's LSP implementation is notably better (e.g. go-to-type actually works, more fault-tolerant parser, faster in some edge cases). I think ty made some more interesting foundational implementation choices (in particular, using salsa for incremental computation and miette for diagnostics), so I suspect as it improves I'll end up moving off of zuban.
I tried Zuban and while the LSP (as of two weeks ago) has more features it’s still not there (it’s a bit more strict: I had to have a init module in every dir to make go to definition work, while pyrefly did not).