uv check: Finally, Type Checking for Single-File Python Scripts

Your most important Python code might be a 60-line script with three dependencies and no type checking. It is also the file most likely to be edited by an AI assistant and run before anyone reads the diff.

On October 13, 2026, Astral announced an experimental integration between uv and ty that goes straight at that gap.

TL;DR (for non-technical readers)

• Python developers have a new one-line tool that checks small scripts for a common class of mistakes before they run.
• It matters because quick internal scripts often end up running billing exports, data jobs and deployments, with far less review than “real” software.
• It is experimental, so it is a safety net and not a guarantee.
• Ask your tech team: “Which of our scripts get run in production, and does anything check them first?”

What was announced

Per the post:

1. ty understands PEP 723 inline script metadata. A single script that declares its own dependencies gets type checking and editor features against the right environment.
2. A new uv check command. It prepares the project environment, installs dependencies and runs ty.

Requirements are uv 0.12.3 or later and ty 0.0.76 or later. It is experimental. Astral says it plans to turn script support on by default, add automatic environment setup for regular projects, and bring Ruff into uv check. One detail worth noting: setting up an environment for a script is opt-in in the editor and CLI, because it means installing and running third-party code.

Why this fits

The friction was never type checking itself. It was the environment. A checker has to know which packages you import. A project has a venv. A loose script has nothing, so the checker either guesses or flags every import.

PEP 723 already put the dependency list inside the script. Now the checker reads the same block. One source of truth, no setup step to forget.

What practitioners are saying

I could not find a large discussion thread on this specific announcement yet, so these views come from the reaction to ty and to Astral more broadly.

• Speed is the headline. On the Hacker News thread for ty, one commenter reported mypy at 18 seconds on a large project versus roughly half a second for ty.
• Speed is not accuracy. Another commenter on that thread saw ty report about 1,600 diagnostics, mostly false positives, where Pyright found 10 real errors. That was an early build, and InfoWorld has since reported ty reaching beta, but it is a fair reminder to test on your own code.
• The ecosystem gap. A third voice argued that libraries like Django and SQLAlchemy lean on runtime magic that checkers handle badly, and that plugin support decides production readiness.
• Who owns the roadmap. The skeptic angle here is not technical. Astral joined OpenAI in March 2026, and some in the community worry that priorities will drift toward coding-agent workflows. Both companies have said uv, Ruff and ty stay open source, and the MIT license keeps forks possible, though commenters note that maintaining a fork is hard.

My take

I like this, and I would adopt it for scripts today, with the right expectations.

Where I agree with the crowd: speed matters less than trust. A type checker that cries wolf gets disabled within a week. So I would run uv check first on new scripts and treat its output as advice, not a gate, until you have seen its false-positive rate on your code.

Where I would push back on the worry about Astral’s ownership: it is a real governance question, but it is a reason to keep your usage portable, not a reason to avoid good tools. PEP 723 metadata and standard type annotations work with any checker. If you only use those, switching later costs you very little. The integration itself is the small, replaceable part.

For teams, the useful framing is that one-off scripts now have a cheap quality floor. That is relevant when AI assistants write and edit them. A type error caught at 6:04 is cheaper than a failure at 6:05.

Try it in 15 minutes

1. Update

uv self update
uv --version

You need 0.12.3 or later. If you installed uv another way, update with that package manager.

2. A script with a deliberate bug

# /// script
# requires-python = ">=3.12"
# dependencies = ["httpx"]
# ///
import httpx


def status(url: str) -> int:
    return httpx.get(url, timeout=5).status_code


print(status("https://example.com"))
print(status(42))

Save it as example.py. The last line passes an int where a string is expected.

3. Check it

uv check --script example.py

ty should flag status(42). If the command is unknown, your uv is too old or the experimental surface has moved, so re-read the announcement.

4. Check a project or workspace

uv check
uv check --package <name>
uv check --all-packages

5. Editor and CLI opt-in

VS Code setting from the post:

{
  "ty.experimental.useUv": "on"
}

For ty on its own:

TY_UV=scripts ty check

A habit worth pairing with it

Pin script dependencies. A bare httpx means the script changes behavior whenever a new release appears. Write httpx==<version you tested>, and consider a date cutoff when running:

uv run --exclude-newer 2026-10-01T00:00:00Z example.py

That limits resolution to packages published before the date, so a malicious release pushed yesterday cannot reach you today.

What it does not do

Type checking will not catch bad logic, wrong assumptions about an API, or valid code that does the wrong thing. It removes one class of cheap mistakes for the price of one command.

What to learn next

• The uv guide to scripts for inline metadata in depth.
• PEP 723, which is short and readable.
• The ty repository, to follow changes while the integration is experimental.

Question

Which of your “temporary” scripts is now something other people depend on, and would you let uv check be the first thing that reads it?

Originally published on DEV. Discussion happens there.