Announcing the Beta release of ty (astral.sh)

That's great news! TIL that ty is also a language server, which means it replaces not only mypy, but also Pyright in Neovim/VSCode.

The title of this story should be "Announcing the Beta release of ty". A lot of people have been waiting for the beta specifically.

I've been using Pyrefly and loving it compared to Pyright, but they recently shipped some updates with crash bugs that forced me to pin to a previous version, which is annoying. Unfortunately my first impression of ty isn't great either. Trying to install the ty extension on the current version of Cursor says "Can't install 'astral-sh.ty' extension because it is not compatible with the current version of Cursor (version 2.2.20, VSCode version 1.105.1)."

Hopefully it gets added to this comparison:

https://htmlpreview.github.io/?https://github.com/python/typ...

If that table is anything to go by, Pyright is not to be underestimated.

I have briefly tried ty (LSP) in Emacs and it seems to work well so far. The only questionable thing I've encountered is that when the signature of a method is shown, the type annotations of some parameters seem to be presented in a particularly verbose form compared to what I'm used to - maybe they're technically correct but it can be bit much to look at.

Anyway, odds are pretty good that ty is what I will end up using long-term, so thanks and congrats on releasing the first beta!

How conformant is this, compared to e.g. mypy?

Not impressed because when tried ruff, and discovered that it doesn't replace (basic) pylint check https://github.com/astral-sh/ruff/issues/970 so we have ruff then pylint (and looking at the number of awaiting PR of ruff feels bad)

Too bad they did not benchmark Zuban, which is also promising.

Also, it's also too bad we have three competing fast LSP/typechecker projects now We had zero 1 year ago.

Very excited to see this. I thought that speed does not matter much for python tooling, but then I tried uv, and realized that I was wrong. The experience is just better. Looking forward to see more high performance quality tooling for Python.

Very exciting! I guess I'll have to wait for Django and Pydantic support to migrate to it on Zulip, but type checking was the last major linter that's still slow in Python.

Beautiful acknowledgment list, and congratulations on the beta release!

I really hope astral can monetize without a highly destructive rugpull, because they are building great tools and solving real problems.

I still don’t understand how a single language can have multiple (what is it now, half a dozen?) different type checkers, all with different behaviour.

Do library authors have to test against every type checker to ensure maximum compatibility? Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?

Without digging too deep- what is the Django story?

Django does a bunch of magic which is challenging for the type checkers to handle well.

well, this is where being pedantic bites me in the a* again. Our codebase has been mostly pyright-focused, with many very specific `pyright: ignore[...]` pragmas. Now it would be great if ty (pyrefly has an option!) could also ignore those lines. There's not _that_ many of them, but .... it's a pain.

The codebase has none of the rust code. In fact even the python code in the code base is mostly just scripts for updating version tags and etc...

Seems like the code isn't actually open source which to me is a bit concerning. At the very least, if ya'll want to release it like this please be clear that you're not open source. The MIT license in the repo gives the wrong impression.

Thanks Astral team! We use Pydantic heavily, and it looks like first class support from Ty is slated for the stable release, we'd love to try it.

While we wait... what's everyone's type checking setup? We run both Pyright and Mypy... they catch different errors so we've kept both, but it feels redundant.

https://htmlpreview.github.io/?https://github.com/python/typ... suggests that Pyright is a superset, which hasn't matched our experience.

Though our analysis was ~2 years ago. Anyone with a large Python codebase successfully consolidated to just Pyright?

I am so pleased by ty’s stance that I should not have to add annotations to satisfy the type checker. I ripped out last type checker out because it was constantly nagging us about technicalities, but ty immediately found issues where we annotated that a duct was an acceptable input, but actually doing so would break things.

Wow, even if it wasn't so fast, I'd be tempted to use this solely due to their support of intersection (A & B) types! This is a sore omission from the standard python typing system.

rust again? ill skip

Is there any study that shows that typing in Python improves code quality and reduce runtime issues?

is there anything like `uv` available for ruby? going from python and typescript where I can use uv and bun, it feels like ruby is stuck in the past :(

Displaying inferred types inline is a killer feature (inspired from rust lang server?). It was a pleasant surprise!

It's fast too as promised.

However, it doesn't work well with TypedDicts and that's a show-stopper for us. Hoping to see that support soon.

Django support will be a game changer on top of the game changer ty is!

Super excited about this generally ok satisfied with pyright but so I was with conda before uv or black before ruff.

I was reading the list of their offerings in the footer and for a second was very excited by the 5th item:

> RUFF 0.14.9

> UV 0.9.18

> TY 0.0.2

> PYX Beta

> GITHUB

Python programmers are crying out for types it seems. It’s a shame the Python foundation haven’t blessed a spec. Better to get everyone working on a single slightly imperfect standard than a morass or differing ideas.