Making a Python interpreter in 1024 bytes

I mean, obviously that one should only appear within Mongolian text and not within indentation.

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).

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!

> In what scenario would you ever need to use a sequence like in indentation in your source code?

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?

Indeed, for some code, CPython and this interpreter produce identical output. I gave it an upboat.

If you are willing to sacrifice performance, you can implement dicts via linear lookup in much less code than a proper hash table.