[pypy-dev] Lessons From (Limited) Experience

[Christian Tismer]

Rocco Moretti wrote:
...

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

Very true.

...

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

It is one of my fears when rewriting Python in Python:
How often will I fail to recognize in which system I am?

There was a two-part TV film like "world at the wire"
in Germany, late 70's, where the level of simulation
also was not always clear :-)

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

It does seem so if you have to write that crap by hand.
When generating code, this is no issue at all.
I wasn't sure for myself about this problem.
Then I read Armin's long reply to everything,
and I found one thing of his generated-c-approach
appealing: Everything is turned back into generated
C, and there is no question about exceptions:
Surely they would be built like before.

Now, why do we have a problem with it in an interpiler
that does not create C code? I think we do lack experience.

...

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

This is most natural if you don't have a case construct.
If I ever whished to add such a thing, then for this project :-)

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

Absolutely, this can be done if it makes enough sense.

> How does that work with parameter/return value passing and potential
> psyco optimization? Don't know - didn't get that far.

After Armin's recent post, it seems to be true that Psyco will
get a complete rewrite, with a whole lot of new ideas.
Armin seems to be eager to try different object layouts as well,
with/without refcounts, with classical GC, ...,
so I believe the new, Python-based Pysco will be very capable.

> I might not make the sprint, but I'd be glad to help as I can,
> Rocco Moretti

There will be a second sprint, right before EuroPython.
At least, Guido proposed that, probably enough to
make it doubtlessly happen.

ciao - chris