Alex Gaynor, 08.12.2011 11:35:
On Thu, Dec 8, 2011 at 5:16 AM, Martijn Faassen wrote:
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?
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.
I agree that it's not trivial. However, that doesn't mean it should not be
done. Take Cython as the obvious example. It compiles your Py2 or Py3 code
once, and it will then have to run both environments. It has to pull a
couple of tricks to make this generally work (some of which mimic the 2to3
tool), and even then, there are differences that leak into the code, some
of which you mention above. So the code also has to be written in a way
that avoids ambiguities and works around the differences that cannot be
covered at compile time.
Cython actually has three string types: bytes, str and unicode. The first
and last are identical in Py2 and Py3, whereas str is bytes in Py2 and Py3.
That makes it possible to explicitly write code for both environments,
although it does not help much with the typical legacy code that uses str
for everything.
At least some of the problems would, however, go away if both runtimes were
available at the same time. For example, builtins could behave differently
based on the semantics of the source code that uses them, simply by using
different builtins modules for both kinds of source code. That alone would
go a rather long way.
So, assuming that Martijn was actually referring to legacy code, I agree
that it won't solve the problem at hand. But that doesn't mean it would be
impossible to benefit from it.
Stefan
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
