Where do we go from here? Microsoft did not continue to finance the Faster CPython project and the current speed gains are good, but not what we hoped.
[–] Eji1700 2 days ago
[–] vovavili 2 days ago
[–] pjmlp 2 days ago
AI needs formal verification, not a borrow checker.
[–] Retr0id 2 days ago
[–] tweakimp 2 days ago
[–] jerf 2 days ago
The problem is that Python just isn't going to go fast. There are some languages that may have had more resources poured into them to make them go faster in absolute terms, like perhaps Java. But I don't think there's a single language that has had so many ways of trying to make it go faster given so much effort over so many decades. It's really time to call it... if you have Python code and it's a performance problem, if one of the many many many different solutions aren't adequate for some reason, Python is not going to get any faster than it is today and you're going to have to move off of it.
If you need high performance code, Python is simply not the right answer and you're going to have to skill up. Or accept what you have, which you'll have to decide if that's a viable option. If it's fast enough I don't advocate switching casually. But if it isn't, there isn't a realistic prospect that you're going to wake up in a year or two to a 30x-faster Python. I wasn't terribly convinced by that claim back in the early 2000s, but it hadn't really been tested yet. It has been tested now.
[–] LtWorf 2 days ago
[–] jerf 1 day ago
Second, no, it isn't. Pypy is really fast compared to Python. "Compared to Python" is just about the lowest bar there is, though. In absolute terms it is still only a medium-fast language runtime, and it comes with a lot of costs and tradeoffs.
That's the problem with Python. Lots of ways to take a very slow language and make it a medium-fast language with substantial tradeoffs, or make it a fast language with enormous tradeoffs. If you can handle the tradeoffs, fine. But if you can't you just need to switch to a language that is fast without anywhere near as many tradeoffs.
[–] anthk 2 days ago
[–] skeledrew 2 days ago
> RustPython is in development, and while the interpreter certainly can be used in interesting use cases like running Python in WASM and embedding into a Rust project, do note that RustPython is not totally production-ready.
[–] Yossarrian22 2 days ago
[–] bob001 1 day ago
[–] skeledrew 2 days ago
[–] mahboi 2 days ago
[–] vova_hn2 1 day ago
You don't have to throw away the original Python codebase.
You can have:
1. An implementation in slow language (i. e. Python) that you maintain manually or semi-manually (with minimal AI assistance) and understand well.
2. A fast implementation that is fully generated and maintained by AI, using slow implementation (1) as a reference.
You can, for example, run two "adversarial" agents, one writes tests that compare output of (1) and (2) and tries to find a discrepancy, the other tries to fix (2) so that its output never differs from (1).
This way, you can be reasonably confident that (2) does exactly the same thing as (1), despite being a blackbox that you don't understand. While (1) remains a reference implementation that you understand well and can work with.
[–] lemagedurage 2 days ago
[–] Retr0id 2 days ago
[–] samus 2 days ago
Implementation effort has never been what has held these efforts back. LLM helps with squirting out code, but the hard tasks are benchmarking, profiling, community engagement, knowledge management, and dealing with the hard questions such as whether the change is actually worth the additional complexity.
These concerns won't go away even if we give up on human developers being able to grok the code and instead completely relying on LLMs for coding.
[–] pjmlp 2 days ago
Clearly the community doesn't want PyPy, GraalPy, or even a CPython JIT.
F# is on the softest side of that, but letting the compiler tell the AI "nope, here's why" seems like a huge win in saving cycles and time.
The downside at first was simply, "how many examples of F# are there to learn from", and early on it showed, but I think that's been long overcome.
And F# is obviously NOT the best example since it's both "soft" on functional purity and niche. I imagine something like haskell is probably doing even better, although I've yet to check that at all (not that I can code haskell but I haven't looked at anecdotes or anything).
I realize this doesn't really help anyone who's grown to love python, and there's surely no perfect language, but just like how the web catapulted javascript, I see a future where the answer isn't "use AI to make python better" so much as "what already works super well with AI, and does it ease the user adoption"