Today, we're announcing our first hosted infrastructure product: pyx, a Python-native package registry.

We think of pyx as an optimized backend for uv: it’s a package registry, but it also solves problems that go beyond the scope of a traditional "package registry". pyx is now live with our early partners, including Ramp, Intercom, and fal.

As we work towards GA, we're looking for more early users to help shape the future of Python infrastructure.

Get in touch today 👇👇👇

astral.sh/pyx

We’re building a new static type checker for Python, from scratch, in Rust.

From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep! Like Ruff and uv, there will be a significant focus on performance.

The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change).

python-build-standalone has exploded in popularity, with over 70M downloads all-time.

But what is a "standalone" Python build?

It wasn't obvious to me at first! Initially, I didn't understand what problem was being solved or why it mattered... First, some context on the problem.

Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary.

Today, we're shipping a series of features that move uv beyond a pip alternative, and into an end-to-end solution for managing Python projects, command-line tools, single-file scripts, and even Python itself.

A single, unified tool. Like Cargo, for Python.

It's very fast. astral.sh/blog/uv-unifie…

Announcing uv: an extremely fast Python package installer and resolver, written in Rust.

uv is designed as a drop-in alternative to pip, pip-tools, and virtualenv.

With a warm cache, uv installs are near-instant. Here, it's > 75x faster than pip and pip-tools. astral.sh/blog/uv

A collection of (sometimes contradictory) beliefs I've developed on building fast software... Sometimes, performance just doesn't matter. If I make some codepath in Ruff 10x faster, but no one ever hits it, I'm sure it could get some likes on Twitter, but the impact on users would be meaningless.

There's an extremely interesting conversation going on in Python right now around the future of performance.

It's centered on @colesbury's PEP 703, which makes the GIL optional (to be removed entirely in the future), but comes at a cost.

Here's my summary... For context: The CPython interpreter isn't thread-safe, so the global interpreter lock ("GIL") exists to ensure that only one thread is actually executing code at a time.

PEP 703 includes changes to (1) make the interpreter thread-safe and (2) make the GIL optional.

My worst Rust opinion is that I was happier when I didn't use macros.

They can make code harder to read, understand, and change ("magic", "spooky action at a distance", etc.).

If the alternative to a macro is boilerplate... I will sometimes take the boilerplate. This is also kind of a tooling problem. Macro support has definitely improved, but it's still hit or miss, and a lot of little things add up, e.g., automated refactors aren't reflected in macro_rules! bodies.

Python tooling could be much, much faster.

To prove it, I'm releasing ruff, an extremely fast Python linter, written in Rust.

ruff is 10-100x faster than existing solutions. It lints the entire CPython codebase in < 500ms.

Try it! (`pip install ruff`)

github.com/charliermarsh/… I'm inspired by the JavaScript ecosystem, where esbuild, bun, and others have ushered in a new era of performance-focused tooling and set an entirely different bar for how tools should feel.

notes.crmarsh.com/python-tooling…