uv check: Finally, Type Checking for Single-File Python Scripts
---
title: "uv check: Finally, Type Checking for Single-File Python Scripts"
published: true
description: "uv check brings ty type checking to single-file Python scripts with PEP 723 metadata. A 15-minute tutorial on Astral's experimental uv and ty integration."
tags: python, tooling, tutorial, devops
cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com
canonical_url: kielltampubolon.id
---
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:
!Card listing requirements (uv 0.12.3, ty 0.0.76), Astral's planned next steps, and the opt-in settings for environment setup.
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.
!A Python script with a PEP 723 inline dependency block, where ty reads the same block and flags status(42) as passing an int where a string is expected.
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
!Terminal showing uv self update, uv --version and uv check --script example.py, plus the project and workspace variants of uv check.
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?
Related on this blog
- UUIDv7 Is a Great Database Key and a Bad Clock: 4 Tests Before You Migrate
- My Scanner Passed Until I Built a Harness That Lied to It on Purpose
- My MCP Security Scanner Missed 2026's Worst MCP RCE: Here Is the One-Rule Fix
TypeScript Just Became #1 on GitHub. AI Is Why?
In August 2025, TypeScript passed Python and JavaScript to become the most used language on GitHub. GitHub's explanation wasn't a new framework. It was AI.
This video breaks down why AI and typed languages fit together: writing code is now almost free, so checking it is the new bottleneck, and a type checker is the fastest checker you have. We walk through a real typo that JavaScript ships to production and TypeScript catches before the code runs, and look at why 94% of compile errors in AI-written TypeScript are type errors.
CHAPTERS
0:00 TypeScript is #1 on GitHub
0:52 The two jobs: writing and checking
1:24 Reason 1: Instant feedback
2:54 Reason 2: Types are context
3:22 Reason 3: Safe big changes
3:53 Reason 4: The cost disappeared
4:20 Python, Rust and the wider shift
5:11 What this means for you
SOURCES
- GitHub, Octoverse 2025: "A new developer joins GitHub every second as AI leads TypeScript to #1": octoverse.github.com
- Mündler et al., "Type-Constrained Code Generation with Language Models", PLDI 2025: arxiv.org
- GitHub Blog, "Why AI is pushing developers toward typed languages", Jan 2026
- Meta Engineering, "Open-sourcing Pyrefly: a faster Python type checker written in Rust", May 2025: pyrefly.org
- Astral, "ty: an extremely fast Python type checker and LSP": astral-sh/ty
Subscribe to BytesExplainedtech for short, clear explanations of how software works.
#TypeScript #AI #programming
2 likes · 52 views
Mentions
> why this exists docs.basedpyright.com > 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 pylance-release#7180 and here ty#1190
@charliermarsh Done! - ty#4826 - ty#4827 - ty#4828
@EatonEmmerich astral-sh/ty: An extremely fast Python type checker and language server, written in Rust. astral-sh/ty
uv check: Finally, Type Checking for Single-File Python Scripts --- title: "uv check: Finally, Type Checking for Single-File Python Scripts" published: true description: "uv check brings ty type checking to single-file Python scripts with PEP 723 metadata. A 15-minute tutorial on Astral's experimental uv and ty integration." tags: python, tooling, tutorial, devops cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com canonical_url: kielltampubolon.id --- 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: !Card listing requirements (uv 0.12.3, ty 0.0.76), Astral's planned next steps, and the opt-in settings for environment setup. 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. !A Python script with a PEP 723 inline dependency block, where ty reads the same block and flags status(42) as passing an int where a string is expected. 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 !Terminal showing uv self update, uv --version and uv check --script example.py, plus the project and workspace variants of uv check. 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? Related on this blog - UUIDv7 Is a Great Database Key and a Bad Clock: 4 Tests Before You Migrate - My Scanner Passed Until I Built a Harness That Lied to It on Purpose - My MCP Security Scanner Missed 2026's Worst MCP RCE: Here Is the One-Rule Fix
Python type bugs shouldn't wait until runtime. 🐍 ty checks types and offers editor diagnostics and navigation. Catch mistakes while you code. 🔍 astral-sh/ty #Python #浇朋友 #蓝朋友 #互关 #fo
Python 类型错误，别等运行才发现。🐍 ty 能检查类型问题，还提供编辑器提示与代码导航。适合写项目时提前排雷。🔍 astral-sh/ty #Python #浇朋友 #蓝朋友 #互关 #fo
Repo y docs de ty (0.0.90, 20 oct 2026). Lo pruebas sin instalar con uvx ty check, o lo fijas con uv add --dev ty. El language server va en VS Code, PyCharm y Neovim, con autocompletado, auto-import e inlay hints. astral-sh/ty docs.astral.sh
TypeScript Just Became #1 on GitHub. AI Is Why? In August 2025, TypeScript passed Python and JavaScript to become the most used language on GitHub. GitHub's explanation wasn't a new framework. It was AI. This video breaks down why AI and typed languages fit together: writing code is now almost free, so checking it is the new bottleneck, and a type checker is the fastest checker you have. We walk through a real typo that JavaScript ships to production and TypeScript catches before the code runs, and look at why 94% of compile errors in AI-written TypeScript are type errors. CHAPTERS 0:00 TypeScript is #1 on GitHub 0:52 The two jobs: writing and checking 1:24 Reason 1: Instant feedback 2:54 Reason 2: Types are context 3:22 Reason 3: Safe big changes 3:53 Reason 4: The cost disappeared 4:20 Python, Rust and the wider shift 5:11 What this means for you SOURCES - GitHub, Octoverse 2025: "A new developer joins GitHub every second as AI leads TypeScript to #1": octoverse.github.com - Mündler et al., "Type-Constrained Code Generation with Language Models", PLDI 2025: arxiv.org - GitHub Blog, "Why AI is pushing developers toward typed languages", Jan 2026 - Meta Engineering, "Open-sourcing Pyrefly: a faster Python type checker written in Rust", May 2025: pyrefly.org - Astral, "ty: an extremely fast Python type checker and LSP": astral-sh/ty Subscribe to BytesExplainedtech for short, clear explanations of how software works. #TypeScript #AI #programming