3 ms·

It doesn't feel too surprising to me. The core developer tooling for Python was (/is) about on par with some of the other top languages (C, C++, Java), but lack

It doesn't feel too surprising to me. The core developer tooling for Python was (/is) about on par with some of the other top languages (C, C++, Java), but lacking when compared to some of the others (Rust, Go, JS/TS). There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. So it feels like there wasn't any magic, trickery or "take over", but they just filled a void. Control over uv and ruff (and now also python-build-standalone) doesn't really give Astral significant leverage over Python as a language. They are also quite involved in standardizing many parts of uv via PEPs, which I'm sure the PSF could shoot down if they were overly favoring uv's goals. Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence). I think that makes it very hard to compare to e.g. when Yarn entered the Node.js package manager scene. It also doesn't feel too surprising that there is little resistance against commercial involvement. Commercially-led programming languages were quite the norm in the past and also seem to be having a comeback (or trying to). In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not.

zahlman 2y ago
>There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. In my book, this happened partly because of disagreement over what tasks the tooling actually needs to do (and because users' needs differ wildly), and a bit because of slow discussions around standards and development of those standards - but mostly because of a poor foundation. It's not that Uv's installer is doing amazing things; it's more that Pip is just badly designed. The internals aren't well factored; it vendors a whole bunch of stuff; it can't offer a usable UI for its own download cache; it doesn't offer an API (and explicitly counsels people to run it in a subprocess); it's designed around the assumption that it will get copied into every virtual environment (even though you don't have to do that any more - except that people don't know this, and it could break if your programs are doing that subprocess trick, unless they declared Pip as a dependency explicitly because who does that?)... the list goes on and on. > Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence) Python has been around much longer than programmers have been talking about "software ecosystems" in the contemporary sense. Pip isn't in the standard library, so that it can be developed and versioned separately. Making the experience smooth (to the extent that it is) requires special-case support in the form of the `ensurepip` bootstrap and `venv` special-casing Pip (for a while, Setuptools got the same treatment). There is an extremely strong insistence in that community on making sure not to break older workflows - as much as people perceive them to get broken all the time anyway. All manner of improvements are held back because we still need to support projects that use `setup.py` exclusively and do so in a variety of legacy ways; and because Python still has to work if you don't set up a "project" at all; and shebangs have to work which has implications for how `sys.path` is initialized, etc. The last time there was a concerted attempt to break everything in order to rebuild it properly, users ended up getting 11 years to adapt to 3.x (9, if you account for 3.0 and 3.1 having serious issues and going back on a decision about how to migrate bytes and unicode literals) and in some cases are still grumbling almost 5 more years past the nominal deadline. >In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not. The developers who have been around the longest seem to have more of that background. The best-known names among the relative newcomers all seem to be people working at large tech companies.

zahlman 2y ago

>There have also been previous attempts (Pipenv/Poetry) that did prove demand but fell flat in some regards. In my book, this happened partly because of disagreement over what tasks the tooling actually needs to do (and because users' needs differ wildly), and a bit because of slow discussions around standards and development of those standards - but mostly because of a poor foundation. It's not that Uv's installer is doing amazing things; it's more that Pip is just badly designed. The internals aren't well factored; it vendors a whole bunch of stuff; it can't offer a usable UI for its own download cache; it doesn't offer an API (and explicitly counsels people to run it in a subprocess); it's designed around the assumption that it will get copied into every virtual environment (even though you don't have to do that any more - except that people don't know this, and it could break if your programs are doing that subprocess trick, unless they declared Pip as a dependency explicitly because who does that?)... the list goes on and on. > Compared to other languages Python leadership also always made the impression to me that they'd rather focus on the language itself and have a looser grip on the ecosystem surrounding it even if that comes with a more fragmented ecosystem (which has already been the status quo for most of Python's existence) Python has been around much longer than programmers have been talking about "software ecosystems" in the contemporary sense. Pip isn't in the standard library, so that it can be developed and versioned separately. Making the experience smooth (to the extent that it is) requires special-case support in the form of the `ensurepip` bootstrap and `venv` special-casing Pip (for a while, Setuptools got the same treatment). There is an extremely strong insistence in that community on making sure not to break older workflows - as much as people perceive them to get broken all the time anyway. All manner of improvements are held back because we still need to support projects that use `setup.py` exclusively and do so in a variety of legacy ways; and because Python still has to work if you don't set up a "project" at all; and shebangs have to work which has implications for how `sys.path` is initialized, etc. The last time there was a concerted attempt to break everything in order to rebuild it properly, users ended up getting 11 years to adapt to 3.x (9, if you account for 3.0 and 3.1 having serious issues and going back on a decision about how to migrate bytes and unicode literals) and in some cases are still grumbling almost 5 more years past the nominal deadline. >In some languages where your median developer has more years of experience and they likely grew up with languages which are more "grassroots" the resistance would be higher. And while I would assume that the people at the PSF also fit that profile, in a high-influx language such as Python, the majority of the Python developers do not. The developers who have been around the longest seem to have more of that background. The best-known names among the relative newcomers all seem to be people working at large tech companies.