[pypy-dev] Summer of PyPy pre-proposal
arigo at tunes.org
Sat Aug 12 10:45:31 CEST 2006
On Fri, Aug 11, 2006 at 06:59:00PM -0300, Leonardo Santagada wrote:
> I would like to enter Summer of Pypy with my proposal to make a
> and they thought it was a good idea.
Nice plan :-)
> So I checked the code and started
> looking at what should/can do on 2 months of work ( I don't know if
> there is this limitation on time).
Not necessarily, but the proposal should have a timeline and your
calendar should allow you to put "reasonable" amounts of work on it.
> I am a litle lost with all the code
> from pypy and the idea of making another interpreter so I am posting
> here my ideas and I am specting your feedback.
> do simple direct interpretation of the source?
I'm not completely clear about the difference between a simple direct
where the main work is in getting the execution model and the object
model right. For the object model I mean building the Python classes
[[Class]] internal property -- with all the other internal properties
and methods; and then making the pre-built objects and prototypes and
functions. It's ok to leave out some parts of the library of pre-built
objects for the Summer of PyPy's duration. (This part corresponds to
PyPy's "object spaces".)
For the execution model, as you note, you need to start with an
interpreter. It would interpret bytecodes that you are free to invent;
(What I mean by execution model also includes things like function and
method calls, and how to fit built-in functions.) (This part is
documented under the name "bytecode interpreter" in PyPy.)
> Should I use the parser defined on pyparsing (this one seems really
> nice) or write one manually?
I'm not sure about this. Our tokenizer and parser are definitely meant
to be reusable, but I'm not exactly sure how :-/ I think there is a way
to recompile the tables in pytokenize.py. The parser loads a grammar
dynamically, so that's simpler. My 2 cents, though, is that you don't
produces some data that is easy to feed to Python, it would be a good
start. (Ultimately, we really need a parser written in RPython, but
it's ok to leave this out of the Summer of PyPy proposal.)
More information about the Pypy-dev