[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pypy-dev
Subject:    Re: [pypy-dev] change of strategy for the py3k branch?
From:       Martijn Faassen <faassen () startifact ! com>
Date:       2012-05-31 8:59:56
Message-ID: CAGT4ZFhNDGCAEm-jhQ5PuFfCdCggt6vuFs95xjwVN=P94MJ3eg () mail ! gmail ! com
[Download RAW message or body]

Hey,

> Can you describe what sort of semantics you have in mind?

Sure, I've discussed them before. The goal would be to have a Python 3
based project and use Python 2 modules/packages,
or the other way around. That way it  should become much easier to
adopt Python 3, even in existing projects. To this end you'd need to
have import magic that'd go across Pythons:

# in python 3
foo = python2_import(''foo')

# in python 2
bar = python3_import('bar')

These would import the modules in the appropriate interpreter, and
then wrap them in such a way that they become usable from the other
interpreter.

Later, you could come up with more sophisticated ways to designate a
module "python 2" or "python 3" so that the normal 'import' statement
will do something equivalent to the above (if you happen to know there
are no namespace conflicts).

>Would you like to have two copies of builtin modules?

Yes, a separate copy for each interpreter.

> How about namespaces?

Yes, module name spaces should be separate. If you want to make a
Python 2 library available in Python 3 you can
use the import magic to do so.

> What about objects being passed from one interpreter to the another?  Would they magically
> change or would they be "py2k dict" and "py3k dict"? If you can describe the
> semantics of a proposed beast I'm willing to answer how likely it is to
> happen

They would be wrapped. I understand PyPy supports perfect proxies
(I've seen the network-based demonstration). So you'd wrap a
Python 3 object in a Python 2 wrapper, and vice versa. So a Python 3
proxy for a Python 2 object would:

* make sure any attribute accesses are translated to Python 3 objects.
(for immutables, a straight conversion is enough, otherwise a proxy)

* a method proxy would make sure that any arguments are proxied from
Python 3 to Python 2 (or straight conversion in case of an immutable
if that'd be faster. Or a proxy unwrapping in case you are dealing
with a Python 2 to 3 proxy already), and any return values are proxied
from Python 2 to Python 3.

The proxies for various built-ins such as dict would of course make
sure that method calls are translated.

You need to able to be able to declare various things about arguments
and return values in some tricky cases like where a Python 2 string is
involved; is it to be interpreted as a Python 3 string or a Python 3
bytes? Declarations could go into a central registry that is consulted
by the proxy-ing mechanism, we can come up with nicer syntax later.
The idea is that you could make declarations about a Python 2 library
externally so you can use it within a Python 3 context.

One way to think about this is a FFI from Python to Python. You'd need
Python 2 to 3 proxies, Python 3 to 2 proxies, and various proxy
wrapping and unwrapping rules.

Regards,

Martijn
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
[prev in list] [next in list] [prev in thread] [next in thread]