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

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!

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

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.

TypeScript takes the same approach in this scenario, and I assume this helps both be fast.

    const x = []
    x.push(1)
    type t = typeof x // number[]

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

And what do you use instead?

AI generated anything is a hellscape.

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

Unbelievable

The problem is that the conformance tests were mostly written by Eric Traut, so there's a natural bias towards specifying what Pyright does well. There's a lot of things Mypy does really well that should probably be implemented in Pyright.

PR is somewhat WIP-ish but I needed some motivation to do OSS work again :)

https://htmlpreview.github.io/?https://github.com/SimonSchic...

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