You would be correct according to Greenspun's 10th Rule: https://en.m.wikipedia.org/wiki/Greenspun's_tenth_rule

Yep. I also got really excited thinking this is homoiconic python I might be able to make my coworkers use (without having them buy into lisp). But no, it's just lisp.

You may want to take a look at Rhombus, that is a somewhat-python-like language with macros that is written in Racket.

> Rhombus is an experimental, general-purpose programming language with conventional expression syntax that is built on Racket and that is macro-extensible in the same way as Racket.

It's still work in progress, but you can install and run the prototype. I recomend to take a look at the "demo" file with examples https://github.com/racket/rhombus-prototype/blob/master/demo...

Or read the docs https://docs.racket-lang.org/rhombus/index.html , in particular an overwiew in https://docs.racket-lang.org/rhombus/Modules.html and some examples of macros in https://docs.racket-lang.org/rhombus/expr-macro.html .

Looks like it. I was curious to witness this homoiconic Python but I'm not sure it's even possible. For that to be true, Python syntax would have to be made out of tuples, lists or dictionaries, and the interpreter would have to evaluate those directly.

What is the difference?

The whole point of homoiconicity is that a language (lisp) is implemented in itself. This is lisp implemented in python (not itself).

I thought the point of homoiconicity was essentially runtime reflection and evaluation of programs constructed at runtime, i.e. code is a first class datatype in the language.

I don't think these properties imply much about the underlying implementation of the language.