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@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
