python on Saurabh Kumar

django-ox

Wed, 30 Sep 2026 12:00:00 +0000

django-ox makes the database the Django task queue: transactional enqueue inside atomic(), no Redis/RabbitMQ, retries, worker-death recovery, recurring schedules, admin and metrics. Adoption read: pilot it for ordinary Django jobs; keep Celery for broker-scale workflows.

jetify-com/typeid

Sat, 26 Sep 2026 12:00:00 +0000

jetify-com/typeid is a spec for Stripe-style IDs: user_01h2xcejqtf2nbrexx3vqjhp41 is a snake_case type prefix, _, then a UUIDv7 in 26 chars of Crockford base32 (hex UUIDs take 36). Time-ordered, so B-tree inserts stay local, unlike UUIDv4. Double-click selects the whole ID, and a serializer expecting user_ rejects a pasted post_ ID. Strip the prefix and you get a valid UUIDv7 back, so the database never has to know. Cheap way to adopt: keep the column a native 16-byte uuid (DEFAULT uuidv7() on Postgres 18, uuid.uuid7() on Python 3.14) and encode/decode only at the API edge, e.g. a DRF serializer field on top of typeid-python. If PKs are already uuid, no schema change, and IDs explain themselves in logs and support tickets.

NVIDIA's NOOA framework

Tue, 28 Jul 2026 12:00:00 +0000

Python’s Ellipsis literal (...) is a real object (type(...) is <class 'ellipsis'>), not just a placeholder. Beyond type stubs and numpy slicing, NVIDIA’s NOOA framework repurposes it as a runtime dispatch marker: methods with ... bodies are completed by an LLM at runtime, while methods with real bodies stay deterministic Python. The boundary between “code I control” and “code the model controls” becomes greppable: grep -n '\.\.\.' agent.py. Clever reuse of existing syntax that linters and type checkers already accept.

django-crawl

Fri, 24 Jul 2026 12:00:01 +0000

django-crawl by Adam Johnson: BFS-crawls your Django site using the test client, no real HTTP overhead. Origin story: diffing CSP headers during a Django 6.0 migration accidentally caught 7 non-CSP bugs in a 100%-coverage project. HTML parsing via Rust (html5ever), follows links/sitemaps/feeds. Works as a management command or a TestCase smoke test that raises ExceptionGroup on errors.

import datetime as dt

Sat, 11 Jul 2026 12:00:00 +0000

Python 3.15 datetime docs now officially recommend import datetime as dt in a Tip block, to disambiguate the module from the datetime.datetime class. The tip cites Adam Johnson’s 2019 post — 6 years from community convention to CPython docs. Fixes both traps: from datetime import datetime shadows the module, and import datetime reads ambiguously as datetime.datetime.now(). via

Django ORM: From sync_to_async Threads to Native psycopg3

Sat, 13 Jun 2026 00:00:00 +0000

Django shipped async ORM methods back in 3.1. The a-prefixed methods, including aget(), afilter(), and acreate(), let calling code use coroutines, but the database work still blocked an OS thread. I want to explain that distinction and how the execution path changed.

Django 6.0 fixed it for real in December 2025. I want to walk through the path from “async via threads” to “native async via psycopg3,” because it is not a story about a feature landing. It is a story about three constraints that boxed Django in for five years: psycopg2 blocks, connection state lived in thread-locals, and the entire ORM assumed DB-API2. Once you see those three, every design decision Django made falls out of them almost mechanically.

The Thread-Based Async Path

When async views arrived in 3.1, the ORM underneath them was entirely synchronous. psycopg2 — the default PostgreSQL driver for most of Django’s life — wraps libpq, a C library with no async I/O surface at all. There is no flag you set to make psycopg2 async. You either replace the driver or you find a workaround.

Django found the workaround: asgiref.sync.sync_to_async.

# Simplified — what aget() actually did under the hood in Django 5.x
from asgiref.sync import sync_to_async

async def aget(self, *args, **kwargs):
 return await sync_to_async(self.get, thread_sensitive=True)(*args, **kwargs)

sync_to_async pushes the callable into a ThreadPoolExecutor. The event loop is not blocked, because the coroutine awaits the thread’s future. But a real OS thread is blocked, sitting on a TCP socket waiting for Postgres to answer. You moved the blocking, you did not remove it.

The thread_sensitive=True flag is the part that gives the game away. Django’s database connections lived in thread-locals:

# django/db/backends/base/base.py (pre-6.0)
import threading
_thread_local = threading.local()

Without thread_sensitive=True, two consecutive sync_to_async calls from the same request might land on different threads, see different thread-locals, and tear your transaction state in half. The flag pins every call within the same coroutine context to one dedicated thread, so the connection still looks like a single connection per request. This preserves the connection’s thread affinity.

Put it together and the cost is obvious. Five hundred concurrent async requests, each touching the database, need five hundred threads. That is the thread-per-connection model, even though the calling code uses coroutines.

Why psycopg2 Was a Dead End

You cannot retrofit async I/O onto psycopg2. It calls into libpq synchronously and blocks the calling thread until the query returns. The only way to run it in an async context is exactly what Django did: park it in a thread and await that thread. There was never a clever escape here.

The obvious alternative was asyncpg, a fully async PostgreSQL driver that beats psycopg3 on raw throughput. Django ruled it out, and the reasons are worth their own section further down. The short version is that asyncpg does not implement DB-API2 (PEP 249)¹, and Django’s ORM is built on DB-API2 from the ground up — cursor objects, execute(), fetchone(), fetchall(). You do not bolt a different contract onto twenty years of ORM and call it a driver swap.

psycopg3 is the answer that fits, because it does not force that choice.

psycopg3 Does Async And DB-API2 At The Same Time

psycopg3 — the package is just psycopg, not psycopg3 — was redesigned to support both synchronous and asynchronous execution through one shared core². The same query compilation logic runs both paths. What changes is the connection and cursor type you hand it.

# psycopg3 — synchronous path
with psycopg.connect(dsn) as conn:
 with conn.cursor() as cur:
 cur.execute("SELECT * FROM posts WHERE id = %s", [pk])
 row = cur.fetchone()

# psycopg3 — async path (same SQL, same parameters, different objects)
async with await psycopg.AsyncConnection.connect(dsn) as aconn:
 async with aconn.cursor() as cur:
 await cur.execute("SELECT * FROM posts WHERE id = %s", [pk])
 row = await cur.fetchone()

AsyncConnection and AsyncCursor use asyncio directly. The await cur.execute(...) suspends the coroutine and releases the event loop while the network I/O happens. No thread sits idle on a socket. That is the whole difference, and it is the difference that matters.

Django 6.0 made psycopg3 the recommended PostgreSQL driver and wired AsyncConnection and AsyncCursor into the backend.

What Django 6.0 Actually Changed

Three refactors enabled the switch. None of them are glamorous, and that is the point.

1. ContextVar Replaces Thread-Locals

Thread-locals are indexed by thread ID. Coroutines do not have thread IDs of their own — they share threads and switch between each other at await points. So thread-local connection storage is not merely awkward under async, it is structurally wrong. Think of a thread-local as a coat hook bolted to a single chair: it works only as long as one person stays in that chair the whole time. Coroutines stand up and swap chairs constantly.

The fix is contextvars.ContextVar, which arrived in Python 3.7. A ContextVar is scoped to the current execution context, and each asyncio Task gets its own context, copied from its parent when it is created. Django 6.0 moved connection storage off threading.local() and onto a ContextVar:

# django/db/backends/base/base.py (Django 6.0)
from contextvars import ContextVar

_connection: ContextVar = ContextVar('django_db_connection', default=None)

Two concurrent requests, both awaiting a query, each live in their own asyncio Task, each with their own context copy, each seeing their own connection. No locking, no thread affinity, no thread_sensitive gymnastics. The coat hook now travels with the person.

2. DatabaseWrapper Gets an Async Connection Path

DatabaseWrapper is the Django object that represents a database connection. Before 6.0 it exposed one path, self.connection, a synchronous psycopg2 connection. After 6.0 it also exposes async_connection():

# Conceptual — the async context manager on DatabaseWrapper
@asynccontextmanager
async def async_connection(self):
 conn = await psycopg.AsyncConnection.connect(**self.get_connection_params())
 _connection.set(conn)
 try:
 yield conn
 finally:
 await conn.close()

Django’s connection-handling code detects whether it is running inside an asyncio event loop and routes to the right path. You do not pick the path. The runtime does.

3. SQLCompiler Gets async_execute

The query compiler, SQLCompiler and its subclasses, is where Django turns a QuerySet into SQL and sends it to the database. Before 6.0 there was one path, execute_sql(). Django 6.0 adds async_execute_sql():

async def async_execute_sql(self, result_type=MULTI, chunked_fetch=False, chunk_size=GET_ITERATOR_CHUNK_SIZE):
 async with self.connection.async_connection() as conn:
 async with conn.cursor() as cursor:
 await cursor.execute(self.as_sql())
 if result_type == MULTI:
 return [row async for row in cursor]
 return await cursor.fetchone()

aget(), afilter(), aiterator() and the rest now route through async_execute_sql() instead of wrapping execute_sql() in sync_to_async. The thread pool drops out of the picture entirely.

The New Execution Stack

Here is how await Post.objects.aget(id=1) flows through Django 6.0:

await Post.objects.aget(id=1)
 └── QuerySet.aget()
 └── SQLCompiler.async_execute_sql()
 └── DatabaseWrapper.async_connection() # ContextVar-scoped
 └── psycopg.AsyncConnection
 └── AsyncCursor.execute()
 └── asyncio TCP socket write
 └── await socket read ← event loop released here
 └── row data returned

And here is the same call under Django 5.x:

await Post.objects.aget(id=1)
 └── QuerySet.aget()
 └── sync_to_async(thread_sensitive=True)(QuerySet.get)
 └── ThreadPoolExecutor — OS thread blocked
 └── SQLCompiler.execute_sql()
 └── psycopg2 connection (thread-local)
 └── libpq blocking TCP call
 └── thread wakes, result returned

The event loop is no longer handing work off to a thread. It suspends the coroutine, does other work, and resumes when the socket is readable. That is the entire reform, and it is enough.

What This Means For Concurrency

The practical payoff is in connection count. With the old thread approach, five hundred concurrent async requests meant up to five hundred threads and up to five hundred Postgres connections. Threads are cheap but not free — each costs roughly 8MB of stack by default, plus scheduler overhead.

With native async, those same five hundred requests can be multiplexed over a connection pool sized to what your database can actually handle, typically 10 to 50 connections, with the event loop running the wait queue. You use far fewer threads, one or a handful for the event loop workers, and far fewer database connections.

Django 6.0 also ships native connection pooling for the async path³, built on psycopg_pool.AsyncConnectionPool:

# settings.py — async pooling in Django 6.0
DATABASES = {
 "default": {
 "ENGINE": "django.db.backends.postgresql",
 "OPTIONS": {
 "pool": {
 "min_size": 2,
 "max_size": 10,
 },
 },
 "CONN_MAX_AGE": 0,
 }
}

This is the same pool option I covered in Django Native PostgreSQL Connection Pooling, with one difference that matters. In that post I warned against native pooling under ASGI — Django’s own docs recommended PgBouncer instead — because the sync pool and the event loop did not cooperate. Django 6.0’s AsyncConnectionPool is what closes that gap. The pool itself is now async-aware, so the ASGI caveat no longer applies on the native psycopg3 path. I was right to warn you then. You can stop worrying about it now.

Is sync_to_async Gone?

No, and it should not be. It is the fallback for drivers that cannot go native async:

Driver	Async path
psycopg3 (PostgreSQL)	Native `AsyncCursor` — no threads
psycopg2 (PostgreSQL)	`sync_to_async` thread wrap — still blocked
mysqlclient / MySQL	`sync_to_async` thread wrap
sqlite3	`sync_to_async` thread wrap

Run Django 6.0 against psycopg2 or MySQL in an async context and Django still falls back to the thread pool. The native path only exists when psycopg3 is installed and configured. The thread trick did not become wrong. It became the path of last resort.

The way forward for other databases is psycopg3-equivalent async drivers. MySQL has aiomysql, SQLite has aiosqlite. Django contributions for those backends are in progress but not stable in 6.0, so for now PostgreSQL is the database that gets the real thing.

asyncpg Is Still Faster, And Still Not Supported

Benchmark asyncpg against psycopg3 on raw async throughput and asyncpg wins, often by 20 to 40 percent on bulk read workloads. Django will not adopt it. The reasons are structural, not political, and I think Django is right.

No DB-API2. asyncpg uses positional $1, $2 parameters, not %s. The entire ORM query compiler assumes %s.
No synchronous fallback. Management commands, migrations, and sync views would need a whole separate code path.
A different transaction model. asyncpg handles transactions differently from the DB-API2 autocommit and explicit model Django manages internally.

Using asyncpg would require changes to the ORM, not just a driver swap. A driver benchmark alone does not measure that work. If you genuinely need asyncpg throughput with a Django-like ORM, look at SQLAlchemy 2.0 with its async session support and asyncpg backend, running under Starlette or FastAPI. For Django, psycopg3 is the correct answer.

Upgrading

To get the native async path today:

pip install "psycopg[binary,pool]"

# settings.py
DATABASES = {
 "default": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "mydb",
 "USER": "myuser",
 "PASSWORD": "mypassword",
 "HOST": "localhost",
 "CONN_MAX_AGE": 0,
 "OPTIONS": {
 "pool": True, # or dict with min_size/max_size
 },
 }
}

If you are on Django 5.2 LTS with psycopg3, you already get the synchronous psycopg3 path and connection pooling. The native async query path needs Django 6.0. You can upgrade the driver without upgrading Django and still get the pooling benefits in sync contexts, which is a fine thing to do while you wait.

Why It Took Five Years

Django’s async ORM story ran from “async with threads” in 3.1 in 2020 to “native async with psycopg3” in 6.0 in 2025. Five years sounds slow until you look at what had to be true first:

psycopg3 had to be stable enough to depend on, which it reached around 2022 to 2023.
Thread-local connection state was woven through the codebase, and the ContextVar migration touched hundreds of files.
The Django project is conservative about breaking changes, especially in database handling, where bugs are not cosmetic.

The result is correct and maintainable rather than the absolute fastest thing money can buy, and I do not think that was the wrong trade. For most Django applications — web services handling thousands of concurrent HTTP requests — native async with psycopg3 is already more than fast enough, and it integrates cleanly with everything else in the ecosystem.

Django Native PostgreSQL Connection Pooling — the sync side of the same story: configuring the psycopg3 pool, sizing min_size/max_size, and avoiding the CONN_MAX_AGE foot-gun.

PEP 249 — Python Database API Specification v2.0 — The DB-API2 spec that Django’s ORM is built on top of; asyncpg deliberately does not implement it. ↩︎
psycopg3 — Async operations — Official psycopg documentation on the async connection and cursor API. ↩︎
Django 6.0 Release Notes — Full changelog including async ORM changes, background tasks, and template partials. ↩︎

Django Modern REST

Thu, 02 Apr 2026 12:00:00 +0000

Django Modern REST seems to be an emerging REST API library with focus on performance, scalability and pluggable serializers. Supporting msgpack, CBV and less of sync_to_async. Might evaluate it against the my current preferred django-ninja. gemini

zoocache

Fri, 13 Feb 2026 12:00:00 +0000

zoocache is a sematic dependency based cache manager, that support in-memory, LMDB or redis backends. Integration with Django looks interesting.

Free-threaded Python in uv and GitHub Actions

Mon, 12 Jan 2026 12:00:00 +0000

The free-threaded version of python can be added to uv and github actions with t suffix. e.g. 3.14t and 3.13t source

how uv got so fast

Sat, 27 Dec 2025 12:00:00 +0000

how uv got so fast. UV performance is because of design decisions while rust contributes to micro optimizations.

LangGraph

Wed, 24 Dec 2025 12:00:00 +0000

“LangGraph is an orchestration framework for building stateful multi-agent applications using LLMs. It provides low-level primitives such as nodes and edges, along with built-in features that give developers granular control over agent workflows, memory management and state persistence. This means developers can start with a simple pre-built graph and scale to complex, evolving agent architectures. With support for streaming, advanced context management and resilience patterns like model fallbacks and tool error handling, LangGraph enables you to build robust, production-grade agentic applications. Its graph-based approach ensures predictable, customizable workflows and simplifies debugging and scaling.”

Django Native PostgreSQL Connection Pooling

Wed, 18 Jun 2025 00:00:00 +0000

Opening PostgreSQL connections adds overhead. Django 5.1 (released August 7, 2024) added native connection pooling¹, which lets an application reuse connections. Measure connection overhead and response times before and after enabling it; the benefit depends on your workload.

If you’re on Django 6+ and running async/ASGI, also see the async pool notes in How Django’s ORM Went From sync_to_async Threads to Native psycopg3.

Native Pooling vs External Pooling

PgBouncer runs as a separate pooling server. Django’s native pooling runs in the application process, so it does not require a separate server. It does require psycopg’s pool package. Third-party Django pooling packages and manual connection management are other options, with their own maintenance and configuration needs.

Configure Native Pooling

Requirements: Django 5.1+ and PostgreSQL (this feature does not work with psycopg2)²

Install the correct package:

pip install "psycopg[binary,pool]"

Critical: The package is called psycopg (not psycopg3). The pool functionality requires a separate package that this command installs automatically³.

Add these lines to your settings.py:

DATABASES = {
 "default": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "your_db_name",
 "USER": "your_db_user",
 "PASSWORD": "your_db_password",
 "HOST": "your_db_host",
 "PORT": "5432",
 "CONN_MAX_AGE": 0, # Required - pooling fails without this
 "OPTIONS": {
 "pool": True,
 },
 }
}

Deploy this change. Your app now reuses connections instead of creating new ones for every request.

Prevent the Configuration Error That Breaks Production

Must set CONN_MAX_AGE = 0. Without this, Django throws ImproperlyConfigured: Pooling doesn't support persistent connections and your app crashes⁴. The pool manages connection lifetimes, making Django’s persistence redundant.

Scale for High-Traffic Production

Replace "pool": True with specific parameters for production loads:

DATABASES = {
 "default": {
 "ENGINE": "django.db.backends.postgresql",
 "NAME": "your_db_name",
 "USER": "your_db_user",
 "PASSWORD": "your_db_password",
 "HOST": "your_db_host",
 "PORT": "5432",
 "CONN_MAX_AGE": 0,
 "OPTIONS": {
 "pool": {
 "min_size": 4, # Keeps connections warm
 "max_size": 16, # Handles traffic spikes
 "timeout": 10, # Fails fast under extreme load
 "max_lifetime": 1800, # 30 minutes maximum connection age
 "max_idle": 300, # Close idle connections after 5 minutes
 },
 },
 }
}

Start with max_size equal to expected concurrent users divided by 10. Scale up if you see timeout errors in logs.

Monitor Your Performance Gains

Enable pool monitoring to track your improvements:

# In settings.py
import logging
logging.getLogger('psycopg.pool').setLevel(logging.INFO)

Watch pool utilization, connection wait times, timeout errors, and response times. Record median and 95th percentile latency before and after the change under comparable load. Use those measurements to size the pool and judge whether pooling helps your application.

Critical Fix for Threading and Celery Applications

Essential for background processing: This isn’t a pooling bug — it’s expected Django behavior that pooling simply makes painful. Any connection opened outside Django’s request-response cycle (for example, in a thread you spawn yourself) stays open until you explicitly close it. Without a pool you might not notice; with one, those un-returned connections exhaust max_size and you start seeing PoolTimeout errors⁵. Add explicit cleanup:

from django.db import connection
from threading import Thread

class DataProcessingThread(Thread):
 def run(self):
 # Your database operations here
 User.objects.filter(active=True).update(last_seen=timezone.now())

 # Critical: returns the connection to the pool
 connection.close()

For code that may touch multiple database aliases, Django’s documented helper django.db.close_old_connections() is the more robust choice — it closes all old or unusable connections across every configured database:

from django.db import close_old_connections

class DataProcessingThread(Thread):
 def run(self):
 try:
 User.objects.filter(active=True).update(last_seen=timezone.now())
 finally:
 close_old_connections()

Without this cleanup, each background thread permanently holds a connection from your pool.

Deployment Scenarios That Require Different Approaches

ASGI applications: On Django 5.1–5.2, Django’s documentation recommends against native pooling with ASGI — use PgBouncer or similar external poolers instead. This changed in Django 6.0, which ships an async-aware AsyncConnectionPool that works correctly under ASGI. I cover how that fits together with the truly-async ORM in How Django’s ORM Went From sync_to_async Threads to Native psycopg3.

Serverless deployments: Connection pools don’t persist across serverless invocations. Skip this optimization for Lambda/Cloud Functions.

Multi-tenant applications: Each tenant database needs its own pool configuration in DATABASES.

When to Evaluate Pooling

Evaluate pooling when connection establishment is a measurable part of request latency, concurrency is growing, or the application is approaching PostgreSQL connection limits. Compare measurements before and after rather than assuming a fixed latency or cost saving.

Django 5.1 Release Notes - Official Django documentation announcing native connection pooling support ↩︎
Django Database Configuration - Complete guide to Django database settings including pooling requirements ↩︎
psycopg Installation Guide - Official psycopg documentation for package installation and pool dependencies ↩︎
Stack Overflow: Django Pooling Configuration Error - Community discussion of the CONN_MAX_AGE requirement ↩︎
Django Ticket #35672 - Closed as invalid: connections opened in threads must be returned manually. See also the Databases → Caveats docs, which recommend django.db.close_old_connections() for connections created outside the request-response cycle. ↩︎

ty: Astral's Take on Python Type Checking

Fri, 09 May 2025 00:00:00 +0000

Anyone who has run mypy on a real codebase knows the workarounds. You enable the daemon, you keep the incremental cache warm, you scope the check to the files you touched, and you still wait a few seconds for the editor to catch up after a rename. In CI it is worse, because the cache is cold and the full run can stretch into the minutes. None of this is broken, exactly. It is just the cost you learn to pay. So when a new checker says the wait can mostly go away, I pay attention, but I also want to know what it costs.

That checker is ty (gh:astral-sh/ty), from Astral, the same people who built the Ruff linter and the uv package manager. As of May 2025, it is pre-alpha, version 0.0.0a6, and not something you should put in production. But it is already worth talking about, partly for what it does and partly for what it deliberately leaves out.

Speed Is The Headline

The numbers people are reporting are large. One user saw mypy take 18 seconds where ty finished the same check in about half a second. Another compared ty at 2.5 seconds against Pyright at 13.6 seconds on a 100k line codebase. Some users assumed it had failed, because nothing that finishes that fast could have actually looked at their whole project.

Ruff did the same thing to linting a few years ago. It was fast enough that the linter stopped being a separate step you ran and became something that just happened while you wrote code. ty looks like it wants to do that for type checking. That matters more than it sounds. A check that takes a minute is a thing you run in CI and forget about. A check that runs in milliseconds is a thing your editor can run on every save, and that changes how it feels to write Python at all.

Fast And Frequently Wrong, For Now

Speed is the easy part. Being correct is the hard part, and here ty is still young.

The Astral developers say this plainly: it is pre-alpha, many of the errors it reports may be wrong, and the feature set is small. Right now it does diagnostics and go-to-type-definition, and not much else. One user ran it on a codebase where Pyright reported 10 diagnostics, all correct, and ty reported 1,599. That is not a small gap. Type inference is the thing that takes years to get right, and ty has not had years.

I would not read those 1,599 diagnostics as a verdict on the project. A count like that is rarely 1,599 distinct bugs; it is usually a handful of inference patterns the checker gets wrong, multiplied across every file that hits them. Fix the pattern and the count collapses. What you are looking at is a checker that is fast first and accurate later. Given what Astral did with Ruff and uv, betting against the accuracy catching up seems unwise. But it has not caught up yet, and you should treat the output accordingly.

It Is Entering A Crowded Field

ty is not arriving to an empty room. It joins mypy, Microsoft’s Pyright and Pylance, and Facebook’s Pyrefly, which also builds on Ruff’s parser despite being a separate project.

What makes all of these hard is Python itself. TypeScript was built with static typing in mind. Python’s type hints arrived later and grew unevenly, bolted onto a dynamic language, with the inconsistencies you would expect from something added after the fact. On top of that, the libraries people actually use are the hardest cases. Django and SQLAlchemy lean heavily on metaprogramming and runtime code generation, which is exactly the kind of thing a static checker cannot see. The ecosystem mostly papered over this with type stubs and plugins: SQLAlchemy 2.0 added real typed mappings, and Django users lean on django-stubs, which is a mypy plugin. Hold onto that detail, because it runs straight into the next decision.

No Plugins, On Purpose

This is where Astral makes a real choice rather than a faster one. mypy lets libraries ship plugins so the checker can understand their metaprogramming. ty will not have plugins. Astral treats the interchangeability of type checking as a feature: a check should mean the same thing across tools and projects, and it should not depend on a plugin that one checker has and another does not. Instead they plan to support the popular libraries directly in the tool.

That is a trade, not a free win. The Django user relying on django-stubs today is relying on exactly the plugin mechanism ty is choosing not to have, so until Astral supports those libraries directly, that user has no escape hatch. More work falls on Astral, and the libraries they have not reached yet are simply not understood. But it also means you do not end up with type checking that only works inside one vendor’s setup, and that division is worth defending.

They are also borrowing from Rust’s compiler for their diagnostics, aiming for error messages that explain rather than just flag. An LSP server and a VS Code plugin are planned, though there is no release date for either.

The Question That Always Comes Back

Astral is a VC-backed company, and the same question hangs over ty as over Ruff and uv: how does this get paid for. The code is open source and has outside contributors, but at some point the money has to come from somewhere.

People guess at CI products, private repositories, or enterprise services. Astral, for now, seems to be building the tools first and leaving monetization for later. That has earned them a lot of goodwill in the Python community, and it should also keep you a little cautious, because the terms you adopt a tool under are not always the terms you keep it under.

Trying It

If you want to look at it yourself:

uv tool install ty

Or without installing anything:

uvx ty check

These notes describe the pre-alpha release in May 2025. Expect rough edges, and do not trust a red diagnostic until you have checked it by hand.

I do not know yet whether ty becomes the type checker people reach for. The speed is real, the missing plugin system is a deliberate stance and not an oversight, and the accuracy is not there yet. What I want from it is the thing Ruff already delivered: a tool fast enough to disappear into the edit loop, honest enough to trust, and available under open source terms I can rely on. The first of those is here. The other two are still being written.