Making a Python interpreter in 1024 bytes

azhenley 171 points 64 comments September 06, 2026
austinhenley.com · View on Hacker News

Discussion Highlights (13 comments)

TZubiri

A lot of criticism of python often mentions the whitespace as lexical scope tokens, and that criticism is usually posited by users of the language. As implementer of an interpreter, did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?

ni5arga

the blog post is pretty well-written! loved how he wrote about the the code-golfing part.

teddyh

For those who actually need something like this in production, there is Snek: < https://sneklang.org/ > “ Snek is a tiny embeddable language targeting processors with only a few kB of flash and ram. ”

hankbond

Good use of free will and well-written. Very nice walkthrough austin!

Scubabear68

I was very disappointed that this is “interpreting” some tiny made up language. This is not Python, or even within three orders of magnitude of Python.

tempodox

This seems to be in the same spirit as Justine Tunney's SectorLISP. Very cool. https://justine.lol/sectorlisp/

anitil

This is really cool! It's so fun to see what you can achieve and what's optional. I have seen the 'single character variable' limitation in some other minilangs before, but using the source itself as the target of function calls and loops is new to me. It does make a lot of sense but I wouldn't have thought of that.

jrdres

The code makes me smile, because it's nasty . This isn't like C4, a tiny but complete C compiler which does error checking on its subset. Instead, this is worse than Sector C, which takes every shortcut and just plain assumes everything in the source is right. This "Python" just plain assumes for keywords: Any "f" is a "for [x] in range[y]" (exactly that, no other for's). Any "w" is a "while". Any "i" is an "if". Any "d" is a "def". Any "p" is a "print(" Nasty, nasty. (Also nasty is that the code snippets in the article has more comments than the github copy of the "readable" version. You need the article to understand what's going on.) This is a just a bit too simple for a "Tiny Python". If somebody is willing to allow a few more K's of bytes, I'd love to see at least lists & dicts here--Lisp can do them!

marcelo-earth

Reading the article, I can't believe I just found out Code Golf is a thing. I've been a programmer for more than a decade. But yes, amazing project! I like that it's human-made :)

ssfdg

I don't understand the point of this. If they wanted to make a Python interpreter, why didn't they just ask an AI to do it?

userbinator

To be precise this is 1024 bytes of C, which compiles to a binary many times larger, and implements a very tiny subset of Python. loops work by jumping backwards and reparsing the source each iteration This is how the DOS .bat processing works; not sure if Unix-style shells are the same, as I've never had the need to exploit that "feature". Another comment here has mentioned C4, but another extremely dense (and slightly larger, since it wasn't actually deliberately(!) "code-golfed") interpreter you may want to look at is the J Incunabulum: https://www.jsoftware.com/ioj/iojATW.htm More generally, the array programming culture seems to consider this level of density the norm: https://news.ycombinator.com/item?id=45800777

peter_d_sherman

The condensed version is impressive to be sure, but I'm an even bigger fan of the readable version: https://github.com/AZHenley/python1024/blob/main/python1024_... Well done!

andai

Also by the author: Let's make a teeny tiny compiler https://news.ycombinator.com/item?id=36102460

Semantic search powered by Rivestack pgvector
5,720 stories · 51,803 chunks indexed