4 ms·

Seems a bit late in the conversation to mention this but there is no need to rewrite code to port from python 2.x to 3.0. Basically, move to python 2.6 -- larg

Seems a bit late in the conversation to mention this but there is no need to rewrite code to port from python 2.x to 3.0. Basically, move to python 2.6 -- largely an incremental change. Then use the -3 switch to find all the warnings and then incrementally get rid of them. Then the 2to3 tool should take care of most of the grunt work. Switching will be hard (all switches are) but it will not be as all-encompassing as a complete rewrite.

mechanical_fish 18y ago
From the original article: I think Python 3.0 is and will be a good thing even though it’ll create a staggering amount of work for me, my co-workers and my friends and colleagues (since I deal with two large Python 2.x codebases on a daily basis, the migration is not going to be simple or short for me). So. Not a complete rewrite, but merely "a staggering amount of work"?
- ubernostrum 18y ago
  A number of smallish changes, applied across multiple large codebases? Yeah, that's a lot of work. Our software won't have to be completely scrapped and started over, but we will have to spend quite a lot of time porting. In other words, if you have five hundred instances of `print "foo"` which all need to change to `print("foo")`, it's not that you have to "completely rewrite", but you _do_ have five hundred changes to make. And since applying a change is almost never as simple as a single search/replace/rename, it means work.
  - shutter 18y ago
    http://docs.python.org/dev/3.0/library/2to3.html http://docs.python.org/dev/3.0/library/2to3.html 2to3 will handle that automatically.
    - ubernostrum 18y ago
      It will handle that one, yes, but there are enough cases where the "best" transformation is ambiguous and so has to be determined heuristically that there'll still be plenty of work left over for human programmers (not to mention cases where 2to3 cannot determine a transformation at all, or cases where it can be fooled by code which uses 3.0-isms in 2.6 code, or the need to thoroughly test, re-test and test again to make sure everything still works).
- etal 18y ago
  For my own work I'm planning to do it this way: - Incorporate the -3 check with the usual unit tests and pylint run for checking a module as I work on it. - Stay compatible with Py2.X and these additional checks, and when curiousity strikes, run 2to3 to see what happens. The codebase will probably grow some different idioms needed to clear up 2-vs-3 ambiguities; that's OK. I'll learn how to avoid these ambiguities as I go. - When the community seems to be ready for 3.X (in particular, when Debian switches), most of the migration work will have already been done and the 2to3 script should work more or less perfectly for creating a new 3.X branch.

mechanical_fish 18y ago

From the original article: I think Python 3.0 is and will be a good thing even though it’ll create a staggering amount of work for me, my co-workers and my friends and colleagues (since I deal with two large Python 2.x codebases on a daily basis, the migration is not going to be simple or short for me). So. Not a complete rewrite, but merely "a staggering amount of work"?

ubernostrum 18y ago
A number of smallish changes, applied across multiple large codebases? Yeah, that's a lot of work. Our software won't have to be completely scrapped and started over, but we will have to spend quite a lot of time porting. In other words, if you have five hundred instances of `print "foo"` which all need to change to `print("foo")`, it's not that you have to "completely rewrite", but you _do_ have five hundred changes to make. And since applying a change is almost never as simple as a single search/replace/rename, it means work.
- shutter 18y ago
  http://docs.python.org/dev/3.0/library/2to3.html http://docs.python.org/dev/3.0/library/2to3.html 2to3 will handle that automatically.
  - ubernostrum 18y ago
    It will handle that one, yes, but there are enough cases where the "best" transformation is ambiguous and so has to be determined heuristically that there'll still be plenty of work left over for human programmers (not to mention cases where 2to3 cannot determine a transformation at all, or cases where it can be fooled by code which uses 3.0-isms in 2.6 code, or the need to thoroughly test, re-test and test again to make sure everything still works).
etal 18y ago
For my own work I'm planning to do it this way: - Incorporate the -3 check with the usual unit tests and pylint run for checking a module as I work on it. - Stay compatible with Py2.X and these additional checks, and when curiousity strikes, run 2to3 to see what happens. The codebase will probably grow some different idioms needed to clear up 2-vs-3 ambiguities; that's OK. I'll learn how to avoid these ambiguities as I go. - When the community seems to be ready for 3.X (in particular, when Debian switches), most of the migration work will have already been done and the 2to3 script should work more or less perfectly for creating a new 3.X branch.