Charlie Marsh
Building Astral: Ruff, uv, and other high-performance Python tools, written in Rust.
- Reposted by Charlie MarshA basic @fastapi.tiangolo.com app, just one command away. 🎁 First FastAPI thing from @savannah.dev ! 🙌 Also, @crmarsh.com 's uv is awesome, use it. 😎
- 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".
- The uv build backend is now stable, and considered ready for production use. An alternative to setuptools, hatchling, etc. for pure Python projects, with a focus on good defaults, user-friendly error messages, and performance. When used with uv, it's 10-35x faster.
- Try it out by setting your project's build system, or running `uv init --build-backend uv`: ```toml [build-system] requires = ["uv_build>=0.7.19,<0.8.0"] build-backend = "uv_build" ``` (In a future release, we'll make this the default.)
- One underrated implication here: we can now build and publish your package without running or even installing Python. In pure Rust, we can build your Python package, install it, publish it to a registry, etc.
- Today, we’re announcing the preview release of ty, an extremely fast type checker and language server for Python, written in Rust. In early testing, it's 10x, 50x, even 100x faster than existing type checkers. (We've seen >600x speed-ups over Mypy in some real-world projects.)
- Our goal with ty is to build the best static analysis toolchain for Python -- to push the boundaries of how helpful a type checker can be in a highly dynamic ecosystem. And we want it to be capable of scaling to tens or even hundreds of millions of lines of code.
- With the preview release, we don't expect ty to be usable in production. It's feature-incomplete, and you should expect to encounter bugs or even fatal errors.
-
View full thread...plus Brent Westbrook and Dhruv Manilawala :)
- Reposted by Charlie Marshzlib-rs is now used in uv! uv is the extremely fast Python package & project manager with over 200M requests/day. Not only are we happy about the adoption but also grateful for Astral and @crmarsh.com stepping up and supporting us through a GitHub sponsorship. Thanks!
- Reposted by Charlie MarshIn the latest version of uv, we've updated the build system for our managed Python versions to use the latest LLVM version and cherry-picked an extra fix for a performance bug (github.com/llvm/llvm-pr...) and the early benchmarks are pretty exciting! On M3 macOS
- uv is one year old today. Hard to believe its only been a year. The growth, adoption, and impact surpassed my wildest expectations. Happy birthday, uv! 🥳
- \ht to @simonwillison.net who reminded me of this
- Reposted by Charlie MarshPython 3.14.0a5 is out today in uv 0.5.31 and includes a new tail calling interpreter which, from some quick benchmarks, looks like a 1.23x performance improvement !
- Reposted by Charlie MarshHow to create a Python CLI that's globally available in your system in 5 easy steps. 1. Install uv 2. Init project with `uv init --app --package mycli` 3. Write code 4. Install with `uv tool install . -e` 5. Use `mycli` anywhere in your computer
- Reposted by Charlie Marsh🐍🎧 Charlie Marsh: Accelerating Python Tooling With Ruff and uv How is the Rust programming language being used to speed up Python tools? This week on the show, we speak with @crmarsh.com about his company, Astral, and their tools, uv and Ruff. realpython.com/podcasts/rpp/238/
- Reposted by Charlie MarshI want to thank @crmarsh.com for coming on the show this week. What a great conversation! We dug in to Ruff, uv, Astral, and a new typing tool being developed. Thanks again! realpython.com/podcasts/rpp...
- 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).
- Performance is just one of many goals, though. For example: we're investing heavily in strong theoretical foundations and a consistent model of Python's typing semantics. (We're lucky to have Carl Meyer and @alexwaygood.bsky.social on the team for many reasons, this is one of them.)
-
View full threadFor now, we're working towards an initial alpha release. When it's ready, I'll make sure you know :)
