Comment by wbolt 4 days ago
More than 300 comments here and still no convincing answer. Why the community wastes time on trying to make CPython faster when there is pypy which is already much faster? I understand pypy lacks libraries and feature parity with up to date CPython. But… can’t everyone refocus the efforts and just move to pypy to add all the missing bits and then just continue with pypy as the “official python”? Are there any serious technical reasons not to do it?
I really hope I'll never need to touch code written by people who code in python and throws it at a plausible randomiser to get java or C
If you for some reason do this, please keep the python around so I can at least look at whatever the human was aiming at. It's probably also wrong as they picked this workflow, but there's a chance it has something useful
LLMs are there to get the meat of the software in. Fine tuning it is easy when you already have all the syntax written for you. With enough prompting on how you want the code laid out, the modern models do a really good job of getting it right with very minor things you have to tweak.
I get the "old man yells at cloud" vibes from your comment. Who cares how he got the result? I thought our job is to create working software. If this flow works for him and creates code that meets company standards, then more power to him.
However, if the output quality is crap, then well, maybe his creativity should not be rewarded. I've seem hefty amount of Map<Object, Object> in Java, written primarily by JS developers.
"create working software" is usually just a tiny bit of the job. That software then exists and needs to be extended and maintained.
If the result is great and maintainable code, great. I imagine it won't be, as no one has actually understood it even once.
As an old man myself, I am quite sure the other old man has a good reason to yell at this particular cloud. Software is tremendously complex. It is one thing to write it, it is another to amend the thousands and thousands of bugs that inevitably follow, and implement the even bigger amount of adjustments and improvements successful software requires. The latter is the bane of any kind of code generation, whether is RAD, no-code, low-code or LLM ported codebases.
Any kind of code generation that proves incredibly productivity in the writing of software is kind of like saying you have a lot of money by maxing out your creditcard. Maybe you can pay it back, maybe you can't. The fact that there is no mention of future debt is exactly the kind of thing that old men get suspicious about.
I'm not saying the old men are correct. I'm just pointing out the reason for the yelling.
Repl I get it. Possibly valid point. Yet I guess same issue are valid to node.js which seems much faster in many cases and still has valid dev experience.
C compatibility / extension compatibility - nope. First, it is an issue of limited resources. Add more devs to pypy team and compatibility bugs gets fixed. Second, aren’t people writing C extensions due to python being slow? Make python fast - as pypy - and for some cases native code won’t be that crucial.
So I don’t see a real issue with pypy that could not be solved by simply moving all the dev efforts from CPython.
So are there political, personal or business issues?
>C compatibility / extension compatibility - nope. First, it is an issue of limited resources.
No, its an issue of reinventing the wheel. Native code is native code. Numpy stuff isn't going to be faster running in pypy, neither is any of the ML stuff. Stuff like FastAPI or Uvicorn aren't going see much speed increase.
In the modern world, there is basically no need for middle ground performance. In the past, when you had single core processors, making things go fast was advantageous. Now, if you need to go fast, you most likely need to go REALLY fast, at which point just go full native. Otherwise, you are going to be slowed down by network calls and other factors.
So while PyPy is a cool projects that can be an optimization on top of regular python, its not worth while trying to make Python into something it will never be
> can’t everyone refocus the efforts
You have answered your own question.
Seriously, though. PyPy is 2-3 versions behind CPython (3.11 vs 3.14) and it's not even 100% compatible with 3.11. Libraries such as psycopg and lxml are not fully supported. It's a hard sell.
But this is exactly my point. The resources pypy has are much smaller. And still for years they managed to follow up being just 2-3 versions behind with features and high on performance.
So why not move all the resources from CPython to close the gap with features faster and replace CPython entirely?
Since this is not happening I expect there to be serious reasons, but I fail to see them. This is what I ask for.
> Are there any serious technical reasons not to do it?
Forget technical reasons, how would you ever do it? It feels like the equivalent of cultural reprogramming "You must stop using your preferred interpreter and halt all your efforts contrary to the one true interpreter". Nah, not going to happen in a free and open source language. Who would have the authority and control to make such a directive?
Yes, there may be technical reasons, but the reason it doesn't happen more than any other is that programming languages are languages spoken by people, and therefore they evolve organically at no one's direction. Even in languages like Python with a strong bent for cultural sameness and a BDFL type direction, they still couldn't control it. Often times, dialects happen for technical reasons, but it's hard to get rid of them on technical grounds.
I think for pure python performance it is significantly faster at least on all the benchmarks I have seen. That said a lot of what people actually do in python calls into libraries that are written in C++ or C, which I believe has a similar performance (when it works) on pypy.
> Are there any serious technical reasons not to do it?
Yes.
First is startup time. REPL cycle being fast is a big advantage for development. From a business perspective, dev time is more expensive then compute time by orders of magnitude. Every time you make a change, you have to recompile the program. Meanwhile with regular python, you can literally develop during execution.
Second is compatibility. Numpy and pytorch are ever evolving, and those are written a C extensions.
Third is LLMs. If you really want speed, Gemma27bqat that runs on a single 3090 can translate python codebase into C/C++ pretty easily. No need to have any additional execution layer. My friend at Amazon pretty much writes Java code this way - prototypes a bunch of stuff in Python, and then has an LLM write the java code thats compatible with existing intra-amazon java templates.