I like the idea. In fact, after reading the psyco website, I started something like it myself in October. The answer to the question that is on everybody's minds? PyPython. (I envisioned it as potentially being the springboard for other versions: AdaPython, LispPython, etc.) Additionally, the goal was to make a clear and readable implementation of Python which people could study and play with, without requiring them to know C. My plan was "simply" to take the CPython code and convert it into Python code, minimizing the use of "high level" features like lambda, generators, etc., so that a small core could easily be hand compiled into the language du jour. Eventually, a reduced dialect of Python might be employed for the core (interpreter loop and basic objects) such that a simple compiler could be built for it. My greatest ally was my biggest enemy. To make things easier in development, I used close association of my program with the host system. This way I could defer converting the compiler and core objects untill later. Unfortunately, it was *extremely* unclear where PyPython ended and the host system began. In my final incarnation, the PyPython objects with external visibility were referenced from a global definition file (a'la python.h), where they were simply imported wholesale from __builtins__. But the problem which stymied me was the issue of what to do with Exceptions. I discarded the concept of copying the "return Null" technique of CPython - having to check every return value for an error condition seems so unpythonic. But raising native exceptions has the complication of discriminating between exceptions in the host system (or rather the PyPython code) and the end user interpreted code. I might have been able to do something with it if I could have created my own traceback objects from within Python. (That was my greatest frustration - the inability to create and modify core objects [frame, thread, traceback, etc.] from within python itself.) That's where I left it in December when I stopped for Christmas. (Don't bother to ask for code: most of what I wrote was dead ends or "mindless conversion" from C.) I agree with using cross compilers in the bootstrap proceedure and with being "stackless" - two features I was going to apply. One additional thing that came about as a direct result of Python's lack of a switch statement: I replaced the switch statement with an array of references to functions implementing the opcodes. (I was going for clarity over speed) One offshoot of this is the potential to have multiple opcode schemes in the same interpreter. (Like Python 1.5.2 and Python 2.2 - or better yet, Python and Java) How does that work with parameter/return value passing and potential psyco optimization? Don't know - didn't get that far. I might not make the sprint, but I'd be glad to help as I can, Rocco Moretti P.S. I would advise for some brave soul (more reliable than me) to start summaries of pypy-dev, like has been done recently for python-dev. It would be nice to have a record of all the major design considerations in a location which doesn't require several hours of sorting through fluff. __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/