[pypy-dev] Porting PyPy/rpython to Python 3

[Maciej Fijalkowski]

Hi Van.

First of all I'm really sorry if we ever gave an impression that
working on porting RPython to Python 3 would not be welcomed and I
would like to strongly disagree with that.

What we did say (or wanted to say) is that we're unlikely to put a
significant effort into doing the porting ourselves, however reviewing
the pull requests is definitely within the scope of the work someone
will do (if they languish, feel free to poke me personally).

As far as the points go, I'll respond inline.

On Wed, Apr 15, 2015 at 9:34 PM, VanL <van.lindberg at gmail.com> wrote:
> Hi everyone,
>
> For the last little bit I have been working on porting the rpython toolchain
> to Python 3. My initial goal is to get either pypy2 or pypy3 to build with
> either pypy2 or pypy3.
>
> I had gotten the impression from some previous statements that these efforts
> would not be welcome, so I was doing my work in a private fork. After a few
> conversations at PyCon, though, I was encouraged to package some of these
> changes up and send them as a series of pull requests.
>
> A couple questions/thoughts:
>
> 1. I am happy to send the pull requests up using bitbucket. Rather than do a
> big dump, I will send up chunks that each address a particular issue across
> the entire codebase. Even if a PR touches a number of files, each PR will
> implement the same change so that correctness is easy to check. If these PRs
> are not wanted, let me know, and I will stop sending them up.

That sounds very reasonable.

>
> 2. I am initially doing this work in a way that maintains 2/3 compatibility
> - my check before each major commit is whether I can still build pypy using
> pypy2. Would the pypy devs be willing to make building pypy be 2.7+ only?
> That way I could use __future__ imports to ease some of the porting.

Generally speaking the small changes are mostly a no-brainer for us.
RPython is already 2.7 only. However, we generally want to avoid being
Python 3 compatible as a major barrier, so things that complicate
stuff need to be discussed first. One thing that we need to discuss is
how to support unicode in RPython. Unicode-everywhere is definitely a
model we would not like to pursue, you *have to* be able to use bytes
efficiently and all over the place in RPython. Right now unicode
support is a bit rudimentary and I would welcome a way to structure it
better. I'm happy to discuss this (note that automatic conversion
between unicode and bytes in rpython is illegal anyway)

>
> 3. I will likely vendor or require six before I am done. Let me know if this
> would likely be a problem.

As far as simple stuff goes from six (e.g. constants) this is a
no-brainer, we can easily vendor it.

>
> 4. At some point in the future, I plan on reworking the rpython toolchain in
> various ways - use python 3 function and type annotations so as to make the
> flow of types be easier to see, fully split out the rpython and non-rpython
> bits, etc. Again, I am happy to do this on my own, but will gladly
> contribute upstream if wanted.

We'll be happy to review what you are trying to achieve and happy to
discuss ideas. Note that PyPy is by far not the only project using
RPython and we would need to consider all important
backwards-incompatible changes.

Cheers,
fijal