Re: Re: Re: Python parser

I am afraid I cannot give a well researched answer right now, so I will
just give a quick reply.

On Sun, 8 Aug 2004 20:04:55 -0700 Mark Hahn <[email protected]> wrote:

> On Sun, 8 Aug 2004 19:24:37 -0700 (Pacific Daylight Time), Lenard Lindstrom
> wrote:
> 
> >> When I looked at running CPython's libraries with Prothon earlier this year
> >> it didn't look good.  The Python libraries were too tightly wrapped around
> >> the Python language.  The CPython VM was not written to support multiple
> >> languages as the CLR is.  Python extensions expect to be able to have any
> >> and all of Python available at all times.
> >> 
> >> The best I could do would be to have the CPython interpreter running
> >> embedded inside my Prothon interpreter and bridging calls from Prothon over
> >> to Python.  This would not be efficient as it would require both VMs to run
> >> side by side.  There would also be the overhead of translating between the
> >> two.  Threads would not be supported.  I pretty much gave up on the idea.
> >> 
> > Just some speculation. Does not the Stackless Python interpreter come close
> > to the CProthon implementation? 
> 
> Stackless has an interpreter?  Is it just CPython with the stackless patch
> installed?
>
I have not seen the source code but I assume the interpreter loop has been
significantly rewritten. Other parts are probably unchanged.
 
> > Add some extra byte code instructions to
> > handle Prothon's distinct scoping rules and implement prototypes using
> > PyType_Type. Could object locking be done by the object itself? All attribute
> > accesses would be through a special attribute handler method. And Prothon's
> > one pass compiler could still be used. So now you have a virtual machine
> > that handles both languages, no dual interpreters.
> 
> You know more about this than me.  Answer a few questions:
> 
> 1) Does stackles offer preemptive threading?
>
I had forgotten about the dreaded GIL. I assume Stackless still uses it
to allow it to run with extension modules compiled for cPython. I have not
studied how Prothon handles concurrency within the interpreter loop, but
maybe this could be carried over to Stackless. If one accepted that Python
extension modules would have to be recompiled to work with Prothon then maybe
a dummy GIL could be made available.

> 2) Would this scheme allow me to use totally different object templates?
> 
I am not sure what exactly is meant by template. But certainly a Prothon prototype
could be created as a Python extension type. The major interpreter addition required
to support it is a method call that handles the self scope.

> 3) Wouldn't the C extensions expect all the normal Python objects to be
> there?
> 
Yes. But classic and new-style classes should be able to co-exist with prototypes.
The trick would be how to bridge the builtin types, python long and Prothon Long, etc.
Possibly wrapper objects could do this. Or an object's Python behaviour could be
defined by its PyType_Type - class - while its Prothon behaviour is defined by its
methods and prototypes. Any well behaved extension module should access external
objects through the Python api, so as long as that works as expected the exact
implementation of the object should not matter.

Of course this is all conjecture. The cPython interpreter is written in modular
fashion so changes to one part are generally hidden from others, barring certain
optimizations. For instance, it may even be possible to eliminate reference counting
and have Prothon's garbage collector instead. But to confirm this will take a little
more time than I can devote at the moment.

Lenard Lindstrom
<[email protected]>