Python 3.14 compiled to metal – no interpreter(github.com) |
Python 3.14 compiled to metal – no interpreter(github.com) |
1. It's not Python by any means, it's a subset with its own runtime, its own quirks and nuances;
2. It will be impossible to maintain parity with CPython without AI assistance;
3. It will die the same way as dozens of similar (even non-AI projects) died before, and reasons will be the same: (1) and (2).
A subset of python is python. Half a tomato is still tomato
>2. It will be impossible to maintain parity with CPython without AI assistance
What does that even mean? If you would have said that it's impossible to update to python 3.15 of further, I'd get it.
The funny thing about this is not that the first sentence is wrong, which it is. It’s the failed reductio ad absurdum.
A subset of a calculator is still a calculator, but that subset definitely can't do everything the full version can.
Mojo folks (rightly) disagree.
It runs and passes the full cpython testsuite, just 5x faster.
With AI it's 100x easier to maintain than by hand.
It reminds my on pperl. same approach using crane lift. Looks good
It also explicitly says that they’re still working on building out the standard library.
I’m maybe not as pessimistic as leobuskin, but they are absolutely right that this is not the first time someone has tried to build an alternative Python implementation, and that all previous ones have failed because they weren’t able to get close enough to 100% parity to be acceptable to most users. Python is an unusually quirky language. I kind of wonder if “written in Rust” adds an extra headwind here because there’s nothing even remotely memory-safe about Python’s extension mechanism. I don’t know enough to know, but I have read about the death of a few of these projects in the past and a common theme of the post-mortem seems to be, “It went so smoothly at the start that we were caught off guard how much of a brick wall the last 5% was going to be.”
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that"
The irony…
> What is explicitly not done yet — this is the active roadmap, in order: > CPython test suite (cpython-full): the standing grind; failures are clustered and burned down per wave.
Is a pretty oof sentence for a project with one contributor and no users. Just reeks of llm barf with no oversight.
https://github.com/Nonannet/copapy uses copy and patch, discussed here https://news.ycombinator.com/item?id=46972392
Single-pass SSA bytecode compiler and threaded-code stack VM for a sandboxed Python subset https://github.com/dylan-sutton-chavez/edge-python
Is it faster than the original interpreter? Maybe if you optimize out the primitives and certain well-known object types, unless you do some more advanced static analysis.
This is a pretty hard problem to just solve in a week.
EDIT: and man, these kind of comments LLM created comments are really starting to grind my gears as my job slowly turns into reviewing LLM PRs:
> Known gaps at the language level are burned down through the ratcheted floors above — the committed floor files, not this README, are the authoritative compatibility baseline.
it doesn't matter as long as it works.
I think the clankers would call this a "load bearing statement".
It might make more practical sense to start from CPython and try to optimize that further though. It even has a "not fully fleshed out" JIT already.
Basically the entire Python ecosystem has deep integration into implementation details of CPython, if there was a runtime independent api like HPy, then the effort would be better spent migrating to it rather than building yet another half baked JIT.
or we can bring back gopher and just not index slop sites?
I see this as a case of the "quick to get to a POC that falls apart after sustained development for the same reasons it didn't work pre-Fable" problem.
>What is explicitly not done yet — this is the active roadmap, in order:
>CPython test suite (cpython-full): the standing grind; failures are clustered and burned down per wave.
>Stdlib build-out: _io/os, math/struct/random, collections/itertools/json, datetime, importlib parity — each lands as a native module plus a differential corpus module.
>Performance ratchets: tagged small-int flip, TLAB allocation, dict fast paths, float unboxing, call/attribute specialization, generator tiering — toward the ≥5× CPython geomean target (numerics ≥20×).
>AoT parity growth toward the full corpus, plus single-binary product polish.
>No-GIL/free-threaded runtime hardening: thread/GC/signal stress is now on the default runtime path, with remaining gaps tracked by the ratcheted suites.
Overall the substantial parts of his comment are completely wrong and the subjective parts are not much better
>With AI it's 100x easier to maintain than by hand.
This is an unsubstantiated opinion. In practice AI has a limit well below 100x.
>It reminds my on pperl. same approach using crane lift. Looks good
The only thing I can find on the internet that mentions "pperl" is this https://metacpan.org/pod/PPerl
>This program turns ordinary perl scripts into long running daemons, making subsequent executions extremely fast. It forks several processes for each script, allowing many proceses to call the script at once.
Which sounds nothing like pon, which is heavily inspired by bun. Meanwhile if it's this: https://perl.petamem.com/ which took quite a while to find, then I'm wondering why that would have precedence over bun?
Once you add the first sentence, it basically turns into a negative value comment that shouldn't have been posted.
It will be interesting to see how cheap they can make it long term.
Fable-level capability will most likely be available for pennies soon enough.
Just like how a device that can’t multiply or divide is not a 4-function calculator; it’s more like an adding machine. Many of which did multiply by serial addition.
Same thing people claim every time a new model is released, yet never seems to be true.
Do they still make mistakes? Sure. So do humans, though, so it would be unrealistic to expect perfection. The question is: does Fable make fewer mistakes than the median human coder? And at this point I'm genuinely not sure anymore.
> It does not create messes.
?
Someone else paying for the tokens.
Also someone seeing it through (should that come). Obviously we're not "at the moment when most of us can ask Fable to implement a custom compiler to a custom target for our favorite language, and even use it as a part of custom solution", without thousands to spare and lots of time to shape the solution.
If you're a hobbyist trying to compile python to your weird little arduino based thing, then that's a lot of money and you would want to use somebody else's solution, no doubt.
But if you're an aerospace company trying to compile for a flight control computer (and I guess you really want to use python for some reason), spending thousands of dollars on tokens to make and maintain a custom compiler could represent serious savings.
The big picture impact of AI that I see/anticipate the most is SAAS dying out because AI coding makes this kind of enablement and support software easier to make in-house, and this feels like an example of that, but maybe I'm seeing what I expect to see.
>But if you're an aerospace company trying to compile for a flight control computer (and I guess you really want to use python for some reason), spending thousands of dollars on tokens to make and maintain a custom compiler could represent serious savings.
If you're an aerospace company you're willing to pay thousands of dollars for a compiler, because you need a DO-178C certified toolchain so that you can DO-178C certify the whole airframe. Suggesting AI here tells me you have no clue about the realities of aerospace, because you've just thrown out the entire value proposition of the commercial toolchains.
I wouldn't spend $100K in tokens to get a custom bare metal Python. Or even $10K.
And I'd guess that most devs wouldn't either, unless they spend $10K like it's nothing.
People that have "paid far more for far less" are people who have the money to buy $10K watches, or fancy multi $1000 clothes.
'
def hello_world():
print("hello, world")
Is that not python? Yet it uses a subset of python?
That program can be run by either a python runtime, or a python subset runtime.
Now if you were to run a python subset program, like a hello world, you would get:
'
def hello_world():
print("hello, world")
Whoah, it's the same thing.
Turns out every program you write with a subset of a language, is valid for the super language.
Subjectively also, if the subset is big enough, it feels like that language, if it uses 'def' for functions, that's python. 'I know it when I see it' kinda deal.
I think the confusion comes from the mathematical folk reading "subset of X is X", and implying that "subset of X=X". But this is natural language, not mathematical language, when I say that "dog is mammal", I'm not saying that "dog = mammal" I'm saying that "dog ∈ mammal", and "subset of python ∈ python"
Arguably, passion for a project is without price.
In ~1976 Mythical Man Month era it was around 5 lines of fully debugged assembly.
Code Complete 2nd edition ~2004 bumped that up to 10-50 delivered lines of code per day.
I found other estimates of around 20-60. I need to pull them altogether into a cited article.
Based on that plus my own experience I think 100 lines per day of production-level, reviewed and debugged code was a reasonably higher target for a professional software engineer up until just a couple of years ago.
Today I'm frequently pushing 2,000 to 4,000 - and that's not vibe coded junk (I can easily hit 10,000+ if I'm not reviewing anything), that's code that I've reviewed and am happy to put my name to.
Obviously counting lines of code is a stupid, easily gamed metric. But I still think there's signal there. If you want to build a sophisticated piece of software you're going to have to write a bunch of code to do it. Writing at 1,000+ lines of code per day vs 100 will get you there faster.
Is it?
People have solved AI bugs with AI. If some vibe project eventually hits some bug and stops working, what exactly stops using AI to fix it? Is the idea that bugs will go beyond the limits of AI capability?
If you meant to say that when an AI vibe coded project beyond some complexity it's difficult for a human coder to manually go through all the code they didn't write, understand it, and find the issue, sure.
And it's quite easy to ask an AI to refactor a certain way too.
If you use AI yourself, with a focus on bug fixing and stability, you'll find that AI can fix bugs just fine.
The loops themselves are a lot better, but it still needs judgement calls, and Fable will often take an odd direction, and if you don't catch it, that odd choice will compound as it continues to layer on top.
Even so, if it does 80% of the work itself, that's still a 5x improvement.
Plus it keeps the human coder in control and in the loop (and in a job).
And they are TRYING to fix the bugs, they just keep failing over and over, so your reply is entirely incorrect.
Nice try though.
If you ship updates fast, you can't just 'focus on both'. You focus on one or another, doesn't matter if you use "unlimited tokens", same way 9 pregnant women can't make a baby in a month.
>And they are TRYING to fix the bugs, they just keep failing over and over, so your reply is entirely incorrect.
That they "keep failing over and over" is a huge overstatement, it just has some bugs like other software has, so your point can be simply dismissed.
Can you explain why not? Just spin up another agent. 9 pregnant women can do 9 babies in 9 months.
This is a real question. I assure you that teams of more than 1 developer do exist, so I don't see why agents could not work on the same code.
> That they "keep failing over and over" is a huge overstatement
You call it an overstatement because of your religious beliefs. Unfortunately religious beliefs don't really change the fact that they keep failing in fixing their things.