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

[Ronan Lamy]

Le 15/04/15 20:34, VanL a écrit :
> 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.

Porting rpython and porting pypy are different problems. I'm not sure 
it'll ever make sense for pypy to translate on more than one major 
version at any given time. Getting rpython tests to pass on any Python3 
interpreter already seems like a daunting task to me.

> 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.

Personally, I think it's something we'll have to do sooner or later, so 
I'm glad to hear that you're motivated to put some effort into it.
>
> 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.

Sounds good. Cleaning up the code base by getting rid of outdated idioms 
and deprecated syntax would be a good thing in itself. I suggest you 
start with PRs that do just that.

> 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.

pypy is already 2.7 only. It's only rpython that still supports 2.6, 
probably (we have no CI for 2.6, so it's not even clear that it really 
works). I'm +1 for dropping it.

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

We already vendor py.test and pylib, so adding six is not an issue.

> 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.

Could you expand a bit? I'm not sure whether you want to improve the 
usability of RPython-the-language or the maintainability of 
rpython-the-toolchain. Anyway, both are useful goals, and contributions 
will be welcomed.

> Thanks,
> Van
>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev
>