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.

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

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

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.

There are ways to type invariant generics more precisely that still meet the gradual guarantee. E.g.:

  x = []  # list[Unknown]
  x.append(A())  # list[Unknown | A]
  takes_list_of_a_or_b(x)  # list[A | B]

We haven't decided yet if this is what we want to do, though. It's also possible that we may decide to compromise on the gradual guarantee in this area. It's not an ironclad rule for us, just something we're considering as a factor.

ty also implements gradual set-theoretic types, and can represent "ranged" dynamic types (as intersections or unions with Any/Unknown). We don't currently refine dynamic type based on all uses, as suggested here, though we've considered something very much like this for invariant generics.

In your example, wouldn't `none()` be a type for `x` that satisfies both `Integer.to_string(x)` and `Atom.to_string(x)`? Or do you special-case `none()` and error if it occurs?

Oh, that’s exciting to hear! I would love to exchange notes and I know one of the lead researchers of set theoretic types would love to learn more about your uses too. If that sounds fun to you, you can find me on Gmail (same username).

In our case, we implement a bidirectional system where before applying x to Integer.to_string, we compute the domain of Integer.to_string (which is integer) and pass it up. If x is a dynamic type, then we refine it. So on the first call, x refines to `dynamic & integer`, then we apply it.

The second refinement fails because it becomes none, so we discard it, but it means the application on Atom.to_string will fail anyway. So yes, we check for emptiness and discard none.

Yes, thank you for your graciousness and generosity, very much appreciated.

Not the same headline functionality yet, no. At the moment all we support is diagnostics (some of which may be wrong) and go-to-type-definition. More will come.

Thanks for the indulgence. My question was unreasonable, upon reflection, in light of the other information you’ve already provided in the thread.

Yes, we've talked; I know a number of the pyrefly devs well. Ty had already been months in development when pyrefly development started. We discussed collaboration, but they decided they needed to do their own thing in order to move quickly and ensure it would serve their needs, which is totally reasonable.

It looks like both projects seem to use Ruff at their core, is there any documentation that describes the differences in each project's approach?

I believe the only sharing is parsing/ast.

There's a good chance many of the errors we emit are incorrect, at this stage. Lots to do still!

Wait wait wait

Carl, you did not tell me that the errors we emit need to be correct!!

I think I need to go revisit some of my PRs...

I knew we left something important out of that onboarding document

Why don't you just run ty on the ty codebase and let it tell you which errors are correct and which are erroneous?

The current version can handle importing pydantic without error just fine, but it probably can't find your virtualenv, so it doesn't know what third-party dependencies you have installed. Ty will discover your venv if it is in `.venv` in the project directory; otherwise you can help it out with the `--python` CLI flag.

We'll also discover your venv if you: - Activate it manually (`source .venv/bin/activate`, etc.) - Set the `VIRTUAL_ENV` environment variable - Or use a command such as `uv run` or the equivalent from pdm/poetry/hatch to run ty (these project managers usually implicitly set the `VIRTUAL_ENV` variable to point to the project's virtual environment before executing any commands)