On 9 December 2011 11:31, Armin Rigo <[email protected]> wrote: > Hi Martijn, > > On Thu, Dec 8, 2011 at 20:12, Martijn Faassen <[email protected]> > 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 > [email protected] > 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
_______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
