[pypy-dev] python 3

[Yury Selivanov]

Re option #1, just trying to start a discussion:

I know it's a hard topic, but why not to adapt python 3?  Python 3 is the future, everybody understands and accepts that.  Pypy doesn't have substantially good support of c-extenstions, so, let's say, numpy has to be rewritten anyways.  RDB drivers are also poorly supported, while python 3 has an excellent pypostgresql written entirely in python.  Django, twisted and even zope will support python 3 eventually, it is a matter of time.  Why not to start the move now, and do all the heavy work of rewriting numpy & other libs in python 3 to save time later?

On 2011-08-16, at 6:39 PM, Benjamin Peterson wrote:

> 2011/8/16 Yury Selivanov <yselivanov.ml at gmail.com>:
>> Is it possible for pypy core developers to create a high-level roadmap with what needs to be done and where?  Should python3 be another translation target?  Will it be required to touch rpython spec?  What data structures need to be introduced?  etc.  I don't think this planning will take weeks of work, but it will help everyone to understand how much time and money should be invested in the matter.
> 
> First of all, there are some rather large decisions to be made:
> 
> 1. Port everything (Python interpreter, RPython) over to Python 3 and
> only support Python 3. This would probably be the cleanest and easiest
> in the longterm solution, but I doubt many are willing to accept it
> quite yet.
> 
> 2. Somehow maintain Python 2 and 3 in the same codebase. It sounds
> like a hideous mess to me. (I'm happy to be proven wrong.)
> 
> 3. Maintain a Python 3 interpreter in a separate repo or branch. This
> is probably the best compromise, but it requires the constant
> maintenance of someone merging the current head work.
> 
> Then someone has to buckle down and do the actual porting. Depending
> on the option selected above, the amount of work will vary from huge
> to colossal. If you pick option 2, you have to figure out how to test
> both versions. I imagine there will be quite a tangled mess with
> unicode.
> 
> At any rate, some of the initial steps which are compatible with
> Python 2 such as removing tuple unpacking and normalizing raise
> statements can now be taken. They might even make the codebase a bit
> cleaner.
> 
> 
> 
> -- 
> Regards,
> Benjamin