Hi, 2012/6/4 Armin Rigo <ar...@tunes.org>
> Hi Martijn, hi Holger, > > On 6/1/12, Martijn Faassen <faas...@startifact.com> wrote: > > Concerning performance overhead of proxies, lifecycle issues would be > > tricky > > If, hypothetically speaking, there is someone interested in writing a > PyPy solution where both a Python2 and a Python3 interpreter are > running in the same process, then you gain the advantage of having > only one GC to run both. At least it transparently solves the issues > of lifetime and reference cycles. (You also have for free only one > JIT, which can do cross-language optimizations like inlining a Python2 > function into a Python3 context or vice-versa). I see these two > points as benefits that you don't have in any multi-process solution. > > It would require some work on the PyPy side, and I'm not aware of > anybody ready to invest time in that, but it shouldn't be particularly > hard (once PyPy's Python3 interpreter is ready, and once people agree > about which API to use to do cross-language calls.) > I did some experiments a few months ago, trying to embed two 2.7 interpreters in the same translation target (which could have slightly different options, say with/without rope strings). I stopped when I realized that it cannot work with a single pypy tree: if space.get_name() returns a RPython string in 2.7, it cannot return a RPython unicode in 3.2; and even then, the MethodOfFrozenPBCRepr class "assumes that all methods are the same function bound to different PBCs". Maybe we should retry with different pypy trees (i.e pypy/interpreter/ vs. pypy3k/interpreter/, and so on) But I'm sure we would like some objects to be compatible, for example PyFrame2.f_backref could be a PyFrame3. -- Amaury Forgeot d'Arc
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
