crmarsh.com
Building Astral: Ruff, uv, and other high-performance Python tools, written in Rust.
248 posts
7,365 followers
315 following
Regular Contributor
Active Commenter
comment in response to
post
Amazing!
comment in response to
post
Thanks Adam!
comment in response to
post
...plus Brent Westbrook and Dhruv Manilawala :)
comment in response to
post
And second: thank you (and congratulations) to the folks on the Astral team that made this release possible: @alexwaygood.bsky.social, @burntsushi.net, @carljm.me, @dcreager.net, @gankra.bsky.social, @ibraheem.ca, @michareiser.bsky.social, @sharkdp.bsky.social, @zanieb.bsky.social...
comment in response to
post
Like Ruff and uv, we're building this project in the open alongside a community of contributors -- over a thousand PRs in total across 30+ authors.
So first: thank you to everyone that's contributed to ty over the past few months!
comment in response to
post
From here, we'll be implementing the rest of the typing spec, and iterating closely with users as we push towards a production-ready release.
If you're interested in helping us get there, give it a try :)
comment in response to
post
Over the past few months, we've focused on:
1. Defining the core architecture (highly incremental, to power a language server -- built on the same underlying engine as rust-analyzer).
2. Implementing a bunch of type system features (e.g., generics, overloads, protocols).
comment in response to
post
Alongside the preview release, we're also shipping an official VS Code extension.
And you can use `ty server` directly in any editor that supports the Language Server Protocol (Neovim, etc.).
comment in response to
post
Like Ruff and uv, ty is open-source and MIT-licensed, so you can use the same tool on the command line, in CI, in any editor, across your team, etc.
comment in response to
post
Instead, this release is about giving users a _preview_ of what to expect from ty, and a call to follow along as we work towards a stable release later this year.
comment in response to
post
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.
comment in response to
post
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.
comment in response to
post
Hahah thank you 🙇♂️
comment in response to
post
\ht to @simonwillison.net who reminded me of this
comment in response to
post
github.com/astral-sh/py...
comment in response to
post
Yeah it should be, but you may need to reinstall Python with uv?
comment in response to
post
Thank you!
comment in response to
post
For now, we're working towards an initial alpha release. When it's ready, I'll make sure you know :)
comment in response to
post
Warning: this project is _not_ ready for real-world user testing, and certainly not for production use (yet). The core architecture is there, but we're still lacking support for some critical features.
Right now, I'd only recommend trying it out if you're looking to contribute.
comment in response to
post
We haven't publicized it to-date, but all of this work has been happening in the open, in the Ruff repository.
All driven by a uniquely great team: Carl Meyer, @alexwaygood.bsky.social, @sharkdp.bsky.social, @michareiser.bsky.social, Dhruv Manilawala, @ibraheem.ca, and @dcreager.net.
comment in response to
post
Another goal: minimizing false positives, especially on untyped code, to make it easier for projects to adopt a type checker and expand coverage gradually over time, without being swamped in bogus type errors from the start.
comment in response to
post
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.)
comment in response to
post
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).
comment in response to
post
Once selected, Quick Fix actions will allow you to install missing packages into your environment with uv.
comment in response to
post
You can now choose uv when setting the Python interpreter for your project, which will then invoke uv to create the virtual environment.
comment in response to
post
iTerm2 with Starship
comment in response to
post
That's the hope!
comment in response to
post
But, yeah, a lot of this is just profiling to identify bottlenecks or expensive routines, then fixing them.
Another example: flattening a nested hashmap.
github.com/astral-sh/uv...
comment in response to
post
I guess one special trick is that we accidentally optimized-out our custom allocators in a previous version (lol), and we've now re-enabled them.
This has a huge effect on, e.g., musl builds. (It has a smaller but noticeable effect on my MacBook.)
github.com/astral-sh/uv...
comment in response to
post
No special tricks here, just the result of a lot of good profiling work from @konstin.bsky.social...
E.g., further reducing allocations around version representations.
github.com/astral-sh/uv...
comment in response to
post
It's an alternative to Dependabot