How is Python designed?

Diez B. Roggisch deetsNOSPAM at
Sat Dec 4 14:33:27 CET 2004


> The basic idea of this technique is to create a class
> to represent each type of script phrase(that's the
> term I used in the program, it's just a piece of code
> for particular task such assignment,logical/loop
> control,function call, whatever). In the phase of
> compiling, phrase instances of such classed are made,
> and in the execution phase, starting from the first,
> each phrase instance is executed and jump to the next
> phrase instance for subsequential execution,
> like a finite state automa I would say. Currently the
> interpretation efficiency is comparable to most
> popular interpreters.

I'd say that's pretty much standard interpreter technique - an expression
like this:

foo = a + b * c

is translated and reduced to an abstract-syntax-tree something like this:

Assignment("foo", BinaryOp("+", Get("a"), BinaryOp("*", Get("b"),

Then on Assignment one can invoke eval(), and get the result. Assignment
will invoke eval on its children, which in turn will do that for their
operands, until something can be computed. The result is returned.

By using an emulated stack or register-machine, you can flatten that to
something like this:

push Get("c")
push Get("b")
push BinaryOp("*")
push Get("a")
push BinaryOp("+")
pop  Assignment("foo")

This is of course very makeshift - but you'll get the idea.

This doesn't mean I want to discourage you - on the contraire. Developing
your own language is highly educating, and I personally love it when I
"invent" something and then later find out that people much cleverer than
me did so before - it shows that I went down the same paths of thought :)


Diez B. Roggisch

More information about the Python-list mailing list