Live data from Hacker News

Warn about PyPy being unmaintained

github.com

131–140 of 181 posts

Re: Warn about PyPy being unmaintained

#131
post #101

Earlier quoted context omitted.

More specifically, the Scientific Python community through SPEC 0[0] recommends that support for Python versions is dropped three years after their release. Python 3.12 was released in October 2023[1], so that community is going to drop support for it in October 2026. Considering that PyPy is only just now starting to seriously work on supporting 3.12, there's a pretty high chance that it won't even be ready for use…

They appear to be talking about CPython implementations, taking into account when those versions continue to be sorted (in the sense of security updates). That's irrelevant for PyPy, which clearly supports version numbers on a different schedule.

It's not irrelevant, because if SPEC 0 says that a particular Python version is no longer supported, then libraries that follow it won't avoid language or standard library features that that version doesn't have. And then those libraries won't work in the corresponding PyPy version. If there isn't a newer PyPy version to upgrade to, then they won't work in PyPy at all.

Re: Warn about PyPy being unmaintained

#132
post #118
post #26

PyPy is a fantastic achievement and deserves far more support than it gets. Microsoft’s “Faster CPython” team tried to make Python 5x faster but only achieved ~1.5x in four years - meanwhile PyPy has been running at over 5x faster for decades. On the other hand, I always got the impression that the main goal of PyPy is to be a research project (on meta-tracing, STM etc) rather than a replacement for CPython in produc…

> PyPy is a fantastic achievement and deserves far more support than it gets PyPy is a toy for getting great numbers in benchmarks and demos, is incompatible in a zillion critical ways, and is basically useless for large-scale development for anything that has to interoperate with "real" Python. Literally everyone who's ever tried it has the experience that you mock up a trial for your performance code, drop your jaw…

"Ask HN: Is anyone using PyPy for real work?" from 2023 contradicts you about PyPy being a toy. The replies are noticeably biased towards batch jobs (data analysis, ETL, CI), where GC and any other issues affecting long-running processes are less likely to bite, but a few replies talk about sped-up servers as well.

https://news.ycombinator.com/item?id=36940871 (573 points, 181 comments)

Re: Warn about PyPy being unmaintained

#133
Money is a forcing function for development. Why is there still no way to donate to all devs in the dependency tree? Should we just anticipate expensive problems just like this when the rot finally makes it uncomfortable to continue development?

Re: Warn about PyPy being unmaintained

#134
post #118
post #26

PyPy is a fantastic achievement and deserves far more support than it gets. Microsoft’s “Faster CPython” team tried to make Python 5x faster but only achieved ~1.5x in four years - meanwhile PyPy has been running at over 5x faster for decades. On the other hand, I always got the impression that the main goal of PyPy is to be a research project (on meta-tracing, STM etc) rather than a replacement for CPython in produc…

> PyPy is a fantastic achievement and deserves far more support than it gets PyPy is a toy for getting great numbers in benchmarks and demos, is incompatible in a zillion critical ways, and is basically useless for large-scale development for anything that has to interoperate with "real" Python. Literally everyone who's ever tried it has the experience that you mock up a trial for your performance code, drop your jaw…

Timely management of external resources is what the `with` statement has been for since 2006, added in python 2.5 or so. To debug these problems Python has Resource Warnings.

Additionally, CPython's gc is also only eager in a best effort kind of way. If cycles are involved it can take long to release memory. This will become even more the case in future versions of CPython, in the free threading variants.

Re: Warn about PyPy being unmaintained

#135

Earlier quoted context omitted.

They appear to be talking about CPython implementations, taking into account when those versions continue to be sorted (in the sense of security updates). That's irrelevant for PyPy, which clearly supports version numbers on a different schedule.

It's not irrelevant, because if SPEC 0 says that a particular Python version is no longer supported, then libraries that follow it won't avoid language or standard library features that that version doesn't have. And then those libraries won't work in the corresponding PyPy version. If there isn't a newer PyPy version to upgrade to, then they won't work in PyPy at all.

You might make a different decision if you were targeting PyPy.

Re: Warn about PyPy being unmaintained

#136
post #47

Earlier quoted context omitted.

The short summary of it being that these people are beyond terrible at giving names to things.

Programmers and engineers should never be allowed to name things. I say that as a programmer and engineer.

On one side I agree. On other side I look how marketing people name things and I think we're still better off

Imagine if next edition of GCC, released in 2026 was named 2027. Then it was GCC One. Then GCC 720. Then GCC XE. Then just plain GCC. Then GCC Teams

Re: Warn about PyPy being unmaintained

#137
post #101

Earlier quoted context omitted.

I think the most significant boundary is given by the question: "is there a plan to support new minor versions of Python?" It sounds like there is not. There may be non-zero maintenance work happening, but a project that only maintains support for old versions and will never adopt new ones is functionally one that the ecosystem will eventually forget about. Maybe you call that "under active development" but my respon…

More specifically, the Scientific Python community through SPEC 0[0] recommends that support for Python versions is dropped three years after their release. Python 3.12 was released in October 2023[1], so that community is going to drop support for it in October 2026. Considering that PyPy is only just now starting to seriously work on supporting 3.12, there's a pretty high chance that it won't even be ready for use…

What's the point of a three year window? It seems like a weird middle-point. Either you are in a position to choose/install your own interpreter and libraries or you are not.

If you can choose your own versions and care at all about new releases, you can track latest and greatest with at the very most a few months of lag. Six months of "support" is luxurious in this scenario.

If you can't choose your own versions, you are most likely stuck on some sort of LTS Linux and will need to make do with what they provide. In that case three years is a cruel joke, because almost everything will be more than three years old when it is first deployed in your environment.

Re: Warn about PyPy being unmaintained

#138
post #101

Earlier quoted context omitted.

More specifically, the Scientific Python community through SPEC 0[0] recommends that support for Python versions is dropped three years after their release. Python 3.12 was released in October 2023[1], so that community is going to drop support for it in October 2026. Considering that PyPy is only just now starting to seriously work on supporting 3.12, there's a pretty high chance that it won't even be ready for use…

This is silly, there's no killer feature for scientific computing being added to python that would make an existing pypy codebase drop that dependency, getting a code validated takes a long time and dropping something like pypy will require re-valditating the entire thing.

The phenomena you're describing is why Cobol programmers still exist, and simultaneously, why it's increasingly irrelevant to most programmers

The killer feature is ecosystem: Easily and reliably reusing other libraries and tools that work out-of-the-box with other Python code written in the last few years . There are individually neato features motivating the efforts involved in upgrading a widely-used language & engine as well, but that kind of thinking misses the forest for the trees unfortunately.

It's a bit surprising to me, in the age of AI coding, for this to be a problem. Most features seem friendly to bootstrapping with automation (ex: f-strings that support ' not just "), and it's interesting if any don't fall in that camp. The main discussion seems to still be framed by the 2024 comments, before Claude Code etc became widespread: https://github.com/orgs/pypy/discussions/5145 .

Re: Warn about PyPy being unmaintained

#139
post #130
post #125

Earlier quoted context omitted.

Is your argument here that you shouldn't accept the free trial because you might find it useful and then be trapped into paying for more of it later?

No, my argument is that your “but neither of them have explicitly said that there won't be options to renew for another six months” point is not something anyone should realistically be counting on, and is not a valid counter argument to your parent post of “Isn't the Claude one only for a few months?”. We should be discussing what is factual now , not be making up scenarios which could maybe happen but have zero ind…

I didn't say that I thought they would likely extend it, but I stand by my statement that it's a possibility.

Neither company have expressed that the six month thing is a hard limit.

The fact that OpenAI shipped their version within two weeks of Anthropic's announcement suggests to me that they're competing with each other for credibility with the open source community.

(Obviously if you make decisions based on the assumption that the program will be expanded later you're not acting rationally.)

Re: Warn about PyPy being unmaintained

#140
post #118

Earlier quoted context omitted.

> PyPy is a fantastic achievement and deserves far more support than it gets PyPy is a toy for getting great numbers in benchmarks and demos, is incompatible in a zillion critical ways, and is basically useless for large-scale development for anything that has to interoperate with "real" Python. Literally everyone who's ever tried it has the experience that you mock up a trial for your performance code, drop your jaw…

Timely management of external resources is what the `with` statement has been for since 2006, added in python 2.5 or so. To debug these problems Python has Resource Warnings. Additionally, CPython's gc is also only eager in a best effort kind of way. If cycles are involved it can take long to release memory. This will become even more the case in future versions of CPython, in the free threading variants.

Sorry, the with statement is non-responsive. The question isn't whether you "can" write PyPy-friendly code. Obviously you can.

The question isn't even whether or not you "should" write PyPy-friendly code, it's whether YOU DID, or your predecessors did. And the answer is "No, they didn't". I mean, duh, as it were.

PyPy isn't compatible. In this way and a thousand tiny others. It's not really "Python" in a measurable and important way. And projects that are making new decisions for what to pick as an implementation language for the evolution of their Python code have, let's be blunt, much better options than PyPy anyway.

Post reply on HN