ty

> why this exists https://docs.basedpyright.com/v1.40.2/type-server/ > The "type server protocol" is a desperate attempt from microsoft to prevent pylance from becoming obsolete by outsourcing its type checking to other language servers like basedpyright, ty or pyrefly -- while continuing to keep certain language server features exclusive to pylance. > This protocol benefits nobody except microsoft. It adds needless complexity to any language server that chooses to support it. Basedpyright does not support it and strongly advises other language servers to avoid supporting it as well. > For more info see here https://github.com/microsoft/pylance-release/discussions/718... and here https://github.com/astral-sh/ty/issues/1190#issuecomment-337...

A big benefit of letting agents run code is they can process data without bloating their context. LLMs are really good at writing python for data processing. I would suspect its due to Python having a really good ecosystem around this niche And the type safety/security issues can hopefully be mitigated by ty and pyodide (already used by cf’s python workers) https://pyodide.org/en/stable/ https://github.com/astral-sh/ty

icontract or pycontracts -like DbC Design-by-Contract type and constraint checking at runtime with or as fast as astral-sh/ty would make type annotations useful at runtime "Support runtime checking" : https://github.com/astral-sh/ty/issues/867 : > [ typeguard, beartype, trycast; mypyc ] mypyc/mypyc: Compile type annotated Python to fast C extensions https://github.com/mypyc/mypyc src: https://github.com/python/mypy/tree/master/mypyc .. docs: https://mypyc.readthedocs.io/en/latest/ : mypyc docs > Using type annotations > Strict runtime type checking: https://mypyc.readthedocs.io/en/latest/using_type_annotation... : > Mypyc ensures type safety both statically and at runtime. [...] `Any` types and erased types in general can compromise type safety, and this is by design. Inserting strict runtime type checks for all possible values would b

It's talking about Luau (gradually typed, https://luau.org/), not Lua. Hopefully https://github.com/astral-sh/ty will make the Python typing situation better, but absent that, Python typing is... not great. Honestly even with that it feels subjectively very finicky.

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

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

This is also documented at https://github.com/astral-sh/ty?tab=readme-ov-file#contribut... and https://github.com/astral-sh/ty/blob/main/CONTRIBUTING.md#re...

I'm not sure if they're gearing up for an announcement, but about 9 days ago they dropped the preview warning from their README. I'm assuming they're still working through final housekeeping items before formally announcing it. [1] https://github.com/astral-sh/ty/commit/7a6b79d37e165f2e73189...

I'm waiting for ty to get TypedDict checking. https://github.com/astral-sh/ty/issues/154

I recently discovered that the folks building uv and ruff are also building a type checker, and it already works really well (and fast!), despite beta status: https://github.com/astral-sh/ty

Hah, I stand corrected. In my defense, Ty make it a lot more obvious and ominous on their github (https://github.com/astral-sh/ty): > /!\ Warning > ty is in preview and is not ready for production use. > We're working hard to make ty stable and feature-complete, but until then, expect to encounter bugs, missing features, and fatal errors.

in the related FAQ https://github.com/google/pytype/issues/1925 they point explicitly to the future: > What alternatives can I consider? There are four Python static type checkers that can be considered: mypy and Pyright have been released to the community for a while and have well established user bases. Pyrefly, ty were announced recently at PyCon US 2025 and are in active development stage in the current time of August 2025 when this was written. mypy - https://github.com/python/mypy Pyright - https://github.com/microsoft/pyright Pyrefly - https://github.com/facebook/pyrefly ty - https://github.com/astral-sh/ty

ty is definitely not ready to be a pyright replacement yet. But it is usable as an LSP for simple things like go to definition, and deeper LSP features are on the roadmap for the eventual beta and GA releases. https://github.com/astral-sh/ty/blob/main/docs/README.md#oth...

> I am strongly against ty behaviour here. [ty developer here] Please note that ty is not complete! In this particular example, we are tripped up because ty does not do anything clever to infer the type of a list literal. We just infer `list[Unknown]` as a placeholder, regardless of what elements are present. `Unknown` is a gradual type (just like `Any`), and so the `append` call succeeds because every type is assignable to `Unknown`. We do have plans for inferring a more precise type of the list. It will be more complex than you might anticipate, since it will require "bidirectional" typing to take into account what you're doing with the list in the surrounding context. We have a tracking issue for that here: https://github.com/astral-sh/ty/issues/168