Comment by dr_zoidberg | Hacker News Reader

Comment by dr_zoidberg | Hacker News Reader

Parent Full thread

> By default it prints a diff, you have to use 2to3 -w if you want it to modify files on disk -- I certainly don't want tools modifying files in-place by default, so that seems like the right API to me.

Well, running 2to3.py -w -n -o [new_py3_path] [old_py2_path] got me a copy of a project with every fix already applied. Another alternative I've been thinking is doing a "last before 2to3 commit" (and leaving no pending changes), and then run 2to3 inplace and check those from the IDE (which may or may not be easier to a few folks that work with me).

I have to check a few more things, but it seems 2017 is the year I'm finally porting then two biggest projects I work on to Python 3. Luckily both projects aren't heavy offenders and should still remain Py2 compatible, but we may have the push with the clients to ask for exlusively Py3 support.

You could also test the waters with a `2to3` branch.

If you have uncommitted changes, instead of dropping them in as "last before..." you can git-stash them before branching and git-stash-pop them when you come back.

That would prevent 2to3 from seeing them, though.

Yes, because they're pending changes. When they're finished, they can be committed and the branch can be rebased to include them.

At which point you need to run 2to3 again, and maybe update callers of the code you stashed, depending on what it actually does. If you know with certainty it isn't going to be affected in any way by the upgrade tool, of course, then either works as well. But otherwise I'd argue strongly for finishing the changes first, committing them, and only then running the upgrader.

It's an argument of preference in practice, and therefore all but guaranteed to go nowhere. I tend to think that updating a whole codebase like this is best done atomically rather than piecemeal, especially when the code belongs to a team rather than an individual. But I can see where opinions might differ on such a point.

Part of wanting no uncommited changes is to push a few issues that have been lingering around as "too easy, not important" and get the team to fix them once for all. But yeah, we could be a bit more "correct to the git way".

Reply on news.ycombinator.com