[Python-Dev] Prothon on CPython intrepreter? [PROTHON]
bac at OCF.Berkeley.EDU
Wed Aug 11 03:30:24 CEST 2004
Mark Hahn wrote:
> I'm sure you've heard the joke that ends with "we've established you're a
> whore, now we are just haggling over the price". If I can compromise
> Prothon for .Net, why can't I compromise it some more for CPython? So I am
> thinking of doing a Prothon implementation in CPython before doing the .Net
> version. I will get a library and community fast like I would have with
I am personally very glad to hear this!
> This CPython->.Net->CProthon roadmap will get Prothon out quickly and slowly
> easy my wild ideas for the interpreter into Prothon. It will also make
> CPython a multiple language VM for the first time.
> So, I'll finally get to some questions:
[SNIP - question for Guido]
> 2) Lenard Lindstrom said he thought I could "Add some extra byte code
> instructions to handle Prothon's distinct scoping rules and implement
> prototypes using PyType_Type".
That is definitely possible. If you look at the opcodes that currently
exist (http://www.python.org/dev/doc/devel/lib/bytecodes.html for the
in-dev docs; doesn't list LIST_APPEND or NOP, though ... Raymond, you
planning on documenting these, or should I file a bug report?), there
are opcodes for loading from locals, globals, names (when you don't know
which scope), and cells (closure stuff). Basically the opcode just
specifies where to look in the code object for the value. So yes, you
could emit another opcode if you needed to for scope and you made the
appropriate changes to the code object if you need other fields.
> He also said "All attribute accesses would be
> through a special attribute handler method". I don't know the Python
> interpreter code yet, but does this sound workable to everyone? It doesn't
> have to be Python compatible.
Well, all attribute access goes through descriptors already (if I
remember correctly from PyCON 2003's sprint). You could just change the
default descriptor to do what you want.
> 3) Could Tim Peter's welcome offer to Prothon here on Python-dev be
> stretched to include the many questions I would have when modifying CPython?
> In other words would this project be welcomed as a sandbox for Python or
> would it be an unwelcome drain on your limited resources?
=) You are are free to ask, just don't be floored if you are warnocked
on occasion (warnocking, since I have only heard this in the Perl world
form the perl-6-internals list, is when a message gets no response). I
personally have no issue and actually welcome the discussion since it
could help with improving CPython with new ideas. And this is coming
from someone who will have to read the emails. =) I know I am
personally willing to answer your questions.
I do have a piece of advice before you delve into this too deeply, and
that is to consider looking at the AST branch (tagged as ast-branch in
CVS). Jeremy Hylton has been leading a rewrite of the compiler to take
the concrete syntax tree, generate an AST for it, and then emit opcode
from that. It is *much* easier to use than how compile.c works now. It
also, in my opinion, makes things clearer by breaking up compilation
into more, smaller steps. It isn't in the main trunk yet, but it will
be someday (I personally plan to work on it once my thesis is done so
that I can hopefully integrate my work into the core more easily and it
is now tradition for some people to sprint on it at PyCON =) .
Who knows, you might be able to just generate your own version of the
AST or just have a different compiler for the AST itself and thus cut
down and code duplication.
More information about the Python-Dev