I hate to be that guy, but... one week old project, clear signs of vibing. I will be shocked if the remaining work listed (cpython test suite) proceeds in any reasonable timeline.
This is a pretty hard problem to just solve in a week.
Given the stdlib modules listed as "explicitly not done yet", I'm going to say: it doesn't yet, in any meaningful sense. The question then becomes: how confident do we feel that it will work in the near future?
I was trying to say "not confident at all" but hedged a bit too much.
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.
"Very experienced" might mean different things to you. The oldest repo on their GH is from 2017. As for highly skilled: Could you point closer to which parts of their portfolio we are supposed to be awestruck by?
pickle files are usually the limiter here. I would be surprised if it can handle pickle files since it relies so much on runtime LUTs of the objects and arbitrary object definitions. This usually doesn't work in other use cases such as swig or cython either IIRC.
For NumPy/Pytorch, the C API is much bigger issue than pickle. I have not looked at the architecture of this, but given it uses its own IR + replaces ref counting w/ a GC, I am assuming it does not have C API compatibility.
The “status” section of the project’s readme explicitly says that it is not passing the full test suite, and that the AOT compiler passes fewer tests than the JIT one.
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.”
Your reply would have been much better without the first line [0]
> 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"
No, it wouldn't, because he didn't actually read the readme which clearly states that they are still working on passing the CPython test suite and that 5x performance is an aspirational goal, not something they accomplished yet.
>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.
>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
>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.
I noticed that it wasn't the best comment, I was only concerned with the tone, and I feel like dang has enough going on that we also need to help elevate the conversation. I admit there's some delicious irony in the accuser committing the same crime, but it doesn't improve the discussion to revel in that.
This isn't about the shell of a calculator though, but the functionality. Like if the only operations are addition and subtraction, theoretically you could derive the effects of other operations but it's extremely limiting.
So yeah, half of Python might still be Turing-complete, but it wouldn’t really be Python for any practical purpose.
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.
If you write a program in python, say a hello world:
'
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"
Mojo folks created a new language, officially called it "superset", and trying to sell to enterprise. And it's not a superset by definition, because it can't run it's "subset" (the original Python) without CPython (which was used as libcpython under the hood, iirc). It's a travesty.
Can those AI slop projects have a reserved tag on HackerNews? So many in the past few weeks I wouldn't have clicked and wasted my time on if I knew it was just some vibe-coded garbage.
I see the same thing, and believe that ironically AI is going to bring about the return of good search engines as we’re currently drowning in slop and need a real way to filter it.
you'd need a tacit agreement that real humans who care tag and filter things for the search engine. like a webring or stumbleupon. I imagine it's easier to bolt this on to an existing product by adding "tags" and a "AI likelihood score" or something.
or we can bring back gopher and just not index slop sites?
I am a fan of AI assistance, but “ratchet” is pretty much a Claude giveaway. The kids, now in their twenties because the reference is dated, might make a joke here.
Awesome. Not for this repo specifically; more about the trend. More people are realizing that we have such powerful tools at our disposal and will want to do something awesome, worth while with them. Of course, many will fall off after a week, then more after a month, but some will survive. Knowledge will be spread and some will be winners through adoption. Grit can lead to knowledge, and can lead to awesome stuff.
If AI can find new proofs for well posed math problems, i see no reason why it shouldn't be able to implement a more performant fully featured version of an existing interpreter (eg with JIT and AOT) that emulates python api well and passes all python tests and tests of other projects. It is true that a lot of human effort and thought has been put into squeezing performance out of the existing implementation. It is true that many people have found that getting that last 1% of python test suite to pass turned out to be insurmountably hard. Same is true for math, and yet AI sometimes finds simple solutions that we somehow missed. Maybe there's a simple optimization that was used in an obscure interpreter of a domain specific language that we never heard of. Worth a shot in my mind. If that turns out to be successful, we should ideally find the code that served "as an inspiration" if any.
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.
If humans can find (and have been finding for millennia) new proofs for well posted math problems, I see no reason why they shouldn’t be able to implement a more performant fully featured version of an existing interpreter.
Well, so far any gives level of capability has started with (expensive) frontier models, but everyone else, including the cheaper models, usually quickly catches up and the frontier keeps moving forward.
Fable-level capability will most likely be available for pennies soon enough.
Dynamic typing means you don't know the sizing of things beforehand. Instead of an interpreter, you get something resembling a runtime. Like Object could be a struct with a hashmap of property names->values, many of which will be pointers to other objects. Idiomatic C or Rust code will have flatter structs in many cases.
Is it faster than the original interpreter? Maybe if you optimize out the primitives and certain well-known object types.
Lol, all the people squawking about how this means nothing and this is a worthless project amuses me. A lot of people just don't see it yet. This is coming for literally everything and it is so exciting. The next decade is going to be awesome.
Most of the value proposition of Python is that it calls into fast native modules. Compiling Python itself helps a little, but it isn't that big of a deal. The most prominent Python JITs have been a failure because of the tight coupling between CPython and native modules.
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.
Funny to see it took the same IR approach as I did with https://github.com/rcarmo/go-joker - although I did it somewhat based on the .NET IR and this seems a bit more AI-ish.
73 comments
[ 2.9 ms ] story [ 39.4 ms ] threadThis is a pretty hard problem to just solve in a week.
it doesn't matter as long as it works.
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.
I think the clankers would call this a "load bearing statement".
https://github.com/can1357/selene
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).
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
>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.
The irony…
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.
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.
'
def 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():
'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"
Mojo folks (rightly) disagree.
or we can bring back gopher and just not index slop sites?
Is a pretty oof sentence for a project with one contributor and no users. Just reeks of llm barf with no oversight.
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.
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.
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.
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.