How is Python designed?

Limin Fu fulimin_yuan at
Mon Dec 6 02:10:05 CET 2004


> Ok, thats clearer. This whole thing sounds familiar
> - the technique you
> describe seems to resemble continuation passing
> style. For a brief
> discussion read here:
> Python has a continuation-based interpreter
> implementation - its called
> "stackless python". Google for it. It certainly is
> interesting.

That's interesting. I heared of stackless pyton a few
days ago, I will have a more careful look at it. 

> And I don't see that the ast is more complicated, at
> least implementation
> wise - in fact, your method requires more analysis
> as  for each statement
> its pollible successors have to be computed and made
> known to it - where an
> ast node only knows about its children that more or
> less directly stem from
> the syntax analysis.

Not really. You think in this way, maybe because you
know more about AST and less about that technique I
mentioned. I thinked in the opposite
way because I know different things better. 

> I have to admit that I don't know if
> continuation-based evaluation has
> inherent performance-gains. The only thing I can
> think of is that you don't
> need a stackframe in some cases as tail-recursion -
> useful, but not so
> common that one would expect significant performance
> gains there. But as I
> said - I'm not on sure ground here.

I'm not sure either. Certainly it depends very much in
the implementation. If anybody want, we can make some
tests to check. I don't know if it's important,
because it seems people dosen't really care about the
efficiency of an interpreter (as long as it is not
really really too slow).

> Can you elaborate on what you consider beeing an
> unefficient recursive call
> and where there is a difference between your method
> of evaluation and the
> ast-evaluation I mentioned? After all, the
> ast-evaluation is a postorder
> traversal which has the same complexity of a depth
> first search - the only
> difference beeing the latter one using a fifo, the
> forme a lifo for
> managing the list of untraversed nodes. I don't see
> any difference here. 

Sorry maybe I didn't understand that part correctly
and took grant that it would be implemented in
recursive way. I just wondered if the following can be
extended for arbitrary length arithmetic expressions:
Assignment("foo", BinaryOp("+", Get("a"),
BinaryOp("*", Get("b"), Get("c"))))

> I don't have negative opinions about yuan and by no
> meants want to
> discourage you developing it. Its a nice project.

If I upseted you or anybody here by un-properly used
words, please forgive me. I always feel my english
must be improved :)

Best regards,


Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.

More information about the Python-list mailing list