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

[Alex Gaynor]

On Thu, Dec 8, 2011 at 5:16 AM, Martijn Faassen <faassen at startifact.com>wrote:

> Hi PyPy folks,
>
> I've said so before in comments on your blog, but much kudos to the
> project, you guys have been doing a great job! Some time ago I tried PyPy
> against an artificial life experiment of mine which implemented a simple
> stack-based language in Python and was pleasantly surprised to see that
> PyPy actually sped things up quite a bit - I'd heard about the JIT not
> being too good with interpreters. Good enough to make it a lot faster,
> though. :)
>
> Anyway, on to my question. I already asked it once in 2007, and didn't get
> a very encouraging response, but we're years down the road now and crazy
> difficulties is something the PyPy folks are good at, so I'll ask it again.
>
> You all are, as I understand, exploring supporting Python 3 with PyPy.
> Cool.
>
> Would it be possible to have an interpreter that could support both Python
> 2 and Python 3 modules in the same runtime? I.e, an interpreter that
> supports importing Python 3 code from Python 2 modules, and vice versa?
>
> It would tremendously help the Python ecosystem for such a solution to be
> out there, because in such a situation people can start using Python 3
> codebases in Python 2, encouraging more people to port their libraries to
> Python 3, and people can use Python 2 codebases in Python 3, encouraging
> more people to start projects in Python 3. I can't stress enough how much I
> believe that would help the Python ecosystem!
>
> I understand that the problems involved would be decidedly non-trivial,
> but that has never stopped you guys before.
>
> Modules would need to declare somehow that they were Python 2 or Python 3.
> There'd need to be, somehow, two separate import "spaces", where Python 2
> code would import from Python 2 modules by default and Python 3 code would
> import from Python 3 modules by default. You'd also need something explicit
> to allow cross imports. Python 2 objects represented in Python 3 (and vice
> versa) would either need to be transformed for immutable built-in objects
> (a Python 2 string would become a Python 3 bytes), or proxied for custom
> objects.
>
> I remember when I brought this up at the time that Armin Rigo suggested a
> few conundrums that were hard to solve. What these were exactly I don't
> remember anymore, so I hope Armin will chime in and remind me. :)
>
> Regards,
>
> Martijn
>
>
>
> ______________________________**_________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/**mailman/listinfo/pypy-dev<http://mail.python.org/mailman/listinfo/pypy-dev>
>

I don't think it can, or should be done, here's why:  Say you have a Python
2 dictionary {"a": 3}, and you pass this over to py3k land, what does it
become?  Logically it becomes a {b"a": 3}, two problems: a) it now has
bytes for keys, which means you can't use it as a **kwargs, b) internally
ints have a totally different representation, since there's now only a
unified long type (this one doesn't apply to pypy as much, just throwing it
out there for completeness).  Python 2 fundamentally does the string type
wrong, it's both the general string type for everythign, as well as the
byte sequence, the result is no program has enough semantic knowledge to
know what you mean by a string when you pass it over hte py3k boundary.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20111208/5434b571/attachment.html>