Antonio Cuni <anto.c...@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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
