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!

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

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

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

Also by the author:

Let's make a teeny tiny compiler

https://news.ycombinator.com/item?id=36102460

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.

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.

This seems to be in the same spirit as Justine Tunney's SectorLISP. Very cool.

https://justine.lol/sectorlisp/

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

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!

I hate when they measure the size of source code instead of the size of a binary.

I appreciate .kkrieger much more than this monstrosity

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?

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

[dead]

[dead]

[dead]

tl;dr:

1. Choose a small fragment of the language

2. Adapt an existing interpreter

3. Use a tool to shorten the code, 'minify'

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?