Making a Python interpreter in 1024 bytes

Original Article ↗ Hacker News Discussion ↗

A 1,024‑byte C “Python interpreter” that runs a tiny, carefully chosen subset of Python prompts debate over what really counts as implementing a language versus merely mimicking its surface syntax. Commenters explore the trade-offs behind extreme code golf: omitting error checking, restricting features, and re-parsing source to save bytes, while comparing this project to minimalist systems like SectorLISP, Tiny BASIC, and embedded languages such as Snek. Much of the conversation centers on how indentation-sensitive syntax, tab/space handling, and tooling constraints complicate both language design and real-world maintainability, even in toy interpreters.

Whitespace, Tabs vs Spaces, and Indentation Semantics

  • Large subthread debates whether Python-style significant indentation truly complicates lexing.
  • One view: indentation forces a non-regular lexical grammar and a stack of indentation levels, but this is manageable and comparable to complexity introduced by other features (e.g., string interpolation).
  • Big argument around tabs vs spaces:
    • Some argue for strict rules (no mixing, or “tabs then spaces but never spaces then tabs”) and treating odd patterns as errors.
    • Others push back that such constraints are arbitrary, culturally biased (re: Unicode whitespace), and not technically necessary if indentation is modeled as “prefix strings on a stack.”
  • Several concrete failure cases are discussed: mixed tabs/spaces across editors, editors auto-aligning with tabs, and the ambiguity between indentation vs alignment in Lisp- or F#-style code.
  • General split: “tabs for indentation only, spaces for alignment” vs “just ban tabs and use spaces to avoid tooling bugs.”

Scope and Nature of the 1024-Byte Interpreter

  • Multiple commenters stress this is a tiny, highly simplified, and error-fragile Python-like subset, not a real Python implementation.
  • It pattern-matches single characters for control structures (any “f” as for, any “p” as print, etc.), so very non-Python syntax will still “run.”
  • Some consider this too “nasty” or misleading; others accept it as in-bounds for a deliberately golfed toy.

Implementation Tricks and Constraints

  • Loops work by jumping back and reparsing source each iteration, reminiscent of early BASIC or DOS batch interpreters.
  • The interpreter operates directly on source text instead of building an AST, matching old 8-bit interpreter techniques.
  • Error checking is largely removed to hit the byte budget; some call this “cheating” since correctness then relies on the human author.

Related Projects and Historical Context

  • Commenters link and compare to SectorLISP, SectorC, Snek, Forth, J’s tiny interpreter, and Tiny BASIC / old Microsoft BASICs and Turbo Pascal, noting how much used to fit in a few kilobytes.

Perceived Value and Motivation

  • Many praise the writeup, readability of the expanded version, and the joy/curiosity of code golf and sizecoding.
  • Skeptics question practical utility, argue that binary size would be a more honest metric, or suggest just asking an AI to produce such code, while others defend “doing it by hand” as the entire point.