Announcing the Beta release of ty

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"

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!

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

AI generated anything is a hellscape.

And what do you use instead?

I really need better generics support before ty becomes useful. Currently decorators just make all return types unknown. I need something this to work:

    _F = TypeVar("_F", bound=Callable[..., Any])
    def my_decorator(*args: str) -> Callable[[_F], _F]: ...

Unbelievable

Wow, that's probably my go-to case of things going south, not "best case scenario". They sold to IBM, a famous graveyard for software, and on the way there changed from FOSS licensing to their own proprietary ones for software the community started to rely on.

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

Various tickets asking for it, but they also want to bundle in the python interpreter itself, which is out of scope for a pyproject.toml manager: https://github.com/astral-sh/uv/issues/5802

  x = []
  x.append(1)
  x[0] = "new"
  x[0] + "oops"

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

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

No, static typing is usually used AOT (most frequently at compile time), not usually at runtime (types may or may not exist at runtime; they don't in Haskell, for instance.)

Python type checking is also AOT, but (unlike where it is inextricably tied to compilation because types are not only checked but used for code generation) it is optional to actually do that step.

Python type annotations exist and are sometimes used at runtime, but not usually at that point for type checking in the usual sense.

Educate yourself before making such claims.