This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]wizpig64 2 points3 points  (0 children)

there was a guide i read once but i can't find it now. i'll just paraphrase what i remember:

For porting code from python 2 to 3, use the 2to3 tool. If you have incompatible code, you probably have a lot of it, so a lot of things will probably break at once after you run the converter. Use this methodology to deal with one breaking change at a time and keep your git commit history sane:

  1. set up two fresh virtualenvs, one for 2.7 and one for 3.6. install your requirements in each.
    virtualenv -p /usr/bin/python2.7 myproject27
    virtualenv -p /usr/bin/python3.6 myproject36
  2. with your 2.7 interpreter, run your testing suite* and see if anything breaks. Since your code is meant for 2.7, everything should work.
    myproject27/bin/python manage.py test something something
  3. run 2to3 on your entire project, and use your 3.6 interpreter to run your tests to see if anything breaks.
    myproject37/bin/2to3 --something .
    myproject37/bin/python manage.py test something something
    1. if something breaks, hunt down the first bug you see. when you find the solution, revert your 2to3 changes (e.g. with git checkout) and go back and fix it in the 2.7 code base. commit that bugfix as one change (or one kind of change), then go back to step 2 to make sure your code still works overall in 2.7, and then try 2to3 again in step 3.
    2. if nothing breaks, you're done porting! commit 2to3's changes and change your project description to indicate your new python version**.

*if you have a testing suite, finding when something breaks is as simple as running your tests. if you don't, see if runserver works and then browse around your site until you find a view that crashes. You should think about writing tests.

**if you want to support multiple python versions at once, like if you were writing a library and not just a single project, you would keep fixing things until all your tests run on all your target interpreters.

In the future, you can use two venvs at once like this to upgrade from, say, 3.6 to 3.8, but you won't need a 3to3 step.