Announcing the Beta release of ty

Posted by gavide 12/16/2025

Announcing the Beta release of ty(astral.sh)

854 points | 179 commentspage 2

akdor1154 12/16/2025|

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.

0cf8612b2e1e 12/16/2025||

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.

selcuka 12/16/2025||

Ty doesn't support Django yet, and it doesn't have a plugin system, so third party developers can't improve it. If you need Django support, it is better to stick to mypy or pyright for the time being.

0cf8612b2e1e 12/17/2025||

Is Django planned? Or always going to be a non first party kind of deal?

selcuka 12/17/2025||

It is being planned, but there is no timeframe [1]:

> We are planning to add dedicated Django support at some point, but it's not on our short-term roadmap

[1] https://github.com/astral-sh/ruff/pull/21308#issuecomment-35...

czue 12/18/2025||

They say in the docs that they want Django support before the official release.

davidhalter 12/18/2025||

Feel free to use Zuban, it already supports Django models and is way ahead in typing support (and it's probably as fast as Ty).

albert_e 12/17/2025||

Slight tangent

I recently viewed tutorials on uv and ruff from Corey Schafer on youtube which were excellent

Hope to make these tools part of my defaults

Look forward a similar overview by Corey on ty :)

Curious ..is there any backstory to these library names?

japhyr 12/17/2025|

I believe the've been looking for two-letter names that aren't already taken, and are easy to type. I think I heard that from one of the podcasts that Charlie Marsh was on.

benrutter 12/17/2025||

Source here for anyone interested[0]. From memory, Ruff was its own thing, (I think named after the bird?) since then they've tried to give projects short letter combinations for consistency and ease of typing (uv, ty, pyx)

[0] https://talkpython.fm/episodes/download/520/pyx-the-other-si...

zanie 12/17/2025||

Ruff wasn't named after the bird, we just think it's funny that Charlie didn't know it was a bird. He made up the word :)

collinmanderson 12/17/2025|||

I've always assumed it was something like:

ruff - "RUst Formatter".

ty - "TYpe checker"

uv - "Unified python packaging Versioner"? or "UniVersal python packaging"

BiteCode_dev 12/18/2025||

Also note that R, U and T are one letter away to spell Rust.

benrutter 12/17/2025|||

Ah, thanks for demystifying!

tabbott 12/16/2025||

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.

f311a 12/16/2025||

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.

iamdanieljohns 12/16/2025|

The guy behind Zuban should've put his project out the in open way earlier. I'd love to see both projects succeed, but in reality it should become one.

davidhalter 12/18/2025|||

Zuban maybe doesn't succeed in terms of the amount of users, but it's nearly finished, supports the full Python type system (I'm in the process of completing the conformance tests), has support for Django and LSP support is also pretty much complete. So in a technical way it did already succeed.

It might not be used as much, but to be honest I think that's fine. I'm not a big VC-funded company and just hope to be able to serve the users it has. There's space for multiple tools in this area and it's probably good to have multiple type checkers in the Python world to avoid the typical VC rug pull.

the-wumpus 12/19/2025||

Zuban continues to have "not great" diagnostics like the rest of the python type checkers, where ty has "rust inspired" diagnostics that are extremely helpful. It's a shame to hear that the current state is considered "nearly finished".

davidhalter 12/21/2025||

Have you tried `--pretty`? That is more of a Rust style. Most type checker report the short version, but have longer versions of the issues. IMO that's a good choice, but opinions might differ.

arthur-st 12/17/2025|||

For real. I consider myself to be “into Python typing,” and yet I had no knowledge of Zuban before the parent comment and a very faint memory of Jedi.

Perepiska 12/18/2025||

So I've decided to give it a try. Open installation instructions and went thru "easy install with uvx" / "get and run our sgell script" until get "pip install ty". I do not want use other tools so I started it in pet project directory as "ty check". Is shows me progressbar and "98/99 files" then hang. I restarted it and it hung on "68/99" and started using 100% of cpu core. I waited for 15 min and killed it. Try to get more information about current file but there is no verbose mode but colorful "ty --help" output. Lets wait for a year then try again.

Edit: +"then try again"

dcreager 12/19/2025|

There was a hang/performance bug [1, 2] that was reported just after the beta release, which we've since fixed [3]. You might try seeing if we get through your entire project now?

(And as an aside, there _is_ a verbose mode: if you add `-vv` you'll get DEBUG-level log messages printing out the name of each file as we start to check it, and you can set TY_MAX_PARALLELISM=1 in your env to make it very clear which file is causing the hang. That's how we debug these kinds of issues when they're reported to us.)

[1] https://github.com/astral-sh/ty/issues/1968

[2] https://github.com/astral-sh/ty/issues/1993

[3] https://github.com/astral-sh/ruff/pull/22030

Atomic_Torrfisk 12/18/2025||

Serious question, Do we need another type checker in Python?

I've never really felt the existing options were lacking for our use case. Completely fair game if this was just a passion project, but at this point at best this feels like noise, at worst some overzealous developer is going to implement this in my teams pipeline and waste time. Waste his time because the existing type checker did the job and there was not reason to change it, and waste our time because they will likely change (probably tighten) the existing behavior and waste our time while we adapt our habits to it.

the-wumpus 12/19/2025|

The existing type checkers are slow. That's their reasoning for creating it. The type checking world in python is now reasonably well specified (and the type checkers are beginning to work more similarly), so I would expect (once ty is out of beta) you could replace your type checker with ty and just see a 20x speedup in CI and much much faster IDE diagnostics.

If it was going from 3s -> 1s then you'd probably be right, but on my work codebase pyright (which is the faster one!) takes 15 seconds (ty takes 0.8s) and takes a bit for errors to appear in the IDE. This is now fast enough for us (mypy was taking >30s, which was not fast enough), but if the project grew another order of magnitude (which it might) then it would probably be too slow.

It's the same reason ruff is great, linting the codebase is so so fast.

pcwelder 12/17/2025||

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.

sharkdp 12/17/2025|

We should generally support TypeDicts. Can you go into more details of what is not working for you?

pcwelder 12/17/2025||

```

from anthropic.types import MessageParam

data: list[MessageParam] = [{"role": "user", "content": [{"type": "text", "text": ""}]}]

```

This for example works both in mypy and pyright. (Also autocompletion of typedict keys / literals from pylance is missing)

sharkdp 12/17/2025||

Thank you!

I reported this as https://github.com/astral-sh/ty/issues/1994

Support for auto-completing TypedDict keys is tracked here: https://github.com/astral-sh/ty/issues/86

petesergeant 12/17/2025||

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.

woodruffw 12/17/2025||

Could you elaborate on what you mean? There are various typing PEPs; they even have their own category[1].

[1]: https://peps.python.org/topic/typing/

dcreager 12/17/2025||

And the PEPs are now collated into a larger single typing spec [1], even hosted on a python.org subdomain. (Previously it was hosted on readthedocs)

[1] https://typing.python.org/en/latest/

ReflectedImage 12/17/2025||

Speaking as a Python programmer, no. Using types in a prototyping language is madness.

The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster.

If you want slow development with types, why not Java?

maccard 12/17/2025|||

Have you written any go code? it's the closest I've come to actually enjoying a type system - it gets out of your way, and loosely enforces stuff. It could do with some more convenience methods, but overall I'd say it's my most _efficient_ type system. (not necessarily the best)

petesergeant 12/19/2025||||

If you can’t do fast prototypes with types, you need to get better at using types. It’s very fast to throw stuff together in TypeScript.

ReflectedImage 12/26/2025||

No one can do fast prototypes with types, all they can do is convince themselves they are faster than they really are.

Having worked in both dynamically typed and statically typed software development shops, the statically typed programmers are considerably slower in general. Usually they only have 1/3 of the output as programmers who use dynamically typing. Statically typed programmers also tend to be much less ambitious in their projects in general.

They still think they are "fast programmers" but it's complete fiction.

solarkraft 12/17/2025||||

because i want fast development with types.

ReflectedImage 12/26/2025||

Yeah, but that doesn't exist. Types and fast development are directly opposing goals.

This goes all the way back to Lisp vs C in the 1980s with C programs having triple the development time as Lisp programs.

To modern day with Turborepo taking 3 months to write in structually typed Go vs 14 months in statically typed Rust.

philipallstar 12/17/2025|||

> Using types in a prototyping language is madness.

It's not a prototyping language or a scripting language or whatever. It's just a language. And types are useful, especially when you can opt out of type checking when you need to. Most of the time you don't want to be reassigning variables to be different types anyway, even though occasionally an escape hatch is nice.

ReflectedImage 12/26/2025||

Types are not always useful, they increase the line count per delivered feature by 3x to 4x, which results in a corresponding increase in bugs in the delivered code and an corresponding increase in the overall software development costs.

It's very foolish to just use types in all programming projects.

maccard 12/17/2025|

I was underwhelmed by uv as a tool when it was announced, and when I started using it. For context, I'm a C++ developer who occasionally has to dip into python-land for scripts and tooling. I set up a new workstation about 6 months ago and decided I'd just use pip + venv again, and honestly I lasted 2 weeks before installing UV again. It's one of those tools that... doesn't really do much except _what you wanted the original tool to do_, and I'm hoping that Ty has the same effect.

More comments...