On 05/27/2012 07:53 AM, Steven D'Aprano wrote: > > On Sat, 26 May 2012 19:37:33 -0700, ru...@yahoo.com wrote: >> >> Is there a list of fixers I can tell 2to3 to use that will limit changes >> >> to things that will continue to run under python-2.7? > > > > So you want a 2to2?
Yes. :-) > > I suggest you read the Fine Manual and choose the fixers you want to > > apply yourself: > > > > http://docs.python.org/library/2to3.html > > > > That, plus a bit of trial-and-error at the interactive prompt, will soon > > tell you what works and what doesn't. But read on for my suggestions. That, and the 2.6 and 2.7 What's New's and the docs for the 3.x backported features mentioned therein... I've started to do just that but if someone else has already distilled all this information... >> >> I want to start the 2->3 trip by making my code as py3 compatible (under >> >> py2) as possible before going the rest of the way to py3, and having >> >> 2to3 help with this seems like a good idea. > > Your project, your decision, but it doesn't sound like a good idea to me, > > unless your project is quite small or efficiency is not high on your list > > of priorities. You risk making your 2.7 version significantly slower and > > less efficient than your 2.6 version, but without actually gaining 3.x > > compatibility. I can't really migrate my project until wxPython does. But I've read a number of conversion experiences ranging from "ran 2to3 and everything was golden" to needing to make some serious design decisions (usually in the bytes/str area) to months of effort to get all the little glitches wrung out. So I have no idea what is in store for me. By doing some of the conversion now I can hopefully get a better sense of what is in store and get some of the work done earlier rather than later. There is also the generally useful heuristic of dividing a larger task into two smaller independent tasks... And finally, there is the question about maintaining 2/3 compatibility in a single codebase. I don't have a hard requirement for this but if it is doable without too much effort, I would prefer to do so. ISTM that looking at what remains left to do after the 2.7 code has been 3-ifided as much as possible will allow me to make a better judgment about that. > > (For what it's worth, I try to aim at 3.x compatibility as the priority, > > and if that means my code is a bit slower under 2.5-2.7, that's a price > > I'm willing to pay.) > > > > The problem is that many of the idioms that work well in Python 3 will be > > less efficient, and therefore slower, in Python 2.7. For example, > > consider this Python 2.x loop, iterating lazily over a dict efficiently: I did not spend much time optimizing for performance when writing the code, so it probably doesn't make sense to worry about it now, unless a really large performance difference is likely (which seems to me unlikely given that I don't have any really large in-memory data). Thanks for the tip though; it is something I'll remain alert for. > >[...] > > For what it's worth, I'd try these fixers: > > > > apply > > except > > exec > > execfile > > exitfunc > > has_key > > idioms > > ne > > next > > paren > > print > > raise > > repr > > tuple_params > > ws_comma > > xreadlines > > > > plus "from __future__ import print", and see what breaks :) > > > > Also, don't forget future_builtins: > > http://docs.python.org/library/future_builtins.html > > > > Good luck, and if you do go ahead with this, please consider posting an > > update here, or writing a blog post with details of how successful it was. Thanks for that list. Sans anything more definitive it is a good starting point. -- http://mail.python.org/mailman/listinfo/python-list
