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
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.
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.
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.
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.
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)
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.
> 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.
"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.
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.
If anyone else is also barely aware and confused by the similar names, PyPI is the Python Package Index, which is up and maintained. PyPy is "A fast, compliant alternative implementation of Python." which doesn't have enough devs to release a version for 3.12[0].
Thanks for the clarification. On top of that, being an issue in the 'uv' GitHub repo (uv installs packages from PyPi) made my brain easily cross the letters.
There's a difference between dead (i.e. "unmaintained") and low activity ("not under active development"). From what I can see PyPy is in the latter category (and being in that category does not mean it's going to die soon), so choosing to claim it is unmaintained is notable.
@kvinogradov (Open source endowment), I am (Pinging?) you because I think that you may be of help as I remember you stating that within the Open source endowment and the approach of how & which open source projects are better funded[0]
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.
> @kvinogradov (Open source endowment), I am (Pinging?) you
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
> unfortunately, @-pinging does not work on this site
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.
knowing pypy has good implementations of a lot of behavior it helped me fix multiprocessing in Maya's python interpreter, fixing stuff like torch running inside of Maya.
it's too bad. it is a great project for a million little use cases.
- The pure python repl started off in PyPy, although a lot of work was done to make it ready for prime time by the COython core devs
- The lessons from HPy are slowly making their way into CPython, see https://github.com/py-ni
- There were many fruitful interactions in fixing subtle bugs in CPython that stemmed from testing the stdlib on an alternative implementation
I really like PyPy’s approach of using a Python dialect (RPython) as the implementation language, instead of C. From a conceptual perspective, it is much more elegant. And there are other C-like Python dialects now too - Cython, mypy’s mypyc. It would be a shame if PyPy dies.
Most pure Python libraries run on PyPy without porting, while incompatibilities come from C extensions written against the CPython C-API such as numpy, lxml and many crypto libraries that either fail or run poorly under PyPy's cpyext compatibility layer.
If you plan to support PyPy, add it to your CI, prefer cffi or pure Python fallbacks over CPython C-API extensions, and be ready to rewrite or vendor performance-critical C extensions because cpyext is slow and incomplete and will waste your debugging time.
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?
I remember from the Gentoo days that when you compiled PyPy from source it would generate a Mandelbrot in ANSI art during the compilation. I was so impressed!
my view/experience is that pypy only makes faster the type of python code which you absolutely should not write in python if you care about performance
Is this another subversion attack? Basically putting up some subverted package to a established one, that is lazily maintained and then created enough ruckus for the target to switch packages?
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?
Everyone here says "if developers are so much faster, why aren't we seeing more features?!" as if the only thing required to release a feature is developers.
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".
tbf they have been saying they've started doing this since December, so we're only a few months in. And like most software it's an iceberg: 99% of work on not observable by users, and in spotify's case listeners are only one of presumably dozens of different users. For all we know they are shipping massive improvements to eg billing
Strange subthread. I don't see Claude Opus 4.6 changing the tide for PyPy. There is no need to understate AI capabilities for this.
"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.
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)
> Anthropic released vibe coded C compiler that doesn't work, how their LLM can help in maintaining PyPy?
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.
What annoys me is the name. Early morning it took me a
moment to realise that PyPy is not PyPi, so at first I
thought they referred to PyPi. Really, just for the name
confusion alone, one of those two should have to go.
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.
If you have to insist that a name needs a certain capitalization to properly exist, you're in the territory of brand zealotry and pedantry. The people who don't care for one reason or other vastly outnumber you, and they will invent your disfavored capitalization into existence. The same goes for pronunciation. GIF? Jira?
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.
No. PyPy development was ongoing long before the first release. The first intact commit in the PyPy repo is from February 2003: https://github.com/pypy/pypy/commit/6434e25b53aa307288e5cd8c....
And that commit indicates there's been development going on for a while already. The commit message is:
"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.
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
https://pypy.org/howtohelp.html
https://opencollective.com/pypy
2 replies →
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?
2 replies →
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.
Also big notice that it is unmaintained
And that the corporations using their work should donate if they actually want it maintained.
1 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.
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
Which is just as wrong.
14 replies →
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.
PyPy on numpy heavy code is often a lot slower than CPython
1 reply →
I rather like Python and have used the C API extensively, "nice" is not the word I'd choose ...
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)
2 replies →
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.
1 reply →
(This affected TypeScript, .NET and other folk too)
1 reply →
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.
"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)
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.
5 replies →
If anyone else is also barely aware and confused by the similar names, PyPI is the Python Package Index, which is up and maintained. PyPy is "A fast, compliant alternative implementation of Python." which doesn't have enough devs to release a version for 3.12[0].
[0]: https://github.com/orgs/pypy/discussions/5145
Thanks for the clarification. On top of that, being an issue in the 'uv' GitHub repo (uv installs packages from PyPi) made my brain easily cross the letters.
Reminds me of Cython vs CPython
What is cpython? I don't think I've heard of this one before.
Edit: it's just python. People are pretending like other attempts to implement this are on equal footing
6 replies →
and mypy is "an optional static type checker for Python" [0]
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.
pypy existed long before type annotations were a thing
2 replies →
Don't forget about RPy https://pypi.org/project/rpy2/2.2.7/
Don't forget about dmypy, the daemon version of mypy.
https://mypy.readthedocs.io/en/stable/mypy_daemon.html
Thanks. I knew this already but keep forgetting and getting confused
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.
3 replies →
The python community has the habit of giving short names for things
Thanks, I also saw this as PyPI and was confused, lol
now somebody just needs to make a PiPy for the raspberry pi
3 replies →
Somewhat interesting that "volunteer project no longer under active development" got changed to "unmaintained".
For context, they have 2 to 4 commits per month since October [1]. The last release was July 2025 [2].
[1]: https://github.com/pypy/pypy/commits/main/
[2]: https://github.com/pypy/pypy/tags
That seems reasonably active to me. You can't really expect more from an open source project without paid full-time developers.
What euphemism do you prefer then...
There's a difference between dead (i.e. "unmaintained") and low activity ("not under active development"). From what I can see PyPy is in the latter category (and being in that category does not mean it's going to die soon), so choosing to claim it is unmaintained is notable.
18 replies →
Undermaintained might be more suited since it does have life but doesn't appear commercially healthy nor apparently relevant to other communities.
1 reply →
much respect to the PyPy contributors, but it seems like a pretty fair assessment
9 months since the last major release definitely feels like a short time in which to declare time-of-death on an open source project
8 replies →
@kvinogradov (Open source endowment), I am (Pinging?) you because I think that you may be of help as I remember you stating that within the Open source endowment and the approach of how & which open source projects are better funded[0]
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)
> @kvinogradov (Open source endowment), I am (Pinging?) you
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
> unfortunately, @-pinging does not work on this site
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.
4 replies →
HN doesn’t have this sort of pinging behavior :/
knowing pypy has good implementations of a lot of behavior it helped me fix multiprocessing in Maya's python interpreter, fixing stuff like torch running inside of Maya.
it's too bad. it is a great project for a million little use cases.
wow, that would be a big shame. I hope many of the useful learnings are already ported to CPython.
- The pure python repl started off in PyPy, although a lot of work was done to make it ready for prime time by the COython core devs - The lessons from HPy are slowly making their way into CPython, see https://github.com/py-ni - There were many fruitful interactions in fixing subtle bugs in CPython that stemmed from testing the stdlib on an alternative implementation
And more
Almost none of it will have been ported to CPython, as it's a completely different approach.
I really like PyPy’s approach of using a Python dialect (RPython) as the implementation language, instead of C. From a conceptual perspective, it is much more elegant. And there are other C-like Python dialects now too - Cython, mypy’s mypyc. It would be a shame if PyPy dies.
Most pure Python libraries run on PyPy without porting, while incompatibilities come from C extensions written against the CPython C-API such as numpy, lxml and many crypto libraries that either fail or run poorly under PyPy's cpyext compatibility layer.
If you plan to support PyPy, add it to your CI, prefer cffi or pure Python fallbacks over CPython C-API extensions, and be ready to rewrite or vendor performance-critical C extensions because cpyext is slow and incomplete and will waste your debugging time.
Read as PyPi and almost had heart attack
> This thread is about PyPy, not PyPI.
The hardest things in programming. That and designing a logo for something you cannot touch, smell or see.
At this point it's probably better investing time and money into RustPython[1][2].
[1] https://rustpython.github.io/
[2] https://github.com/RustPython/RustPython
Why would anyone use a python interpreter that is slower than CPython?
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?
I remember from the Gentoo days that when you compiled PyPy from source it would generate a Mandelbrot in ANSI art during the compilation. I was so impressed!
Thank you for all the work guys, I’ll see how I can help.
my view/experience is that pypy only makes faster the type of python code which you absolutely should not write in python if you care about performance
Is this another subversion attack? Basically putting up some subverted package to a established one, that is lazily maintained and then created enough ruckus for the target to switch packages?
Odd how you still see announcements of this nature if Anthropic's marketing is be believed.
Yup.
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.
Everyone here says "if developers are so much faster, why aren't we seeing more features?!" as if the only thing required to release a feature is developers.
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".
1 reply →
> They claim their (best) devs don't even code anymore
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.
tbf they have been saying they've started doing this since December, so we're only a few months in. And like most software it's an iceberg: 99% of work on not observable by users, and in spotify's case listeners are only one of presumably dozens of different users. For all we know they are shipping massive improvements to eg billing
> why have we only seen like 3-4 minor new QoL improvements
You are seeing improvements? From what I can tell, my user experience has only been going downhill over the past years - even pre-AI...
Also, why isn‘t there a native client for all platforms? Could they not just let the AI auto-translate the code?
1 reply →
Anthropic released vibe coded C compiler that doesn't work, how their LLM can help in maintaining PyPy?
Strange subthread. I don't see Claude Opus 4.6 changing the tide for PyPy. There is no need to understate AI capabilities for this.
"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.
https://www.anthropic.com/engineering/building-c-compiler
1 reply →
Prompts for this?
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)
Strikes me as the worst possible solution if they're struggling to find maintainers in the first place. Who reviews the vibe coded patches?
> Anthropic released vibe coded C compiler that doesn't work, how their LLM can help in maintaining PyPy?
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.
Most maintainers don't have a stack of cash to throw at tokens.
They don’t need to throw a stack of cash at them, Anthropic and OpenAI have programs for open source maintainers.
https://claude.com/contact-sales/claude-for-oss https://openai.com/form/codex-for-oss/
13 replies →
"You're completely right. That mushroom is poisonous."
Is Python dying? /s
What annoys me is the name. Early morning it took me a moment to realise that PyPy is not PyPi, so at first I thought they referred to PyPi. Really, just for the name confusion alone, one of those two should have to go.
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.
There is no PyPi, it's PyPI (py pee eye), the Python package index.
If you have to insist that a name needs a certain capitalization to properly exist, you're in the territory of brand zealotry and pedantry. The people who don't care for one reason or other vastly outnumber you, and they will invent your disfavored capitalization into existence. The same goes for pronunciation. GIF? Jira?
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.
Wikipedia tells me that the package index PyPI (launched in 2003) is about 4 years older than the interpreter PyPy (first released in 2007).
Still, at its core, PyPy is a Python interpreter which is itself written in Python and the name PyPy fittingly describes its technical design.
No. PyPy development was ongoing long before the first release. The first intact commit in the PyPy repo is from February 2003: https://github.com/pypy/pypy/commit/6434e25b53aa307288e5cd8c.... And that commit indicates there's been development going on for a while already. The commit message is:
"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.
I think back then PyPI was known as the cheeseshop, so there wouldn't have been the same confusion.