It seems that PyPy is not being actively developed anymore and is phased out even by numpy (numpy/numpy#30416). There's no official statement from the project, but the numpy issue is from a PyP...
Read the original article
Comments
PyPy core dev here. If anyone is interested in helping out, either financially or with coding, we can be reached various ways. See https://pypy.org/contact.html
The website should have a prominent Donate section, maybe have some tiers of donation like the Ladybird browser does.
I wanted to put a little £ towards the project but couldn't see a place to do it.
I don’t disagree about prominence but to share the links under the about section for people here
By stuaxo 2026-03-0917:19 Thanks, I should add PyPy to the list of projects I send a little to ... PyPy should be better supported by organisations + not need individual contributions, but things are where they are I guess.
By bob_theslob646 2026-03-0823:15 Thanks for sharing this. I just donated. Been using them for many many years.
By eugenekolo 2026-03-0817:17 Donated. Thank you and everyone else on the PyPy team.
I use PyPy regularly on an app of mine, and very often when I need to do some compute heavy load. Typically over 5x faster than CPython. It makes some stuff that takes impossibly long with CPython (nobody wants to wait 5 minutes...), to returning a response in a few seconds.
Another suggestion to add for you all (IDK how helpful.) When I see PyPy I see that its speed is faster for CPU-bound work but I'm thinking there is also I/O bound work that would see significant increases in the load they can handle. You could host a page that benchmarks common tasks like HTTP req/s (different types) with asyncio vs CPython. Could even have an automated tool that allows projects to benchmark performance from a web-page using PyPi without having to install or measure anything.
Benchmarks are tricky. Do you have a specific use case you want sped up?
By forsakenharmony 2026-03-0813:38 I have to say the speed comparison on the front page seems hard to read / backwards
I feel like you should either put absolute numbers side by side or how much faster pypy is (instead of how much time it takes)
By true_religion 2026-03-0918:22 It would also be nice to see benchmarks of how much faster PyPy is getting each version. I know there is a tracking page but it tracks dozens of tests and has no absolute reference summary by version.
An easy chart to show v3.x is 10% faster than the last version would be great.
By rurban 2026-03-116:19 You really need free claude or gpt subscriptions for this maintainance updates. They published OSS support recently. Ask them.
Though they use an inflated star ranking system, which doesn't reflect reality.
By trueismywork 2026-03-0811:461 reply Also big notice that it is unmaintained
By RobotToaster 2026-03-0812:171 reply And that the corporations using their work should donate if they actually want it maintained.
By gzread 2026-03-0813:07 Donating is for individuals. If a corporation wants something done, they can hire or contract someone to do that thing.
By cfbolztereick 2026-03-088:152 reply PyPy isn't unmaintained. We are certainly fixing bugs and are occasionally improving the jit. However, the remaining core devs (me among them) don't have the capacity to keep up with cpython. So for supporting new cpython versions we'll need new people to step up. For 3.12 this has started, we have a new contributor who is pushing this along.
By HaskLwp 2026-03-0816:01 CPython has turned into a commercial enterprise where a small number of developers chase away everyone and periodically get useless projects funded by corporations that go nowhere after five years. Intelligent people have all left.
The 150th rewrite of unicodeobject.c is relatively benign (except that it probably costs RedHat money) but the other things are impossible to keep up with.
The text merged to the documentation is more concise than the PR title:
> not actively developed anymore
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 response is "ok, then I don't care whether it's under active development, I (and 99.9% of other people) should care about whether it's going to support new minor versions."
On the other hand, if you don't support new minor versions day one, but you eventually support them, that's quite different.
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 before becoming obsolete. At that point it doesn't even matter whether you want to call it "in active development", it is simply too far behind to be relevant.
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.
By jcattle 2026-03-097:46 I guess the point of a three year window is to be able as an ecosystem to at some point adopt new language features.
When you have some kind of ecosystem rule for that, you can make these upgrade decisions with a lot more confidence.
For example in my project I have a dependency on zstandard. In 3.14 zstandard was added to the standard library. With this ecosystem wide 3 year support cycle I can in good confidence drop the dependency in three years and use the standard lib from then on.
I feel like it just prevents the ecosystem from going stale because some important core library is still supporting a really old version, thus preventing other smaller libraries from using new language features as well, to not exclude a large user base still on an old version.
By SiempreViernes 2026-03-0813:332 reply 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 .
By cozzyd 2026-03-0818:53 The alternative is when you run a script that you last used a few years ago and now need it again for some reason (very common in research) and you might end up spending way too much time making it work with your now upgraded stack.
Sure you can were you should have pinned dependencies but that's a lot of overhead for a random script...
By SiempreViernes 2026-03-0915:201 reply Most programmers aren't writing scientific software, which you can tell by claims that nicer f-strings is a pressing concern.
By lmeyerov 2026-03-100:28 We can play that game - items like GIL-free interpreters and memory views are pretty relevant to folks on the more demanding side of scientific computing. But my point is this is a head-in-sand game when the community vastly outweighs any individual feature. My experience with the scientific computing community is that the non-pypy portion of it is much bigger.
I'm not a pypy maintainer, so my only horse in this race is believing cpython folks benefit from seeing the pypy community prove Things Can Be Better. Part of that means I rather pypy live on by avoiding unforced errors.
By ajb 2026-03-0823:09 Unfortunately python does add features in a drip-drip kind of way that makes being behind an experience with a lot of niggles. This is particularly the case for the type annotation system, which is retrofit to a language that obviously didn't have one originally. So it's being added slowly in a very conservative way, and there are a lot of limitations and pain points that are gradually being improved (or at least progressed on). The upcoming lazy module loading will also immediately become a sticking point.
By quietbritishjim 2026-03-0814:391 reply 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.
By ameliaquining 2026-03-0814:581 reply 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.
By Wowfunhappy 2026-03-0815:11 You might make a different decision if you were targeting PyPy.
By masklinn 2026-03-0812:43 > 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 is literally a Python 3.12 milestone in the bug tracker.
> my response is "ok, then I don't care whether it's under active development, I (and 99.9% of other people) should care about whether it's going to support new minor versions."
It sounds a lot more like your actual response is "I don't care about pypy".
Which is fine, most people don't to start with. You don't have to pretend just to concern-troll the project.
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 production.
Maybe that, plus the core Python team’s indifference towards non-CPython implementations, is why it doesn’t get the recognition it deserves.
Third party libraries like SciPy scikit-learn, pandas, tensorflow and pytorch have been critical to python’s success. Since CPython is written in C and exposes a nice C API, those libraries can leverage it to quickly move from (slow) python to (fast) C/C++, hitting an optimum between speed of development and speed of runtime.
PyPy’s alternative, CFFI, was not attractive enough for the big players to adopt. And HPy, another alternative that would have played better with Cython and friends came too late in the game, by that time PyPy development had lost momentum.
By mattip 2026-03-089:29 Yes. The C API those libraries use is a good fit to CPython, a bad fit to PyPy. Hence CFFI and HPy. Actually, many if the lessons from HPy are making their way into CPython since their JIT and speedups face the same problems as PyPy. See https://github.com/py-ni
By jjgreen 2026-03-0818:52 I rather like Python and have used the C API extensively, "nice" is not the word I'd choose ...
By glkindlmann 2026-03-0813:251 reply Sorry can you explain more the connection between PyPy and CFFI (which generates compiled extension modules to wrap an existing C library)? I have never used PyPy, but I use CFFI all the time (to wrap C libraries unrelated to Python so that I can use them from Python)
CFFI is fast on PyPy. The JIT still cannot peer into the compiled C/C++ code, but it can generate efficient interface code since there is a dedicated _cffi_backend module built into PyPy. Originally that was the motivation for the PyPy developers to create CFFI.
By glkindlmann 2026-03-0820:42 Thank you for the background info, and sorry for me explaining CFFI (I just wanted to be sure we were talking about the same thing). Being ignorant about PyPy, I honestly had no idea until now that there was a personnel or purpose overlap between CFFI and PyPy. I am very grateful for CFFI (though I only use it API mode).
By pjmlp 2026-03-0818:58 Python was already widely deployed before them, thanks to Zope, and being a saner alternative to Perl.
The Faster Python project would’ve got further if Microsoft hadn’t let the entire team go when they made large numbers of their programming languages teams redundant last year. All in the name of “AI”. Microsoft basically gave up on core computer science to go chase the hype wave.
You’re right, of course: even Guido seems to have been moved off working on CPython and onto some tangentially-related AI technology.
However, Faster CPython was supposed be a 4-year project, delivering a 1.5x speedup each year. AFAIK they had the full 4 years at Microsoft, and only achieved what they originally planned to do in 1 year.
By Qem 2026-03-0814:41 To be fair, they suffered a bit from scope creep, as mid project it was started a second major effort to remove the gil. So the codebase was undergoing two major surgeries at the same time. Hard to believe they could stick to the original schedule under those conditions. Also gil removal decreases performance from sequential execution. I imagine some gains from Faster CPython were/will be spent compensating this hit on gil-less single thread performance.
By pjmlp 2026-03-0810:42 See also VC++ now lagging behind ISO, after being the first to achieve C++20.
By grzaks 2026-03-0810:01 We have been using PyPy on core system component on production for like 10 years
> 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 in amazement, and then run your whole app and it fails. Until there's a serious attempt at real 100% compatibility, none of this is going to change.
Also none of the deltas are well-documented. My personal journey with PyPy hit a wall when I realized that it's GC is lazy instead of greedy. So a loop that relies on the interpreter to free stuff up (e.g. file descriptors needing to be closed) rapidly runs into resource exhaustion in PyPy. This is huge, easy to trip over, extremely hard to audit, and... it's like it's hidden lore or something. No one tells you this, when it needs to be at the top of their front page before your start the port.
By networked 2026-03-0815:00 "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)
By cfbolztereick 2026-03-0815:011 reply 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.
Strongly disagree. If you're relying on Python garbage collection to free file descriptors in a loop, you have a subtle bug that will rear its head in unexpected and painful ways (and by some unwritten law of software, most notably either at 3 AM or when you have an important demo scheduled). This is true whether you're running in CPython or PyPy. It's not hard to avoid - use `with` or `try...finally`. It's not some newfangled language feature. It's not a surprise - you can't write good RAAI code in Python. It's a sign of someone with a poor grasp of the language they're using. If you find things like this, you should fix them, even if you never intend to use PyPy.
> If you're relying on Python garbage collection to free file descriptors in a loop
Again, that's a proscription for how to write python code for future execution. It's emphatically not a statement for the behavior expected by python code already in production, which tends to rely on this behavior (along with many other such warts and subtleties) implicitly.
And the fact that PyPy doesn't feel the need to clone it (and all the others) explains why PyPy basically doesn't work for existing python code.
I mean, me being an idiot python developer in your eyes does nothing to make the ancient code I received run. It just makes you feel smarter. That's a bad trade.
PyPy needs to be compatible before anyone is going to use it. And it isn't. And so people didn't. And so now it's basically dying as no one wants to work on a project no one uses.
By aftbit 2026-03-124:12 It's not about feeling smart or dumb. I'm not doubting that lack of perfect compatibility is holding pypy back, though I suspect it's more related to C extensions and libraries than it is to bug-for-bug compatibility with the garbage collector. I just think that code which does this specific wrong thing that you've mentioned is already doomed to not work reliably even under CPython.
By cozzyd 2026-03-0819:02 I've run into similar resource limit exhaustion due to the GC not keeping issues with cpython as well
