Remix clone Hacker News

You can use uv to pin, download, and use a specific version of a Python interpreter on a per project basis. You shouldn't use your OS provided Python interpreter for long running projects for all the reasons you mentioned, including reproducibility. If you insist on using the vendor provided interpreter, then use RHEL (or a free clone) or any other long suppported Linux distro (there are many). Five years is a very long time in technology. It is not reasonable to expect more from core maintainers IMO. Especially considering we have better options.

▲

pansa2 8 days ago | parent [-]

> Five years is a very long time in technology.

But it's not a long time in the OP's field of science. Unfortunately despite a strong preference for Python in the scientific community, the language's design team seem to ignore that community's needs entirely, in favour of the needs of large technology companies.

I was hopeful that in the transition from a BDFL-based governance system to a Steering Council, we would see a larger variety of experience and opinions designing the language. Instead, I don't think there has ever been a single scientist, finance worker etc on the Steering Council - it's always software developers, almost always employees of large software companies.

▲

epistasis 4 days ago | parent [-]

Thanks for understanding. I think the responses other than yours here are making me reconsider how invested my research group is in Python. I think we will be doing far more Rust and R components in the future to explore the nature of language stability and package stability.

Just this week I had difficulty integrating the work of a team member because they used some new typing features only available in Python 3.13, but we have many library dependencies on numpy < 2, and in their great wisdom somebody decided that with Python 3.13 there would be no more precompiled wheels of numpy < 2. Meaning arduous multiple-minute compilation for any new venv or Docker build, even with uv. This sort of pointless version churn, wasting many valuable research hours on investigating the chains of dependencies and which libraries are ready or not, to serve the whims of some software engineer that decides everyone must update working code to novel APIs, is not something that I experience in other languages.

Hopefully Python Steering Council members reconsider the motivation of continual churn, but it's much harder to get promoted and get acknowledgement for judicious tending of a language than it is to ship a bunch of new features. Combined with fear over Anaconda charges, Python is quickly becoming a very unfriendly place for science, or anybody else that values function over form.

	▲	pansa2 21 hours ago \| parent [-]
		> somebody decided that with Python 3.13 there would be no more precompiled wheels of numpy < 2 Wow. NumPy 2.0 was released less than a year ago and they're already starting to drop support for 1.x?! It only supports Python versions up to 3.12, all of which are themselves either unsupported or in "security fixes only" mode. The developers plan to end-of-life 1.x entirely in less than six months time. Do they not know their target audience at all? > it's much harder to get promoted and get acknowledgement for judicious tending of a language than it is to ship a bunch of new features Yes - as Mark Lutz (author of "Learning Python") puts it [0]: "[Python's] evolution is largely driven by narcissism, not user feedback" and "Python remains a constantly morphing sandbox of ideas, which is great if you just want to play in the sandbox, but lousy if you're trying to engineer reliable and durable software". [0] https://learning-python.com/python-changes-2014-plus.html#se...