If your purpose is to denigrate Python as a language, then uv isn't solving problems for you anyway. But I will say that the kind of evangelism you're doing here is counterproductive, and is the exact sort of thing I'd point to when trying to explain why the project of integrating Rust code into the Linux kernel has been so tumultuous.
One immediate speed-up that requires no code changes: when uv creates a venv, it doesn't have to install Pip in that venv. You can trivially pass `--without-pip` to the standard library venv to do this manually. On my system:
$ time uv venv uv-test
Using CPython 3.12.3 interpreter at: /usr/bin/python
Creating virtual environment at: uv-test
Activate with: source uv-test/bin/activate
real 0m0.106s
user 0m0.046s
sys 0m0.021s
$ time python -m venv --without-pip venv-test
real 0m0.053s
user 0m0.044s
sys 0m0.009s
$ time python -m venv venv-test
real 0m3.308s
user 0m3.031s
sys 0m0.234s
To install in this environment, I use a globally installed pip (actually the one vendored by pipx), simply passing the `--python` argument to tell it which venv to install into. I have a few simple wrappers around this; see https://zahlman.github.io/posts/2025/01/07/python-packaging-... for details.
In my own project, Paper, I see the potential for many immediate wins. In particular, Pip's caching strategy is atrocious. It's only intended to avoid the cost of actually hitting the Internet, and basically simulates an Internet connection to its own file-database cache in order to reuse code paths. Every time it installs from this cache, it has to parse some saved HTTP-session artifacts to get the actual wheel file, unpack the wheel into the new environment, generate script wrappers etc. (It also eagerly pre-compiles everything to .pyc files in the install directory, which really isn't necessary a lot of the time.) Whereas it could just take an existing unpacked cache and hard-link everything into the new environment.
Feel like that's super-obvious but yet here we are.
Actix is just one of many web frameworks, minijinja is an implementation of jinja2, by the original author.
(And many of them are completely fake, anyway. You don't actually need to spend an extra 15MB of space, and however many seconds of creation time, on a separate copy of Pip in each venv just so that Pip can install into that venv. You just need the `--python` flag. Which is a hack, but an effective one.)
(Last I checked, the uv compiled binary is something like 35MB. So sticking with a properly maintained Pip cuts down on that. And Pip is horrendously bloated, as Python code goes, especially if you only have the common use cases.)