4 ms·
What's also missing here is differentiating between "dependencies" as other python libs or host apps with built-in python interpreters stuck to a particular ver
by berkut 13y ago
What's also missing here is differentiating between "dependencies" as other python libs or host apps with built-in python interpreters stuck to a particular version.
For example, VFX studios are generally stuck on 2.6.4 as that's what Maya 2012, Nuke 7 and other commercial software is using.
Lots of VFX studios have hundreds of thousands of lines of Python code integrating stuff across their pipeline. Until the host apps support Python 3 (some like Houdini support both 2/3 via different plugin proxies), it's a Chicken and Egg situation, as VFX studios won't port their python code to 3 until they need to, and the commercial companies making the software above aren't going to waste time adding Python 3 support until their customers ask for it.
So I'm assuming 2.6/7 is going to be around for a while...
- Keyframe 13y agoOne solution would be to provide the two in parallel. But then again this area is slowly moving. I just recently (early last year) wrote my last MEL code and moved fully onto python.
- berkut 13y agoYeah, but that's quite likely (without some sort of façade layer) going to be double the work adding new functionality, and it's definitely going to be twice the testing of the entire Python functionality of the apps.
- klodolph 13y agoSome are stuck on the 3.x series, like Blender.
- sitkack 13y agoWhat we _really_ need is a way to manage python2 and python3 codebases, infact we need a story to manage pythonN+ codebases interoperating in the same process. How is this a one time event? It isn't, nor should it be. Everything is future legacy. Versioned imports down to the language level. Each file should say what version of the language it uses. Code once written that works should not fail to work in the future.