Hi @ideasman42, thanks for getting back to me.
I think the big picture you are asking for, can be found in this phrase of the link I sent earlier:
to aid in providing minimal-effort Python 3 support for applications using libraries that do not yet wish to upgrade their code properly to Python 3, or wish to upgrade it gradually to Python 3 style.
So , why is important to allow “wish to upgrade it gradually to Python 3 style” ?
Over the years there’s been a big effort to try to find a common ground on libraries and dependencies between the DCC production companies, to make sure all the software can work together, and therefore the vfxplatform has born (https://www.vfxplatform.com/) to help having all aligned. (Foundry, Disney, Autodesk etc… are participating)
Vfx offices has been investing quite lot of money in developing many custom tools, and integrating software in each other using mostly python2 (leave alone qt and pyside), and shaping this way their pipelines and workflows. And due to the fact these places are almost always in crunch time for deliveries, there’s not much of a willing to risk to break their workflow or pipeline and therefore production, so the adoption of new , and breaking technologies has to be taken with care , and abundant time ahead. Still they are willing to look into new technologies, but ensuring the effort is worth doing it. You can consider them like elephants, with a lot of memory , pretty robust, but slow to move.
And this is the point.
In order to have tools ported, you need to go in various steps.
- ensure your python2 code is robust and does what should be doing.
- make the code compatible to py3k as well as python2 (future/past module) and ensure all works.
- once all the DCC application and tools supports py3k , remove the past dependencies and finally be in a better place.
The step 2 and step 3 though, could be taking way longer than the livespan support for python2, as they need to wait for ALL the moving parts (mostly DCC applications) to be compatible. In the meanwhile, bugs will be found, and improvements will be added. And you do not want to have multiple branches to keep in sync.
Where does blender fit in all this, you may ask ?
Well, I can see the new blender version is getting more and more attention, but in order to actually put it into the workflows, or even just evaluating it , it has to be able to fit somehow in existing pipelines and tools, and due to the fact is the only one using python3 (for now) , the python libraries at least has to be able to work in both worlds.
Allowing blender to load backward compatible code , will allow everyone interested to start using blender as test bed for their code, and due to that, lot of code will be tested against blender , and why not , integrated into it. (which is exactly what I’m doing)
As much as I agree with this:
Typically automated (even semi-automated) updates only work with simple test cases and aren’t enough to load more complex projects.
what I’m after is the ability to load old python types in py3k (which is what past module allowes) so code can work in both, I’m not after any auto conversion of the code.
My specific case, is just an example of what is likely to happen in any vfx house in the next few years, and allowing blender to be part of this process, could bring blender closer to productions, and have productions able to better evaluate blender in their environments and tools, and why not, later on contributing back if they can use it for production, with improvements and bug fixes.
Hope it helps, if you have any other question, just let me know.
Cheers.
L.