Warn about PyPy being unmaintained
github.com
github.com
I wanted to put a little £ towards the project but couldn't see a place to do it.
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)
An easy chart to show v3.x is 10% faster than the last version would be great.
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.
Though they use an inflated star ranking system, which doesn't reflect reality.
> not actively developed anymore
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.
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.
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 .
Sure you can were you should have pinned dependencies but that's a lot of overhead for a random script...
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.
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.
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.
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.
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.
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.
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.
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.
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.
https://news.ycombinator.com/item?id=36940871 (573 points, 181 comments)
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.
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.
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.
Edit: it's just python. People are pretending like other attempts to implement this are on equal footing
It’s literally the name of the repo [1].
There’s no grounding to feign surprise or concern anymore.
Moreover, I have used PyPy for years to beat the pants off CPython programs.
Nobody is "pretending" anything. These have all been around for 15+ years at this point. Your ignorance does not imply intent to deceive on others part.
for C compilers no reference implementation exists. the C standard was created out of multiple existing implementations.
Given that both pypy (through RPython) and mypy deal with static type checks in some sense, I kept confusing the two projects until recently.
Also, I just learnt (from another comment in this post) about mypyc [1], which seems to complete the circle somehow in my mind.
[0] https://www.mypy-lang.org/
[1] https://github.com/mypyc/mypycMaybe it's changed since, but last I checked the JVM's JIT did not care at all for java's types.
Which is not to say JITs don't indirectly benefit mind, type annotations tend to encourage monomorphic code, which JITs do like a lot. But unlike most AOT compilers it's not like they mind that annotations are polymorphic as long as the runtime is monomorphic...
I say that as a programmer and engineer.
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
(Tip of the hat to Microsoft’s marketing teams.)
Match case and even the walrus operator come to mind.
The gist of what GP meant is that Python does not exactly follow SemVer in their numbering scheme, and they treat the middle number more like what would warrant a major (left-most) number increase in SemVer. For example, things will get deprecated and dropped from the standard library, which is a backwards-incompatible change. Middle number changes is also when new features are released, and they get their own "what's new" pages. So on the whole, these middle-number changes feel like "major" releases.
That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.
> A is the major version number – it is only incremented for really major changes in the language.
> B is the minor version number – it is incremented for less earth-shattering changes.
> C is the micro version number – it is incremented for each bugfix release.
The docs do not seem to mention you, though. :P
[0]: https://docs.python.org/3/faq/general.html#how-does-the-pyth...
That's ultimately the point I was trying to make; my inner pedant can't help but feel the need to push back on people using versioning terminology inconsistently, but in practice I don't think it really made much of a difference in this case.
Or at runtime, you can import things from the standard library which require a minimum 3.x. - .x releases frequently if not always add things, or even change an existing API.
Are you saying that you'd get an error using the new feature on an old version, or that code that used to parse on old versions would not longer work on the newer version? The former is pretty much a textbook example of a minor version update in "traditional" semver; a single new API function is enough to potentially make new code not work on old versions, since any calls to that function will not work on versions predating it. The latter is what would constitute a "breaking change" in semver; old code that used to work can't be made to no longer work without a major version bump.
I say "traditional" semver because in practice it seems like there are fairly few cases in which people actually seem to fully agree on what semver means. I've always found the "official" definition[1] to be extremely clear, but from what I can tell most people don't really adhere to it and have their own personal ideas about what it means. I've proposed things in projects that are fully within both the letter and spirit of semver quite a few times over the years only for people to object on the basis that it "isn't semver" because they hadn't fully read through the description before. Typically I'll mention that what I'm suggesting is something that semver allows and bring up the page and show them the clause that specifically allows what I'm saying but clarify that I recognize we still might not want to do it for other reasons, and the other person will end up preferring to stick with their initial instinct independent of what semver actually says. This is totally fine, as semver is just one of many versioning scheme and not some universal optimum, but my point is that it's probably more confusing for people to use the same term to describe fairly inconsistent things.
[1]: https://semver.org/
Also, looking at the alternate (full) interpreters that have been around a while, PyPy is much more active than either Jython or IronPython. Rust-python seems more active than PyPy, but it's not clear how complete it is (and has going through similar periods of low activity).
Would I personally use PyPy? I'm not planning to, but given how uv is positioning itself, this gives me vibes of youtube stating it will drop IE 6 at some unspecified time in order to kill IE 6 (see https://benjamintseng.com/2024/02/the-ie6-youtube-conspiracy...).
There is more churn in those versions than you'd think.
pypy 7.3.20, officially supporting python 3.11, was released in july 2025: https://pypy.org/posts/2025/07/pypy-v7320-release.html
We're in March 2026. That's 9 months, which is exactly what GP stated.
> There was a reasonable sized effort to provide binaries via conda-forge but the users never came.
How is that in any way relevant to the maintenance status of pypy?
Which it has always been, especially since Python 3, as anyone who's followed the pypy project in the last decade years is well aware.
Imagine someone releases RustPy tomorrow, which supports Python 2.7. Is it maintained? Technically, yes - it is just lagging behind a few releases. Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.
Which is a concern for those libraries, I've not seen one thread criticising (or even discussing) numpy's decision.
> Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.
But it's not, and either way that has nothing to do with uv, it has to do with people who use pypy and the libraries they want to use.
Meanwhile my projects got marked as abandoned because those scanners are unaware of codeberg being a thing.
And I think that PyPy might be of interest to the Fund for sponsoring given its close to unmaintained. PyPy is really great in general speeding up Python[1] by magnitudes of order.
Maybe the fund could be of help in order to help paying the maintainer who are underfunded which lead to the situation being unmaintained in the first place. Pinging you because I am interested to hear your response and hopefully, see PyPy having better funding model for its underfunded maintainers.
[0]: https://endowment.dev/about/#model
[1]: https://benjdd.com/languages2/ (Refer to PyPY and Python difference being ~15x)
unfortunately, @-pinging does not work on this site, it does nothing to notify anyone. If you want to get a specific person’s attention, use off-site communication mechanisms
I’d call it fortunate, and a feature. Not pinging certainly avoids many discussions becoming too heated too fast between two people and lets other opinions intervene.
Not having a mentions functionality for those who wish to use it doesn't seem to to change anything around over-heated discussions.
I'd make @ a page like 'threads' which just includes any comments with @$username.
Like what? I never saw anything to suggest that is the case.
> Not having a mentions functionality for those who wish to use it doesn't seem to to change anything around over-heated discussions.
Of course it does. If you have to keep checking manually, eventually you’ll get distracted. By the time you come back, if you do, there may already be another reply to the reply and you may no longer feel the need to comment. Nor will you be inclined to respond to a comment made days later in a nested discussion, because you won’t find it. But people just arriving at the thread might, and continue the discussion with new perspectives.
> I'd make @ a page like 'threads' which just includes any comments with @$username.
To each their own, I’m thankful HN doesn’t have that feature.
You get blocked if you comment too fast.
it's too bad. it is a great project for a million little use cases.
And more
The hardest things in programming. That and designing a logo for something you cannot touch, smell or see.
https://claude.com/contact-sales/claude-for-oss https://openai.com/form/codex-for-oss/
And for what's it worth, PyPy isn't even eligible for the Claude trial because they have a meager 1700 stars on GitHub.
An unmaintainable mass of Ai slop code and the decision to either pay the ai tax or abandon the project.
(I haven't checked the OpenAI one, as I have no interest in them)
I expect they haven't decided that themselves yet and don't want to commit publicly until they've seen how well the program goes.
You know what they could also do? Stop the programs for new enrolments next month. Or if if they renew them like you said, it could be with new conditions which exclude people currently on them.
There are too many unknowns, and giving these companies the benefit of the doubt that they’ll give more instead of taking more goes counter to everything they showed so far.
We should be discussing what is factual now, not be making up scenarios which could maybe happen but have zero indication that they will.
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.)
"Anthropic released vibe coded C compiler that doesn't work" sounds like https://github.com/anthropics/claudes-c-compiler/issues/1 passed through a game of telephone. The compiler has some wrong defaults that prevent it from straightforwardly building a "Hello, world!" like GCC and Clang. The compiler works:
> The 100,000-line compiler can build a bootable Linux 6.9 on x86, ARM, and RISC-V. It can also compile QEMU, FFmpeg, SQlite, postgres, redis, and has a 99% pass rate on most compiler test suites including the GCC torture test suite. It also passes the developer's ultimate litmus test: it can compile and run Doom.
What you’re seeing is a shibboleth. If you can make the above claim without choking, then you’re a member of the tribe. If it seems so outlandish that honor and sense demand you point out the problems, you’re marked as an enemy.
This is the perfect question to highlight the major players. In my opinion, a rapidly developing language with a clear reference implementation, readily accessible specifications, and a vast number of easily runnable tests would make an ideal benchmark.
The primary objective is to retarget PyPy on top of the Python main branch. A minor objective is to document what of PyPy can be ported to CPython (or RustPython).
Keep a markdown log of issues in order to cluster and close when fixed
Clone PyPy and CPython.
Review the PyPy codebase and docs.
Prepare a devcontainer.json for PyPy to more safely contain coding LLMs and simplify development
Review the backlog of PyPy issues.
Review the CPython whatsnew docs for each version of python (since and including 3.11).
What has changed in CPython since 3.11 which affects PyPy?
Study the differences between PyPy code and CPython code to understand how to optimize like PyPy.
Prepare an AGENTS.md for PyPy.
Prepare an agent skill for upgrading PyPy with these and other methods.
Write tests to verify that everything in PyPy works after updating it to be compatible with the Python main branch (or the latest stable release, CPython 3.14)
For me the biggest signifier is Spotify. They claim their (best) devs don't even code anymore, they use an internal AI tool that they just send prompts to which then checks out a personal test build that they can download off of Slack. "A new feature in 10 minutes!"
Okay, if that is the case, why have we only seen like 3-4 minor new QoL improvements in Spotify the last ~12 months, with no new grand features? And why haven't they fired 95% of their devs and let the remaining elite go buckwild with Claude?
The Emperor really has no clothes.
No, they claimed they didn’t code during a time period. Around year end until early this year. Technically they could have just been on leave.
Also best dev = principal / staff engineers. They rarely code anyway.
AI or no AI anyone could have made that claim.
My CEO keeps asking me "how can we go faster with AI", and my answer is "we can't, because even if we had developers that would instantly develop any feature perfectly, we'd still be bottlenecked on how slow we are at deciding what to actually release".
You are seeing improvements? From what I can tell, my user experience has only been going downhill over the past years - even pre-AI...
Edit: I understand the underlying issue and the PyPy developer's opinion. I don't disagree on that part; I only refer to the name similarity as a problem.
Still, at its core, PyPy is a Python interpreter which is itself written in Python and the name PyPy fittingly describes its technical design.
"Move the pypy trunk into its own top level directory so the path names stay constant."
PyPy migrated from Subversion to git at some point. Not sure how much of the history survived the migration.
If your thing can be reached under "pypi.org", you can either accept that people will come up with their own ideas of how to capitalize or pronounce the name, or you can fight against windmills and tell people what ought to exist or not.