[pypy-dev] python 2 and python 3 sharing an interpreter?

[Michael Foord]

On 9 December 2011 11:31, Armin Rigo <arigo at tunes.org> wrote:

> Hi Martijn,
>
> On Thu, Dec 8, 2011 at 20:12, Martijn Faassen <faassen at startifact.com>
> wrote:
> > Anyway, separate from the binding, I'm wondering about the challenge of
> two
> > Pythons in one runtime - how hard would it be to generate this with the
> > current PyPy? (imagining two different Python interpreters were
> available)
>
> Getting two completely separate interpreters in one process is trivial
> in PyPy, quite unlike CPython (blame C).  This works even with the GC
> (you get one for both) and the JIT (you get one JIT that can
> "meta-trace" starting from either interpreter).  That means that maybe
> PyPy is better than CPython as a starting point.  Of course someone
> still has a serious amount of work to do to integrate the two
> interpreters to the point where it becomes something more than, well,
> two unrelated interpreters in one process.
>
> [ More generally, you can translate several interpreters for different
> languages and getting a single unified JIT, capable of inlining across
> languages.  It is an interesting challenge that explores some unique
> benefits of PyPy --- worth a paper, most probably :-) ]
>


The .NET Dynamic Language Runtime does this for IronPython / IronRuby -
allowing multiple interpreters (for the same or different language engines)
in the same process. An object from one interpreter can be used by the
other, but retains its original semantics - so looking up attributes (or
any other operation) calls back into the interpreter that owns the object
to perform it. (This is a fundamental property of the way the DLR works, so
it mostly came for "free". It's also how a .NET string can behave as a
Python string for example.)

This allows IronPython and IronRuby to interoperate - but Ruby objects
retain their Ruby semantics  even when used from Python (and vice versa).
Resolver Systems used this a great deal for sharing objects between
multiple Python interpreters - all for the same version of Python of course
though.

IronPython doesn't have the particular problem with strings though - under
the hood all strings are .NET strings, but with different behaviour layered
on top. (Even Python 2 byte-strings are .NET Unicode strings under the
hood, with lots of magic to make that work.)

All the best,

Michael Foord


>
>
> A bientôt,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>



-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20111209/b0da36af/attachment.html>