Announcing the Beta release of ty

Posted by gavide 7 days ago

Announcing the Beta release of ty(astral.sh)

853 points | 176 commentspage 2

akdor1154 7 days ago|

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 7 days ago||

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 7 days ago||

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 7 days ago||

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

selcuka 7 days ago||

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 6 days ago||

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

davidhalter 6 days ago||

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 7 days ago||

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 7 days ago|

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 7 days ago||

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 7 days ago||

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 7 days ago|||

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 6 days ago||

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

benrutter 6 days ago|||

Ah, thanks for demystifying!

tabbott 7 days ago||

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 7 days ago||

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 7 days ago|

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 6 days ago|||

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 5 days ago||

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 2 days ago||

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 7 days ago|||

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 6 days ago||

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 5 days ago|

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 6 days ago||

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 5 days ago|

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 7 days ago||

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 7 days ago|

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

pcwelder 7 days ago||

```

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 7 days ago||

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 7 days ago||

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 7 days ago||

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 7 days ago||

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 7 days ago||

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 7 days ago|||

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 5 days ago||||

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.

solarkraft 7 days ago||||

because i want fast development with types.

philipallstar 7 days ago|||

> 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.

maccard 7 days ago|

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...