Personally, I develop for py27 and py35 at home, and outside of a few edge cases, most things are covered by six to the point that I don't think it's hard to develop new code that is compliant with both.

What is hard is updating code bases that stretch back almost 2 decades. It's just a lot of code.

IMHO the industry should start updating now rather than digging a bigger hole but c'est la vie.

How much unicode do you work with? If your answer is "none", then the answer to "is it easy to switch" is "not that hard".

I would start by taking your 2.7 code, adding "from __future__ import print_function" and fixing any SyntaxErrors. This is trivial by byte compiling all the files.

Then, add "from __future__ import division". Now, run all your tests (you have tests right?). If none fail, and you're sure your tests actually test your division code locations, then proceed.

Next step: you're done.

I can think of a few spots where we've used filter or map which should require a bit of work too. Other than that, your Hitchikers Guide to Python 3 seems about as easy as it can be.

map and filter return iterators. This is easy to fix (list(map(...)). reduce is at functools.reduce.

Hmmm I knew there were some changes in both map and filter but didn't dig into them. If the only change is that they return iterators instead of lists, it would even help on some parts of a few projects I maintain. I still have to check it up though, can't be certain until I see what happens and if it breaks anything.

From my limited experience, the code that needs the most work is that involving reading text files -- the whole unicode vs bytes thing.

For the rest, the 2to3 tool does the vast majority of the job.

just tried 2to3 on a small code-base and it seriously BROKE logic, i.e. introduced bugs!

could you be more specific

My guess is people are afraid they're going to end up with difficult to debug edge case type bugs and have to sink loads of time into it beyond the standard porting steps.