about rust though
some say a nicer language helps finding the right architecture (heard that about cpp veteran dropping it for ocaml, any attempted idea would take weeks in cpp, was a few days in ocaml, they could explore more)
also the parallelism might be a benefit the language orientation
enough semi fanboyism
> Plenty of tools are written in Rust without being notably fast.
This also hasn't been my experience. Most tools written in Rust are notably fast.
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).
> a 3600-entry mapping of string names to emoji
Which can easily be zero-cost in Rust.
> It literally doesn't know how to access its own package download cache without hitting the network
This is the only example you've given that actually fits with your thesis.
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.
I actually rewrote a non-trivial Python program in Rust once because it was so slow (among other reasons), and got a 50x speedup. It was mostly just running regexes over logs too, which is the sort of thing Python people say is an ideal case (because it's mostly IO or implemented in C).
Unless I've been seeing very different submissions than you, "pet peeve" seems like the exact opposite of what is actually the case?
I feel that sometimes there's a desire on the part of those who use tool X that everyone should use tool X. For some types of technology (car seat belts, antibiotics...) that might be reasonable but otherwise it seems more like a desire for validation of the advocate's own choice.
Poetry and uv avoid this issue.
Edit: to add to what my understanding of pipenv is, the "standard/approved" method of package management by the python community, but in practice is it not? Is it now uv?
lol
This entire AI generated article with lots of text just to just say the obvious.