FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
48% Positive
Analyzed from 1547 words in the discussion.
Trending Topics
#python#project#cpython#subset#doesn#code#same#still#hard#fable
Discussion (87 Comments)Read Original on HackerNews
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).
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.
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"
[0] https://news.ycombinator.com/newsguidelines.html
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.
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.
Is a pretty oof sentence for a project with one contributor and no users. Just reeks of llm barf with no oversight.
Is it faster than the original interpreter? Maybe if you optimize out the primitives and certain well-known object types, unless you do some really complicated static analysis.
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
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.
https://github.com/can1357/selene
it doesn't matter as long as it works.
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.
I think the clankers would call this a "load bearing statement".
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.