Ty: A fast Python type checker and language server

:wave:<p>Looks like you found the not-so-secret repository we&#x27;re using to prepare for a broader announcement :)<p>Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We&#x27;re excited to get this in people&#x27;s hands, but want to set the expectation that we still have a lot of work left to do before this is production ready.<p>Stay tuned for more for news in the near future!<p>(... I work at Astral)

I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.

The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.<p>The reason we&#x27;re stuck on mypy at work is because it&#x27;s the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods.<p>I wish more python tooling took the TS approach of &quot;what&#x27;s in the wild IS the language&quot;, as opposed to a &quot;we only typecheck the constructs we think you SHOULD be using&quot;.

Just compared the time to check on a fairly large project:<p>- mypy (warm cache) 18s<p>- ty: 0.5s (and found 3500 errors)<p>They&#x27;ve done it again.

Not the most fun question, but as I see Astral taking over the python ecosystem, I can&#x27;t help but wonder: how do y&#x27;all plan to make money? It seems like you&#x27;ve taken VC funding, so monetization is inevitable.

If you have uv installed, you can test it without installing by running:<p><pre><code> uvx ty check</code></pre>

prior to astral appearing, python&#x27;s tooling has been beyond terrible, compared to say, Java&#x27;s<p>astral have now replaced the awful pip with the fantastic uv<p>various awful linters with with the fantastic ruff<p>and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one!<p>I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!

Very excited to have a new fully featured Python language server working in both vscode and vscode forks (e.g. Windsurf, Cursor).<p>Pylance is borked on these forked distributions, so having a new solid alternative here that doesn&#x27;t involve adopting yet another forked Pyright implementation (BasedPyright, Cursor Pyright, Windsurf Pyright, ...) sounds great to me.

Have these guys figured out how to make money yet?

Interesting to see astral come out with this right around facebook’s release of “Pyrefly, a faster Python type checker written in Rust”.<p>Not making any sort of ethical statement, just interesting that rust keeps eating the python and JS tooling worlds.

Will it support Django stubs? Only blocker for my company to switch

I am literally checking HackerNews while I wait for mypy to finish running, so I am excited to hear a faster type checker is on the way! Hope the error messages are also helpful.

Awesome work. What is the business model for these astral tools? It’s a bit of a “waiting for the other shoe to drop” feeling after seeing the VC backing on the company page.

If this will be only 50% as awesome as ruff or uv, it will be a future must-have for me.

I was wondering when someone would write a type checker in Rust, seemed like an obvious thing to do given how slow mypy is.

It’s like when we hit a new month the quota of “talk about Rust” credits is renewed.

I&#x27;ve been looking forward to this since the original announcement (and before, really).<p>On the modest codebase I tried it on (14k LOC across 126 files), it runs in 149ms compared to 1.66s in pyright (both run via uvx &lt;tool&gt;). I couldn&#x27;t get it to play nicely with a poetry project, but it works fine (obviously) in a uv project.<p>Definitely some false-positives, as expected. Interestingly, it seems to hate the `dict()` initializer (e.g. `dict(foo=&quot;bar&quot;)`).

Probably not a top priority but it would be really really cool if this thing had solid t-string support from the jump, to the extent that it’s feasible without actually executing code

See the thing about astral is that they get why Python has been successful in the first place:<p>When it was released it might have been one of the easiest to use languages.<p>The focus on tooling and making the tooling fast has been sharp. Seeing people recommend using non-astral tooling seems nuts at this point.

Perhaps a silly question. Will ty be usable for getting semantical completions &#x2F; suggestions. Similar to using pyright to get completions based on what&#x27;s being written.

Fingers crossed this is&#x2F;becomes extensible. Pyright and MyPy both suffer from lack of extensibility IMO (Pyright doesn&#x27;t consider the use case and MyPy plugins come across as an afterthought with limited capabilities). There are many things that can be built on the back of type-checked AST.

Any plans to create an official ty github action? I&#x27;ve been loving the ruff github action.

I installed it in VSCode and removed Mypy, I haven&#x27;t looked back: <a href="https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items&#x2F;?itemName=astral-sh.ty" rel="nofollow">https:&#x2F;&#x2F;marketplace.visualstudio.com&#x2F;items&#x2F;?itemName=astral-...</a>

Great job!

Curious why so many people want to implement type checkers for python? What problems are being solved that aren&#x27;t covered already?

Looks good but it has the same issues that i have with mypy. Packages that don&#x27;t include the type hints blow-up my process. In mypy i&#x27;ve come to terms with strategically ignoring packages or finding a package of type hints. Mypy is runs cleanly on my project but I get &gt;800 errors with TY, mostly things like:<p>lint:unresolved-import: Cannot resolve imported module `pydantic` --&gt; vartia&#x2F;usr_id.py:4:6 | 2 | from typing import Optional, Any 3 | from enum import Enum 4 | from pydantic import BaseModel, ConfigDict<p>looking forward to the release version.

Glad to see that we have the type-checking equivalent of Ruff!

Does it support go to definition and other lsp features?

uv is an incredible tool ; ty will be also. It&#x27;s insanely fast<p>For now, I have some false negative warnings :<p>&#x27;global&#x27; variables are flagged as undefined `int:unresolved-reference: Name ... used when not defined` (yeah, it&#x27;s bad, I know)<p>f(*args) flagged as missing arguments `lint:missing-argument: No arguments provided for required parameters ...`

How does Astral plan on making money?

This will be similar to Typescript I assume? If so I can’t wait to use it!! I cant count how many times I’ve searched for “TS like in Python” since I’ve started working on Python codebase. TS is so awesome that I use it 100% on new projects. Ruff is also very good, but with this, large code base Python will be a breeze to work with

Is this the same thing as Red Knot?

I&#x27;ve been looking forward to this for what seems like an age.

Recently I started a python project and I wanted to do it the &quot;proper&quot; way. mypy + pylint. But even on this small 15-20kloc program these tools are way to slow to do anything in realtime. It takes double digit seconds to have feedback. Way to long for an LSP. I&#x27;m honestly appalled the state of affairs is this bad. What the hell do people do with moderately or even large sized code bases?

Astral killing it with the Python tooling.

holy shit this is happening

How about we just stop creating non type safe languages. Would save everyone so much hassle.<p>[bring on the downvotes]