Making a Python interpreter in 1024 bytes
austinhenley.com
austinhenley.com
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!
(Slightly less silly: the folks at https://github.com/faster-cpython are doing great work, too.)
Because of that it wouldn’t surprise me much if that sped up some standard benchmarks, for example ones parsing lots of small json objects into dictionaries.
The way Python guarantees to preserve insertion order is pretty clever and doesn't really cost you much at runtime. They pretty much only added this guarantee because it was basically free to offer given the implementation choices they already wanted to make for other reasons.
Yes, but that is almost free for the first insert and need not be much work for the second and third. Also, that naive implementation will use less memory.
The kind of benchmark I was thinking of are the “large_random” and “Kostyra” ones from https://github.com/simdjson/json_benchmark_results that parse arrays of small objects with very short keys.
For such objects, as I said, it wouldn’t surprise me _much_ if the extremely naive implementation were faster.
Clearly supporting multiple functions starting with 'p' would be overengineering.
Meaning that something as simple as "w = 4" would fail? A little too nasty for my liking. Not a choice I would have made, but admire the amount of work done here and the readability of the article. And it's more human-written code than I've done in a number of months!
But yes, amazing project! I like that it's human-made :)
I love feelings of inadequacy at 11:07pm on a Sunday.
Here's the judges' remarks and author commentary on the second edition of this from the 2006 results: https://www.ioccc.org/2006/sloane/index.html
> it’s worked on every system I’ve tried so far though
Still my favorite part of the whole thing. Classic moment of “who among us hasn’t doesn’t this?” lol
https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
Also https://github.com/nanochess
And then if you really want to go large
https://phoboslab.org/log/2021/09/q1k3-making-of
I still have a soft spot for https://www.pouet.net/prod.php?which=1221
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://github.com/AZHenley/python1024/blob/main/python1024_...
Well done!
As implementer of an interpreter, did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?
<space><space><tab><space>
is different than
<space><tab><space><space>
So you also have to track the actual sequence of counts of white space used for each level, rather than just a simple count.
How so? In what scenario would you ever need to use a sequence like <tab><space><tab> in indentation in your source code? Let alone using esoteric Unicode whitespace characters for indentation. I think it is perfectly reasonable for the language to make the restriction that indentation must be either all tabs, tabs followed by spaces, or all spaces.
Writing a lisp in an editor that doesn't do boneheaded things with tabs? That's the only one I've personally run into but lack of imagination is hardly a good excuse to implement arbitrary restrictions.
> Let alone using esoteric Unicode whitespace characters for indentation.
How do you know what's esoteric in other countries? I certainly don't. I'm not an expert in linguistics but I'm sure that people everywhere in the world write computer programs at this point.
> I think it is perfectly reasonable ...
Without any concrete justification? Why would entirely artificial restrictions ever be seen as reasonable?
As far as I'm aware there are three primary and entirely independent uses for tabs. Indentation, field separation, and typesetting. When it comes to typesetting and also to display of fields with a narrow maximum width the concept of a tabstop is useful.
Boneheaded things with tabs was in reference to code editors (where tabs are more or less exclusively used for indentation) most often failing to provide the ability to disable tabstop. In practice this generally hasn't been a point of friction because until fairly recently the most popular languages (ie C & co) didn't support constructs that would lead to adding any indentation outside of the prefix of a line.
So even though in most cases those three uses for tabs are independent, in some languages they get muddled. F# is another language where you may want to align text on line two with the middle of line one, e.g. if you write
let person = { FirstName = "Bill"
LastName = "Gates" }
(Those two links point to different anchors in the same document, BTW: the HN link shortening is going to make them look identical until you hover over them).
var result = someObject.SomeMethod(param1, param2,
param3, param4);
var result = someObject.SomeMethod(param1, param2,
<tab><tab><tab><tab><tab><tab><tab>param3, param4);
I know not to do that. The editor did it anyway, and if I hadn't been paying close attention to whitespace I might not have caught it.
The editor could have been smart enough to parse the code into an AST, notice that param3 and param4 were part of a parameter group, and said "I will use tab characters equal to the indentation of `var result`, then spaces thereafter". It didn't. I had to edit the call to look like this:
var result = someObject.SomeMethod(
param1, param2, param3, param4
);
If my memory is right about which office I was working in when I saw the editor do that to my code, then it was more than a decade ago, probably around 2010 or 2011. It's possible that the modern version of that editor has improved its handling, and would have correctly aligned param3 with spaces. I haven't checked recently. Maybe at some point I will, and report my findings.
To state explicitly what should be implicitly obvious, there is no valid reason (that I'm aware of, I welcome any non-facetious correction) to use any character except U+0009 and U+0020 within indentation. Horizontal Record Separator? Zero-width joiner? Language-specific whitespace characters like your example? All make sense within human text (well, maybe not HRS), but in programming, they should be eschewed in favor of the characters that can be typed in every single keyboard layout in the world. Even languages that don't put spaces between words, such as Thai, still put spaces between sentences (or comma phrases) and therefore keep the space bar in their keyboard layout.
And since mixing tabs and spaces (even between lines, where some lines are tab-indented and some are space-indented) creates problems for whitespace-sensitive language, there's a reason why every whitespace-sensitive language I'm aware of has tended to either outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations, which are usually not available to the validation code running in CI or on other people's machines).
There doesn't need to be an articulable reason. Or rather there's generally no expectation that a central authority will be able to reliably enumerate such. Everything should default to being permitted and only ever be restricted for good reason.
But since you asked. U+2003 for example carries formatting information. Maybe an editor could be written (or even already exists) that would find that useful. Who is any third party to dictate that?
U+00A0 similarly communicates information about the desired formatting and I can see no reason it would be unreasonable for someone to use it nor why its use should pose a technical challenge to a compiler.
> creates problems for whitespace-sensitive langauge
Does it? That seems like an invented problem to me. You have a running prefix composed of arbitrary whitespace characters. Any change in that prefix is a change in the level of indentation. You can add or remove arbitrary amounts from the end of the prefix. In the event you remove from it the result must exactly match the previous stack level. What's so complicated about this?
> outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations ...
Did you mix up your code points there? It's space that's ambiguous, not tab.
Regardless I think that a compiler worrying about the specifics of text editors or other tooling would be backward information flow and a massive abstraction violation. Semantic meaning is entirely dictated by the compiler, not the other way around. There's no convincing reason (IMO) to impose restrictions that aren't technically necessary or to otherwise needlessly employ solutions that would reduce generalization.
Space is always the same width, but tab means a variable number of spaces (usually either 4 or 8, but I've seen 3 before) depending on people's editor configuration.
What makes you say that the space character, U+0020, is ambiguous?
Tab never "means" any number of spaces. How it gets displayed varies but the meaning (of any character, not just tab) can only ever be determined by usage, not display choices (at least for any sane way of doing things). Otherwise what would you make of escape sequences or binary files? Or constructs such as a nonbreaking space?
What business does a compiler have worrying about display width? As I said earlier worrying about the specifics of the editor or other tooling would be backwards information flow and a massive abstraction violation. What if I choose to program in a variable width font? (For the record writing that left me feeling disgusted.)
> What business does a compiler have worrying about display width?
The business of the compiler is to insure that code that it deems acceptable is not ambiguous to different users. Since people can set their own tab spacing, display of tabs is, in an indentation-sensitive language, inherently ambiguous.
> What if I choose to program in a variable width font?
As long as the spacing of any prepended whitespace doesn't arbitrarily change depending on the phase of the moon, the compiler shouldn't (and Python doesn't) give a rat's ass about your display preferences.
The only important thing here is that the location of the left margin on every line is meaningful, both to the compiler, and to any viewers of your code.
Not for code, no. People will do that for spaces. For tabs it's a 1:1 correspondence with indentation level with any visual adjustments done by the editor.
Reading between the lines I suspect you are operating with the flawed idea of using tabs for alignment. One must never use tabs for alignment purposes because they very explicitly do not have a fixed width. (They have a consistent width within a document at any given point in time but it is entirely arbitrary and can change at any time.)
> insure that code that it deems acceptable is not ambiguous to different users ... display of tabs
A compiler never has any control over display. It must ensure no _semantic_ ambiguity. And indeed there isn't any to be found here. Even in python where you can introduce an arbitrary amount of whitespace when going up a level of indentation there is never any semantic ambiguity.
In short you are confused about the division of labor within the stack of abstractions.
> The only important thing here is that the location of the left margin on every line is meaningful, both to the compiler, and to any viewers of your code.
I'd dispute that the compiler needs to care about where your editor places the left margin. However rather than argue about bizarre hypothetical text editors that do unhinged things when displaying whitespace for no apparent reason, I'll instead observe that it seems to follow from what you said that you actually agree with me. As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.
No, I vehemently disagree with most of what you wrote. We certainly agree on basic things that tabs do not have a fixed width, and that a "compiler never has any control over (source code) display." (What a bizarre idea; whoever said it did?)
> I'd dispute that the compiler needs to care about where your editor places the left margin.
This isn't just about editors. I well remember green-bar.
> As long as the prefix remains consistent across a given level of indentation then there's no cause for concern.
No, if someone uses 8 character tabs, and then wants to space over half a tab for visual reasons, things completely break. We probably agree that's wrong, and that the answer is some variant of the answer to "Doc, it hurts when I do this" and I maintain the answer is to dispense with tabs completely.
Look the tabs-vs-spaces war is as old as the big-endian/little-endian war, and I am probably older than you. We'll probably never convince each other of any of this. Have a good day.
BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.
EDIT to add this P.S.: Figured it out. I eventually came across https://elpa.gnu.org/packages/greenbar.html which mentioned the alternating white and green bands of color on old printer paper. I remember those, but I never heard them called "green-bar" which is why I couldn't place the term.
> BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.
I had to go back and look. You obviously have more patience than I do for this sort of debate. :-)
I don't think people who fall down on the tab side of the debate have thought things through. Tabs are about alignment, of course, but why did we transport the typewriter alignment to printers? (Many printers had escape sequences that let you set the tab spacing.) Arguably, it was to save computation time, storage space, data transmission time, and even (for faster printers) to make your print job come out faster. People forget how precious all those were.
Today, a tab key on a keyboard is a perfectly cromulent method to get to your next alignment boundary, but there's a reason that every single usable code editor lets you program the tab key to emit a certain number of spaces.
In other words, don't take my not knowing a term as evidence that it wasn't commonly used; my childhood was unusual by the standards of most Americans. :-)
But there are other cases where the variable-width nature of tabs can create ambiguity all by itself. Take this example from R7RS small:
(cond ((> 3 3) ’greater)
((< 3 3) ’less)
(else ’equal))
(cond ((> 3 3) ’greater)
<tab>((< 3 3) ’less)
<tab>(else ’equal))
Here, the ambiguity is because the tab character needs to have a width of six characters in order to align with the text `(cond `. If that had been an `(if ` with just two forms (omitting the `(else 'equal)` case) then the tab would have needed to have a width of four characters. A smart editor that reads the Lisp code and can interpret `<tab>` as meaning "indent this form to align with the form on the line above", but any context that isn't syntax-aware, such as a git diff, will not align those tabs correctly.
Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.
I don't think so? Assuming we're talking about significant whitespace here and assuming we're maintaining a consistent prefix within a given block then AFAICT there is never any ambiguity. To argue otherwise it seems to me that one of two things must be true.
It could be that spaces are equally ambiguous because in theory you can use any number of either of them for a single level of indentation. While that isn't syntactically ambiguous I suppose it might bother some people.
Or it could be that the compiler is concerning itself with how different editors might choose to display a given line of text in different instances which is (IMO) fundamentally broken and a path down which only madness lies (and anyway suffers from the variable width font conundrum I pointed out earlier).
If you have any counterexamples I'd be interested to see them.
> But to everyone else using a different editor, where the convention is "the tab character just advances to the next multiple of T" (where T is usually 4 or 8), then the second and third lines won't be correctly aligned.
No, you've got a misconception here. An editor should never go out of its way to align that. That would be broken by design. Tabs are never for alignment. Never. Notice that syntactically no new scope has been introduced. So you are still at the same indentation level as the `cond` and you are aligning (thus you _must_ use spaces) a list of expressions that has been split one per line.
I think the entire controversy arises because people (incorrectly IMO) get the idea in their heads that a tab character has some fixed width. It does not. In the context of source code it communicates the concept of indentation, never anything more. It's entirely up to the editor how exactly to display indented code.
> Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.
Right, but that is in my view misguided and anyhow is not of any concern to the compiler. Recall that the original topic and my contention had to do with the possibility of syntactic ambiguity in a language with significant whitespace, not with formatting inconsistencies between different programmers.
def example():
<tab>if True:
<tab><tab>do_something()
def example():
<tab>if True:
<tab><tab>do_something()
do_something_else()
def example():
if True:
do_something()
do_something_else()
The use of .editorconfig files should, in theory, solve this. But just yesterday I had another file, thankfully one where whitespace was not significant. The .editorconfig file said "Indent with tab characters", so my editor, when I opened a new line, indented it with tab characters. But the file was actually indented with spaces, and nobody had fixed the .editorconfig file to say "indent with tab characters... except for this file which is indented with spaces".
Editor misconfiguration in both cases. Not strictly the couterexamples you were asking about. But the Python example, although made up, is reflective of actual situations I've seen. People with different editors editing a file, not paying attention to whitespace, and ending up with ambiguity where the width of a tab character would actually make a difference to whether a line visually appears lined up with its indentation block or a different one.
Tabs are great for indentation in theory. In practice, I've personally seen more pain than gain from files that used them.
Besides, I'm sure many people would look at your Scheme snippet and argue that it's not really about indentation as much as alignment of the subforms, because in a Lisp those two things are basically equivalent, and that the distinction between indentation and alignment is mostly a thing for the curly-brace or otherwise ALGOL-esque languages like Pascal or in this case Python. And in those cases the use of "tabs for indentation, spaces for alignment" is fairly popular although I don't frankly know if many editors actually support that.
I do however think that this whole discussion of spaces Vs tabs is pretty asinine and mostly just stems from people just wanting to align code text visually across lines. It's the same way people insist on monospaced fonts even though one could easily make the argument that proportional fonts are easier to read. Oh well, even I'm not _that_ deprived.
It all works swimmingly until you introduce a nested scope (indentation, tabs) in the middle of an aligned scope (spaces). At that point it still works in the sense that everything is correctly aligned however depending on the editor the tabs might not all have the same width if you aren't able to disable tabstop.
So it isn't generally recommended for lisps in practice (because most common editors will correctly align any given block but when considered in whole the formatting will be inconsistent) but poses near zero problems for most c like languages. (If you're determined you can manage to create problems in a c like by nesting an anonymous lambda within an aligned list of statements or similar such shenanigans. However pretending that python or c++ is a lisp is generally frowned upon so in practice all tabs can be expected to appear to the left of any spaces.)
That was one of the moments that made me move away from tab characters in all circumstances. Because the only way to prevent that sort of thing from happening would be either to fix the editor bug (which I don't have time to do), or to turn on visible whitespace and pay close attention to whitespace every time I make an indentation change, knowing that the editor will sometimes do the wrong thing. I don't want to have to pay close attention to whitespace, and the only way I've found not to have to pay close attention is to either never align things at all, or never use tab characters. Tabs for indentation and spaces for alignment works great in theory, but in practice I have found I can't trust major editors to handle it right.
(Until now, I went with the standard approach: Remember the leading whitespace of the previous line. Then compare with the new line's leading whitespace: If they are the same, then no change in indentation. If the old one is a prefix of the new one, it's an indent. If the new one is a prefix of the old one, it's a dedent. If neither, it's an error)
So your proposed prefix-matching rule would correctly flag that scenario, forcing people stop and figure it out.
EDIT to add this P.S.: Actually, my "spaces may follow a tab but tabs may not follow a space" rule, while elegant, is incomplete. Your prefix-matching rule is actually necessary in order to deal with the "two tabs on one line, twelve spaces on the next line" situation. That would be legal under the "spaces may follow a tab but tabs may not follow a space" rule, but it's ambiguous whether that's an indent or a dedent. If tabs mean eight spaces then it's going from 16 to 12, a dedent; if tabs mean four spaces then it's going from 8 to 12, an indent.
in my view, both are the same, both `is` (or ===) an IndentationError raise
Doesn't affect function call stacks though.
Uhhh, no. Sure, it's posited by people who feel they are are forced to use it, but it's basically unlearning other syntax.
Here's a study about people with no experience. They do better with python:
https://www.researchgate.net/publication/262256894_An_Empiri...
When the scala language made whitespace optional, it was very divisive, but now it's extremely well accepted.
After that experience Python code is like eye-bleach to me.
Significant indentation requires a more complex lexer because it means the lexical grammar is no longer regular. The lexer can't just be a finite state machine, instead it has to maintain a stack of previous indentation levels.
But I don't think many modern languages have a regular lexical grammar anyway. Without significant indentation, some other features still require the lexer to maintain a stack - e.g. string interpolation (Python's f-strings).
Let's make a teeny tiny compiler
https://github.com/xorvoid/sectorc
Edit: I wonder if sectorC could compile python1024
I'm talking about things like SectorLisp https://justine.lol/sectorlisp/
The exception to this is obviously embedded systems with very low amounts of resources where C and assembly are practically unrivaled.
This was standard practice on interpreters for 8-bit microcomputers; with only a 64K total address space, creating an AST first seems immensely wasteful, so you interpret from the source directly.
I believe shells still do this when you run shell scripts; I know the DOS COMMAND.COM definitely does.
This is not Python, or even within three orders of magnitude of Python.
One could imagine an even smaller subset interpreter. It's an interpreter for a subset of Python, consisting only of the programs that print "Hello World". Since it doesn't do any error checking, for all other programs the output is undefined. Implementing it is very simple: Just ignore the input file, and print "Hello World". As a bonus, it's an interpreter for the subset of "Hello World" programs in all other programming languages too!
</tongue-in-cheek>
https://esolangs.org/wiki/Hello
While quines (programs that print their own source code) aren't possible in Hello, there's a version that makes it possible:
https://esolangs.org/wiki/Hello_Plus_Plus
And if you say the original isn't good enough because it can't do anything else... well, esolangs have you covered there too:
https://esolangs.org/wiki/HQ9_Plus
(It should be noted that these are all joke esolangs. There are actual languages on the wiki that are very interesting though - I would definitely recommend you take them out!)
I obviously meant "check them out" here. I was using speech recognition and it clearly misheard what I said.
I'd edit, but it's been long enough since I posted that HN isn't offering that option for this comment any more.
For instance this program works in this interpreter, but not in python:
fxx i in rxxxx(10):
pxxxx(i)>> I started with the most basic code I could think of: 1 + 2
OK, how did you fit that into 512/1024 bytes??? Did you try print(3 * * 1000)?
That said, if I was building a small ugly toy Python implementation, I would probably also not implement long integers. Or the power operator. At least not in the first iteration.
I appreciate .kkrieger much more than this monstrosity
1. Choose a small fragment of the language
2. Adapt an existing interpreter
3. Use a tool to shorten the code, 'minify'
Like a psychopath.
/s
"Things won are done; joy’s soul lies in the doing." - Troilus and Cressida
Probably curiosity.
If there's an AI version of code golfing, I'd be curious to see it. Maybe they golf worse or much better than us meat bags.