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