Glonce

A Python interpreter squeezed into 1024 bytes of C

miscThe Glonce editorsHacker News🔥60Glonce rating60Impact25Novelty42Relevance62Surprise68Players12Credibility85
A Python interpreter squeezed into 1024 bytes of C

A developer set out to write a Python interpreter in as little C source code as possible, with a self-imposed limit of 1024 bytes and a rule against macro tricks or outside libraries. The target subset had to look unmistakably like Python: def for functions, colons, indentation-based blocks, and no parentheses around if conditions. A FizzBuzz program is used throughout the post to show the interpreter actually running, including for loops, nested if/else, and print.

The implementation skips the pipeline a real Python runs through (tokenize, parse to an abstract syntax tree, optimize, emit bytecode, then interpret the bytecode). Instead it is a recursive-descent parser that executes code as it parses. All state lives in a handful of global variables: a 999-byte array holding the source with most whitespace stripped out, a 256-entry array used as the symbol table, and a few counters tracking the current position and character. Variable names are restricted to a single lowercase letter, which lets the interpreter use a variable's character code as a direct index into the symbol table instead of doing a real lookup. Loops are not compiled at all: the interpreter remembers where a loop's condition starts in the source and jumps back to reparse and re-execute it on every iteration. Functions work the same way, jumping to and from a remembered source position on each call and relying on the C program's own call stack to handle recursion. There is no error handling: the interpreter assumes keywords are spelled correctly and that token boundaries are where it expects them to be.

After getting a working version, the readable source ran to over 4800 bytes. Shrinking it relied on C code-golf tricks pulled from an old Stack Overflow thread on golfing in C, some of them dependent on GNU C89-specific behavior: using ASCII arithmetic instead of named comparisons, chaining logic with && instead of if statements, and folding statement sequences into function arguments to save characters. One function that skips to the end of a line was reduced to Y(){c&&c-10&&Y(G());}. After applying these techniques throughout, the finished interpreter came in at exactly 1024 bytes. The author estimates that dropping comparison expressions and targeting FizzBuzz alone could push the size below 800 bytes. Both the readable and the golfed versions of the source are published on GitHub, and the author says there are no plans for another code-golf challenge in the near future, closing with an open challenge to readers to try their own 1024-byte Python.

Key facts

  • A working Python-subset interpreter was golfed from a readable C source of over 4800 bytes down to exactly 1024 bytes.
  • It runs a demonstrated FizzBuzz program using def, for/while loops, parenthesis-free if/else, and print.
  • Variable names are limited to a single lowercase character so a 256-entry array can be indexed directly by character code as the symbol table.
  • There is no compilation step: loops and functions work by jumping back to a remembered source position and reparsing, with functions relying on the C call stack for recursion.
  • The interpreter has no error handling at all and assumes the input code is correctly formed; the golfing techniques came from a Stack Overflow thread on golfing in C.

Why it matters

It is a demonstration of how far a language's syntax can be faked with a minimal, uncompiled recursive-descent parser: no tokenizer, no AST, no bytecode, just direct execution while parsing, and the source still fits in a kilobyte once golfed. It also shows a specific set of C code-golf techniques (ASCII-based comparisons, && chaining, GNU C89 quirks) applied end to end on a real, working program rather than a toy snippet.

Who it affects

This is a hobbyist and educational exercise, not a tool aimed at end users. It will interest people curious about how parsers and interpreters work under the hood, and readers of code-golf and language-implementation write-ups; it is not something application developers would adopt.

How to use it

Both the readable version and the final 1024-byte golfed version of the source are published on GitHub, so the code can be read, run, or picked apart to see how each technique reduced its size. The article does not give a specific link or repository name.

How solid is it

The claims rest on the author's own account of the project, and the 1024-byte figure for the finished interpreter is stated directly in the post. The only functionality shown running end to end is the FizzBuzz example; the text does not describe testing against any broader Python test suite.

Risks and caveats

This is explicitly not a usable Python implementation: variable names are limited to a single lowercase letter, a large part of the language is left out, and there is no error handling, so malformed input has undefined behavior. Several of the golfing techniques depend on GNU C89-specific behavior rather than standard, portable C.

“There is no error handling of any kind! It makes a lot of assumptions based on the correctness of the code.”

— the author