Yes, I should add that in there as a note. I don't really know of any studios doing feature film work with Blender to be honest, but it is important.

Of interest, vfxplatform.com is the group that sets the loose guidelines of what packages everyone should be using, and currently they're on py2, so blender is the exception unfortunately, as much as I would love to be on py3, even if just for native async.

'Kiribati' is a film currently being developed with Blender, but mostly its usage is for short films and TV ads.

While I'm guilty of staying with an "aging" 2.7 codebase (due to lack of time, and my employer not being really sure about Py3), with 3.6 I've been looking more and more into porting and it doesn't look that complicated. Am I missing something when people say that "it's not easy to switch"?

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.

> but maybe represents a small set of 'the industry', with smaller studios

The tech tools in the biz are downright ancient. ;) At my place of work we just got C++11... on an old ass version of GCC. We are also stuck on Qt4 (uughhh!) for the foreseeable future. Also no Python 3. Version control? Enjoy those merges in Perforce!

No one in the industry uses blender though, sadly. C4d supports python scripting but that is python 2