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

List:       pypy-dev
Subject:    Re: [pypy-dev] Porting PyPy/rpython to Python 3
From:       Ronan Lamy <ronan.lamy () gmail ! com>
Date:       2015-04-20 17:53:24
Message-ID: 55353D14.1040804 () gmail ! com
[Download RAW message or body]

Le 20/04/15 09:15, Armin Rigo a écrit :
> Hi Ronan,
>
> On 19 April 2015 at 19:49, Ronan Lamy <ronan.lamy@gmail.com> wrote:
>> Well, I think that the only sane way to port something as big as RPython is
>> to do it incrementally - by getting tests to pass on 3 one subpackage at a
>> time. The parts that are ported will have to be written in mixed 2/3 style,
>> but having tests will prevent regressions in Python 3 compatibility: I don't
>> see why it would be harder than maintaining compatibility with "obscure"
>> platforms such as Windows.
>
> The model we use for Windows would not work.  Imagine we have a
> buildbot running nightly the tests on Python 3 (or some subset of them
> that were already ported).  If we make small changes anywhere in the
> rpython directory, we're likely to ignore Python 3 most of the time,
> just like we can ignore Windows most of the time.  The problem is that
> the latter is fine --- most changes to the rpython directory don't
> affect Windows specifically --- but the former is not --- these
> changes will likely add some SyntaxError or something for Python 3.
> So we need a team whose only job is to look at this Py3 buildbot and
> fix things the next day.

Once code has been ported, keeping compatibility is easy. It's mostly 
just a matter of mechanically writing X instead of Y. So a team of 1 is 
likely more than enough, and I'm volunteering to be it.

> This has two problems.  The first is that someone doing so for a long
> time is implausible (certainly not the kind of job I'd like myself).

Fixing other people's code and telling them how to write it? I can 
certainly do it for as long as you want, and probably for longer than 
that ;-)

> The second problem is that it is going to annoy a lot the original
> author of the patch, as the next day he's likely to continue working
> on the same parts and does not expect the source to have been
> thouroughly "fixed" under his feet, creating a lot of conflicts.

Compatibility fixes are unlikely to be extensive, if you start from code 
that was already compatible. You can also avoid conflicts just by 
remembering to 'hg pull' before making further changes or by running 
some Python 3 tests before merging.
>
> So, definitely -1 on that variant of the idea.
>
> I think I still prefer the "upgrade everything at once and forget
> about Python 2" approach.  Third-party users of RPython on Python 2
> don't have to upgrade at the same time as long as they use the "2.7"
> branch in our repo.  They might have to upgrade to Python 3 later if
> they want to benefit from new features or bug fixes we add from that
> point.  We can even backport a few selected bug fixes for a while,
> based on requests.

I don't think that upgrading RPython and PyPy simultaneously is 
realistic, even if we sprint on that exclusively for a week, all 
together. Porting RPython involves difficult design decisions, which 
shouldn't be rushed, and a raft of issues we won't know anything about 
until we try.

I fear that committing to the big-bang approach means that we'll just 
never port, because it's too risky.
>
>
> A bientôt,
>
> Armin
>

_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

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