> Not many projects use setup.py now anyway and pip is still super slow.
Yes, but that's still largely not because of being written in Python. The architecture is really just that bad. Any run of pip that touches the network will end up importing more than 500 modules and a lot of that code will simply not be used.
For example, one of the major dependencies is Rich, which includes things like a 3600-entry mapping of string names to emoji; Rich in turn depends on Pygments which normally includes a bunch of rules for syntax highlighting in dozens of programming languages (but this year they've finished trimming those parts of the vendored Pygments).
Another thing is that pip's cache is an HTTP cache. It literally doesn't know how to access its own package download cache without hitting the network, and it does that access through wrappers that rely on cachecontrol and Requests.
> That's a property of Python though. The fact that it isn't compiled (and that importing is very slow).
Bytecode compilation is compilation.
There are many things that could be used to improve import speed that I never even see discussed, let alone implemented.
But most importantly, pip doesn't need to have all these modules imported. They already proved they could defer the Requests imports; but the actual network calls aren't that hard to do with the standard library anyway. (As nice as it would be to have Requests in the standard library, but I digress.) Most of the stuff it imports up-front from Rich will go entirely unused.
> Which can easily be zero-cost in Rust.
Which is irrelevant to the point.
> This is the only example you've given that actually fits with your thesis.
No. My thesis is that pip doesn't have to be the way it is in order to actually solve the problem of installing Python packages. Everything I mentioned is an example of a thing pip doesn't have to do in order to install packages, and slows it down unnecessarily.
Sorry, the fact that typical Rust programming style is much faster than typical Python style is irrelevant to the fact that a Rust tool is faster than its Python competitor? Riiight.
> My thesis is that pip doesn't have to be the way it is in order to actually solve the problem of installing Python packages.
Ok but the actual debate was about whether `uv` is faster because it is written in Rust. The answer is yes because when you put a normal amount of effort into writing Python or Rust you run into all these problems in Python that you don't run into in Rust.
Sure you can defer imports, but that's a pretty uncommon thing to do in Python.
It's like, you wouldn't say "bicycles are just as fast as cars; as long as you attach a jet engine to the bicycle!". Yes, technically possible, but nobody does that.
Yes, but that's still largely not because of being written in Python. The architecture is really just that bad. Any run of pip that touches the network will end up importing more than 500 modules and a lot of that code will simply not be used.
For example, one of the major dependencies is Rich, which includes things like a 3600-entry mapping of string names to emoji; Rich in turn depends on Pygments which normally includes a bunch of rules for syntax highlighting in dozens of programming languages (but this year they've finished trimming those parts of the vendored Pygments).
Another thing is that pip's cache is an HTTP cache. It literally doesn't know how to access its own package download cache without hitting the network, and it does that access through wrappers that rely on cachecontrol and Requests.