[Kwpolska]

> Packaging can be irritating although uv takes the sting out a bit.

uv proves the OP’s point. Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv, and why is the Python package manager uv written in Rust and not Python?

[necovek]

For the same reason GP posted and half the stdlib is written in C: Python is a language that is almost always good enough, but never really the best (and especially when it comes to performance of complex algorithms).

[CamouflagedKiwi]

Because uv itself can fetch a Python distribution. If it's written in Python, it's quite a bit harder to distribute, assuming one of their goals is not to require an existing Python install.

[zahlman]

> Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv

Incredibly large backward-compatibility burdens [0], internal politics [1] and general institutional dysfunction (no footnote; if you're familiar then you need no explanation, and if you aren't then the less said the better). Nothing to do with Python as a language. Most of the important pieces to get uv-like performance are algorithmic choices, and most of the rest are available as built-in C code in the reference implementation [2].

(Edit: wait, I recognize your username. You should definitely know these sorts of things.)

> why is the Python package manager uv written in Rust and not Python?

Because that's the language that Astral devs like, and because installing Python itself is considered in scope for uv so there would be an intractable bootstrapping issue.

[0]: In particular, the entire model of `setup.py` defining metadata is certifiably insane, especially when you consider the projects that expect to feed that code to Setuptools at build time in order to figure out what version of Setuptools is needed at build time. But this legacy approach is seen as something that absolutely must be guaranteed to work for well beyond even now; even attempts to remove long-deprecated, minor aspects of that functionality end up breaking major projects, including ones that didn't even require a build step in the first place [3].

[1]: Most obviously, GvR not wanting to have anything to do with it when initially approached by the SciPy people in IIRC 2011, leading to the creation of Conda). But a lot of other things, too. The backwards-compatibility issues synergize with this; consider for example the architectural dumpster fire of Setuptools, and the timeline of distutils removal from the standard library.

[2]: See e.g. my analysis in https://zahlman.github.io/posts/oxidation/ .

[3]: See e.g. my LWN article https://lwn.net/Articles/1020576/ .

[moron4hire]

Any claims that Python has a huge backwards compat mission go right out the window when you consider Python 3. 3 was a perfect chance to fix all of the major problems with Python, problems other languages have solved so there isn't even a need to invent things from scratch. They didn't and that's why the community is still split on adoption.

[Yossarrian22]

I don’t think there is still a Python 2 split, the lack of security updates being a concern

[zahlman]

I have no idea what you're talking about. 3.x objectively did fix the major problems and was not particularly inventive in its approach. The fact that they didn't fix more things all at once — and the fact that they still received massive complaints about supposedly fixing too much — is the origin of that backwards compatibility mission. Actually talking to the devs for any significant length of time makes it clear how much lasting trauma was caused by the change, and how much that cemented pro-backwards-compatibility views. And the community has not been remotely "split on adoption" for years; hardly anyone publishes packages advertised as 2.x compatible any more (e.g. urllib3 gave up almost two years ago). But to the extent that there have been any holdouts at all, it's been people who want ancient systems to work, not people who think that not enough changed to merit upgrading.

[throwaway81523]

Python 3 got very slow update and poor acceptance precisely because it DIDN'T fix major problems, it only tweaked around the edges of minor ones. So people stayed with Python 2 as long as possible. Here's a post from 2014 that I bookmarked and it explains things a decade+ later:

https://news.ycombinator.com/item?id=7802575

From the link: "You know why I'm not running python 3? Because it doesn't solve a single problem I have. It doesn't solve anyone's problems. It solves imaginary problems, while creating real problems."