Announcing the Beta release of ty

471 pointsposted 10 hours ago
by gavide
(astral.sh)

88 Comments

frou_dh

9 hours ago

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!

hauntsaninja

7 hours ago

Note: while spec conformance is important, I don't recommend using it as the basis for choosing a type checker. It is not representative of the things that most users actually care about (and is not meant to be).

(I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)

SmileyKeith

7 hours ago

Can you add some examples of the things users care about that aren't well covered by this? I empathize with everyone who wants a feature comparison chart so they can be confident switching without unknowingly losing important safety checks.

hauntsaninja

4 hours ago

The conformance test suite is currently mostly focused on “what does an explicit type annotation mean”

A shared spec for this is important because if you write a Python library, you don’t want to have to write a different set of types for each Python type checker

Here are some things the spec has nothing to say about:

Inference

You don’t want to annotate every expression in your program. Type checkers have a lot of leeway here and this makes a huge difference to what it feels like to use a type checker.

For instance, mypy will complain about the following, but pyright will not (because it infers the types of unannotated collections as having Any):

  x = []
  x.append(1)
  x[0] + "oops"
The spec has nothing to say about this.

Diagnostics

The spec has very little to say about what a type checker should do with all the information it has. Should it complain about unreachable code? Should it complain if you did `if foo` instead of `if foo()` because it’s always true? The line between type checker and linter is murky. Decisions here have nothing to do with “what does this annotation mean”, so are mostly out of scope from the spec.

Configuration

This makes a huge difference when adapting huge codebases to different levels of type checking. Also the defaults really matter, which can be tricky when Python type checkers serve so many different audiences.

Other things the spec doesn’t say anything about: error messages quality, editor integration, speed, long tail of UX issues, implementation of new type system features, plugins, type system extensions or special casing

And then of course there are things we would like to spec but haven’t yet!

maleldil

3 hours ago

> but pyright will not (because it infers the types of unannotated collections as having Any)

This is incorrect. pyright will infer the type of x as list[Unknown].

hauntsaninja

an hour ago

Unknown has the exact same type system semantics as Any.

Unknown is a pyright specific term for inferred Any that is used as the basis for enabling additional diagnostics prohibiting gradual typing.

Notably, this is quite different from TypeScript’s unknown, which is type safe.

dcre

6 hours ago

I think the idea is not that there are features that aren’t listed, but rather that if a typechecker supports 10 features people care about and is missing 10 that people don’t really use, it will look a lot worse on a list like this than a typechecker with 100% compliance, when in practice it may not really be worse at all.

Edit: Based on this other comment, the point was also about things not covered by the spec. “The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference.” https://news.ycombinator.com/item?id=46296360

codys

6 hours ago

The chart does not describe speed (either in general or in any particular case). Speed/performance/latency is a thing users care about that is not included in the feature list.

SmileyKeith

5 hours ago

Yea that one is fine and well covered in the blog post, and pretty easy to spot in light testing. I'm much more worried about the ones that are harder to spot until you have a false negative that turns into a real bug which would be caught by 1 tool and not another.

_carljm

9 hours ago

We'll be adding ourselves to that table soon. We'll have some work to catch up with pyright on conformance, but that's what the time between now and stable release is for.

progbits

8 hours ago

pyright is very good, but there is also https://docs.basedpyright.com/latest/ which improves on it further.

That said I'm very happy user of uv, so once Ty becomes ready enough will be happy to migrate.

conception

6 hours ago

Basedpyright plus any AI generated python is a hellscape unless you use hooks and have a lot of patience.

bravura

2 hours ago

Do you mind elaborating?

And what do you use instead?

WD-42

8 hours ago

Pyright has been great. But it’s slow. Speed of a LSP does matter for UX. Excited to see how much ty improves on this.

morkalork

3 hours ago

Is it wrong to to say that I don't like pyright on principle because it requires node.js and npm to install and run?

IshKebab

9 hours ago

Pyright is really really good. Anyone that doubts that 10x engineers exist, just go and look at Eric Traut. He's pretty much written it single handedly. Absolute machine.

Mypy is trash. Nice to have a table to point to to prove it.

buibuibui

8 hours ago

Oh my, I just looked him up. He is the developer of Virtual Game Station - a PS1 emulator that I used in the past to play PS Isos on my Windows ME PC! What a legend.

klysm

8 hours ago

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

amanzi

7 hours ago

"pyx" is their first commercial offering: https://astral.sh/pyx

I agree though. Hope this is successful and they keep building awesome open-source tools.

jbmsf

4 hours ago

We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff.

It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.

clircle

5 hours ago

Why the “y” look so wrong in the special font.

tabbott

8 hours ago

Yeah their work thus far has been an incredible public service to the Python community.

tyre

6 hours ago

Feels like they’re headed in the direction of bun.

mi_lk

4 hours ago

In zero revenue or acquisition direction

rockwotj

4 hours ago

Thankfully all these LLM labs are heavily invested in python so this seems like the likely route IMO

ares623

an hour ago

Just need to book a long nice walk with one of the CEOs

bmitc

6 hours ago

My issue with them is that they claim their tools replace existing tools, but they don't bother to actually replicate all of the functionality. So if you want to use the full functionality of existing tools, you need to fall back on them instead of using Astral's "replacements". It's like one step forward and one step back. For me personally, speed of the tooling is not as important as what the tooling can check, which is very important for a language like Python that is very easy to get wrong.

woodruffw

4 hours ago

If there are specific incompatibilities or rough edges you're running into, we're always interested in hearing about them. We try pretty hard to provide a pip compatibility layer[1], but Python packaging is non-trivial and has a lot of layers and caveats.

[1]: https://docs.astral.sh/uv/pip/

amluto

4 hours ago

Is there any plan for a non-“compatibility layer” way to do anything manual or nontrivial? uv sync and uv run are sort of fine for developing a distribution/package, but they’re not exactly replacements for anything else one might want to do with the pip and venv commands.

As a very basic example I ran into last week, Python tooling, even the nice Astral tooling, seems to be almost completely lacking any good detection of what source changes need to trigger what rebuild steps. Unless I’ve missed something, if I make a change to a source tree that uv sync doesn’t notice, I’m stuck with uv pip install -e ., which is a wee bit disappointing and feels a bit gross. I suppose I could try to put something correct into cache-keys, but this is fundamentally wrong. The list of files in my source tree that need to trigger a refresh is something that my build system determines when it builds. Maybe there should be a way to either plumb that into uv’s cache or to tell uv that at least “uv sync” should run the designated command to (incrementally) rebuild my source tree?

(Not that I can blame uv for failing to magically exfiltrate metadata from the black box that is hatchling plus its plugins.)

woodruffw

4 hours ago

> Is there any plan for a non-“compatibility layer” way to do anything manual or nontrivial?

It's really helpful to have examples for this, like the one you provide below (which I'll respond to!). I've been a maintainer and contributor to the PyPA standard tooling for years, and once uv "clicked" for me I didn't find myself having to leave the imperative layer (of uv add/sync/etc) at all.

> As a very basic example I ran into last week, Python tooling, even the nice Astral tooling, seems to be almost completely lacking any good detection of what source changes need to trigger what rebuild steps.

Could you say more about your setup here? By "rebuild steps" I'm inferring you mean an editable install (versus a sdist/bdist build) -- in general `uv sync` should work in that scenario, including for non-trivial things where e.g. an extension build has to be re-run. In other words, if you do `uv sync` instead of `uv pip install -e .`, that should generally work.

However, to take a step back from that: IMO the nicer way to use uv is to not run `uv sync` that much. Instead, you can generally use `uv run ...` to auto-sync and run your development tooling within an environment than includes your editable installation.

By way of example, here's what I would traditionally do:

    python -m venv .env
    source .env/bin/activate
    python -m pip install -e .[dev] # editable install with the 'dev' extra
    pytest ...

    # re-run install if there are things a normal editable install can't transparently sync, like extension builds
Whereas with uv:

    uv run --dev pytest ... # uses pytest from the 'dev' dependency group
That single command does everything pip and venv would normally do to prep an editable environment and run pytest. It also works across re-runs, since it'll run `uv sync` as needed under the hood.

amluto

4 hours ago

Their integration with existing tools seems to be generally pretty good.

For example, uv-build is rather lacking in any sort of features (and its documentation barely exists AFAICT, which is a bit disappointing), but uv works just fine with hatchling, using configuration mechanisms that predate uv.

(I spent some time last week porting a project from an old, entirely unsupportable build system to uv + hatchling, and I came out of it every bit as unimpressed by the general state of Python packaging as ever, but I had no real complaints about uv. It would be nice if there was a build system that could go even slightly off the beaten path without writing custom hooks and mostly inferring how they’re supposed to work, though. I’m pretty sure that even the major LLMs only know how to write a Python package configuration because they’ve trained on random blog posts and some GitHub packages that mostly work — they’re certainly not figuring anything out directly from the documentation, nor could they.)

eyeris

4 hours ago

Got any examples in mind?

pcwelder

18 minutes 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

13 minutes ago

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

shrumm

8 hours ago

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?

gwking

6 hours ago

I appreciate the even tempered question. I’ve been using mypy since its early days, and when pyright was added to vs code I was forced to reckon with their differences. For the most part I found mypy was able to infer more accurately and flexibly. At various times I had to turn pyright off entirely because of false positives. But perhaps someone else would say that I’m leaning on weaknesses of mypy; I think I’m pretty strict but who knows. And like yourself, mine is a rather dated opinion. It used to be that every mypy release was an event, where I’d have a bunch of new errors to fix, but that lessened over the years.

I suspect pyright has caught up a lot but I turned it off again rather recently.

For what it’s worth I did give up on cursor mostly because basedpyright was very counterproductive for me.

I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.

hauntsaninja

4 hours ago

I’ve added ecosystem regression checks to every Python type checker and typeshed via https://github.com/hauntsaninja/mypy_primer. This helped a tonne with preventing unintended or overly burdensome regressions in mypy, so glad to hear upgrades are less of an Event for you

shrumm

6 hours ago

> I will say that I’ve seen a lot more vehement trash talking about mypy and gushing about pyright than vice versa for quite a few years. It doesn’t quite add up in my mind.

agreed! mypy's been good to us over the years.

The biggest problem we're looking to solve now is raw speed, type checking is by far the slowest part of our precommit stack which is what got us interested in Ty.

hauntsaninja

7 hours ago

Mentioned this in another comment, but the spec conformance suite is not representative of the things users care about (nor is it meant to be).

The spec mostly concerns itself with the semantics of annotations, not diagnostics or inference. I don't really recommend using it as the basis for choosing a type checker.

(I was on the Python Typing Council and helped put together the spec, the conformance test suite, etc)

modeless

9 hours ago

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

charliermarsh

9 hours ago

If there's anything else accompanying the error, do you mind filing an issue? I've been using the ty extension with Cursor for weeks and am having trouble reproducing right now.

modeless

9 hours ago

That's the full error. It shows up in a dialog box when I press the install button. I'm on macOS, connected with the Anysphere Remote SSH extension to a Linux machine.

If I choose "install previous version" I am able to install the pre-release version from 12 hours ago without issue. Then on the extension page I get a button labeled "Switch to Release Version" and when I press it I get an error that says "Can't install release version of 'ty' extension because it has no release version." Filed a GitHub issue with these details.

In the meantime, the previous version appears to be working well! I like that it worked without any configuration. The Pyrefly extension needed a config tweak to work.

_carljm

8 hours ago

https://forum.cursor.com/t/newly-published-extensions-appear... suggests that there's some kind of delayed daily update for new VSCode extension versions to become available to Cursor? It seems likely that's what is happening here, since ty-vscode 0.0.2 was only published an hour or two ago.

modeless

8 hours ago

Oh, huh, and since there's no previous release version it just fails to install completely? That's unfortunate.

_carljm

9 hours ago

I can reproduce this; we're looking into it.

pansa2

8 hours ago

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?

WD-42

8 hours ago

You’re talking about a duck typed language with optional type annotations. I love python but that’s a combination that should explain a bit why there are so many different implementations.

MangoToupe

an hour ago

It doesn't. Either the optional type annotations have precise semantics or they don't.

dwattttt

an hour ago

What should a type checker say about this code?

  x = []
  x.append(1)
  x[0] = "new"
  x[0] + "oops"
It's optionally typed, but I would credit both "type checks correctly" and "can't assign 'new' over a number" as valid type checker results.

MangoToupe

an hour ago

It depends on the semantics the language specifies. Whether or not the annotations are optional is irrelevant.

Either way, you didn't annotate the code so it's kind of pointless to discuss.

Also fwiw python is typed regardless of the annotations; types are not optional in any sense. Unless you're using BCPL or forth or something like that

sagarm

an hour ago

They don't. They're just documentation.

mikepurvis

6 hours ago

At least some of it is differing policies on what types can be inferred/traced through the callers vs what has to be given explicitly.

I think everyone basically agrees that at the package boundary, you want explicit types, but inside application code things are much more murky.

(plus of course, performance, particularly around incremental processing, which Astral is specifically calling out as a design goal here)

mirashii

8 hours ago

> Do library authors have to test against every type checker to ensure maximum compatibility?

Yes, but in practice, the ecosystem mostly tests against mypy. pyright has been making some inroads, mostly because it backs the diagnostics of the default VS Code Python extension.

> Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?

You can provide your own type stubs instead of using the library's built-in types or existing stubs.

collinmcnulty

8 hours ago

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.

Ch00k

10 hours ago

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.

0cf8612b2e1e

8 hours 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

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

akdor1154

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

f311a

9 hours 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

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

fkarg

8 hours ago

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.

Svoka

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

tabbott

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

sails01

7 hours ago

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

hexo

7 hours ago

Well, it's just a documentation suggestion for user. Having for me about same value as if it was written in pydoc. I'd really love to see such study as well

sails01

5 hours ago

Agree, we already had a solution documenting types in docstring.

In my case they just add noise when reading code and make it more difficult to review

bmitc

6 hours ago

That's equivalent to asking if there are benefits of static typing.

pansa2

5 hours ago

Specifically, it's like asking if there are any studies that demonstrate benefits of static typing. Are there?

sails01

6 hours ago

Not quite, static typing is used at runtime, python type annotations are not

amethyst

5 hours ago

tools like dataclasses and pydantic would like to have a word...

Zababa

8 hours ago

Beautiful acknowledgment list, and congratulations on the beta release!

hexo

7 hours ago

rust again? ill skip

almanael

9 hours ago

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)

zanie

9 hours ago

As noted in the linked issue

> At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff.

ty is actually a big step in this direction as it provides multi-file analysis and type inference.

(I work at Astral)

syiblet

8 hours ago

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.

bobthecowboy

8 hours ago

At least as of a couple months ago, `ty` was actually being developed in the `ruff` repo (per an pdocast interview the devs did on Talk Python), so that might be why the `ty` repo looks empty (and pulls in ruff as a git submodule).