Hi heard maya 2019 is updating python
I doubt that is the case, for two reasons: 3ds Max 2019 did not make the jump to Python 3.x and Autodesk adheres to the VFX Reference Platform standards (https://www.vfxplatform.com/) which don’t stipulate an upgrade to Python 3.x until calendar year 2019. Given Autodesk’s release schedule that would mean that Maya 2020 would be the absolute earliest a possible Python 3.x upgrade would occur.
2 Likes
Also, probably much more likely that we’ll see python 3.5 or higher, as previous versions will be in a similar support situation to 2.7. (no longer supported by python-dev)
Personally hoping for at least 3.6, as I want a version that gets me f-strings.
1 Like
Unfortunately – it looks like we will have to wait another year before a python 3 update –
Taken from the link that Jeff posted above:
The move to Python 3 has been pushed to CY2020
Well that is frustrating.
What are the odds that vendors actually comply with the request for a python3 preview version?
Reviving this discussion. The latest FBX Python Bindings from the official Autodesk site now includes source to compile a different version of the fbx.pyd file.
(it actually links to a 2020.0.1 version if you decide to download the file.)
I installed Python 3.7 and used their recommended SIP 4.19.3 version and was able to successfully generate a valid fbx.pyd. Unfortunately, my tests do fail in some cases that do not using the 2.7/3.3 premade versions. Specifically, the search for binding tables (matching objects to shaders) appears to work, but I’m unable to pull entries successfully to introspect the shader attributes anymore. The GetEntry() func just fails.
Was wondering if there was anyone else looking into updating this autodesk module or is even interested ?
I’ll need to remember to poke around with this on Tuesday.
Currently we’ve got our own homegrown bindings to the C++ SDK.
Its probably not worth us upgrading (to much code churn) but still worth seeing if its somehow better.
I doubt it will be ‘better’ 
– but it does allow a code path in Python outside of 2.7/3.3 outside of the Autodesk App Ecosystem.
If you do decide to look into it:
I was using SIP source from here:
https://www.riverbankcomputing.com/software/sip/download
I used VS 2015
Python 3.7.3 x64
1 Like
This may need a new topic, but I will start here. In general, how have people been approaching migrating massive 2.7 maya libraries over to 3.x? I have been putting it off for a while, and am not starting to build up a roadmap, but I figured I would poke the hivemind as an extra data point.
@Adam_Pletcher can give a better first hand account on how Volition handled it (I came in after most if not all the hard work was done).
But from what I understand it was basically, run 2to3.py over everything, try to run stuff, and just incrementally fix the errors when they inevitably popped up.
But that 2to3.py did a pretty damn good job of doing the tedious mechanical find/replace style work.
1 Like
Caveat, this wasn’t Maya code, it was all our other giant piles of python code. But I’m operating under the assumption that the transition should be fairly similar.
Really the thing that 2to3 fails at, is distinguishing between when unadorned strings should be treated as unicode (or str now in python3) vs being converted into bytes. It errs on the side of turning everything into unicode, so if you’ve got string literals that need to remain as bytes, you need to manually convert them from "some_bytes" to b"some_bytes"
Bob summarized our process well. We had a huge codebase written for Python 2.7, and we ultimately moved it to 3.5. The 2to3 tool took a lot of the drudgery out. It wasn’t perfect, but it was also fairly good at telling you what it didn’t know how to handle.
Most of the work, for us, wasn’t just the move from 2 to 3. It was updating all our UI code to the newly re-written wxPython, which happened in the 2-to-3 jump. A lot was changed in that rewrite. If it wasn’t for that I think the whole thing would have been pretty straightforward.
In any case, we did the upgrade as a separate branch in Perforce. I would regularly integrate new stuff from main to that branch, just to keep it reasonably accurate, even when we weren’t actively working on the upgrade. When it was done we integrated it all back and fixed things we missed that popped up.
2 Likes
This is perfect you guys! Thank you.