[pypy-dev] change of strategy for the py3k branch?

[Justin Bogner]

Antonio Cuni <anto.cuni at gmail.com> writes:
> after some months of work on the py3k branch, I realized that the current
> strategy/workflow does not scale well and thus I'd like to change it.
>
> For those who are not aware, currently we have the default branch where the
> main development is done, and which includes code for both the rpython
> translator toolchain and the python 2 interpreter.
>
> The py3k branch does not touch the translator toolchain, but modifies the
> python 2 interpreter to make it a py3k interpreter.
 <snip>
> If we decide to go for this route, the next question is: where to store the
> code? I think there are two main solutions:
>
> 1) add a new "pypy/py3k" directory where to copy all the relevant modules.
> E.g. pypy/py3k/interpreter, pypy/py3k/objspace/std, "pypy/py3k/modules.
>
> 2) start a completely new repository which contains only the code for py3k.

Any solution where improvements to the translator have to be ported
manually is a recipe for trouble. The translator toolchain is and should
always be shared.

The interpreters, on the other hand, are where the merge difficulties
come from. These are fundamentally diverging since the python 2 and 3
languages are actually quite different.

Because of these two things, there are only two sane solutions, and (2)
above is not one of them. 

Adding a py3k interpreter to the default branch is reasonable, and could
lead to sharing common parts in a top level directory at some point, but
it comes with a burden on the current python 2 development work.

The other solution is to split the current pypy tree in two. Having a
translator and an interpreter as separate repositories makes the
translator more accessible as a tool, and projects to implement other
languages' interpreters need only depend on it. This is the prettiest
solution architecturally, but adds the burden on developers to match
translator with compatible interpreters, which may or may not end up
being a pain point.

Anyways, a completely separate pypy3k repository is no better than the
current situation, and I would argue that it's far worse. The pains
you're experiencing trying to do merges today aren't even close to the
kind of pain you'll experience trying to merge in interpreter
improvements manually.