[Python-Dev] Prothon on CPython intrepreter? [PROTHON] (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Wed Aug 11 03:30:24 CEST 2004

Mark Hahn wrote:

[SNIP]

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

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

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.

-Brett

More information about the Python-Dev mailing list