Python QtCore module issue

[malcomarmstrong]

I have a local install of python (2.7) as well as the python that ships with Max.

Prior to PySide2, we used PyQt4 alongside an updated version of Blur python combined with in house communal server side libraries.

In the pursuit of updating our tools/scripts etc. and making use of Max Python (MaxPlus and pymxs) I noticed a difference in the PySide2 modules.

Outside of Max, in PySide2.QtCore, you find: QtCore.QStringListModel

In Max`s PySide2.QtCore, there is no QStringListModel, you have to access it through: QtGui.QStringListModel.

This causes a major issue with existing scripts as it ties us to using one or the other (we do not want to have a split system). Tools that only run in Max could be achieved, but we use Deadline, Shotgun and other applications that use PyQt PySide, PySide2, but really did not expect the PySide2 binaries/libraries/modules to be different. We can no longer rely on or trust the implementation if this is going to be a factor. 

I really do not want to have to trawl through the different libraries to find the differences, nor do I wish to create a script system that has to check what should be a straightforward import of items we need when writing code.

Parts of our script call from outside of Max, so it is a little cumbersome and I dont know why Autodesk have chosen to use/create a library that is different to what exists elsewhere. Perhaps this is not even the only difference, so how can we trust the implementation, especially considering that the docs are incomplete and there are serious issues with asset access and ability to create higher level objects and code?

If anyone can shed some light on this, I would appreciate it as we really want to be able to use Max Python in our work, but not at the cost of doubling up on things that should be standardised and especially when  the implementation is incomplete.

[eric.brosseau]

The PySide2 Python module was introduced for the release of 3ds Max 2018; which brings us back in early 2017. The PySide2 version that was included was marked '2.0.0~alpha0'. The module has not been updated since in 3ds Max. However, The Qt Company continued their work to create a more reliable and compliant version of the module, but it is still in an alpha stage on Qt 5.6; they now have a '5.6.0a1' version.

As a side note, they announced in June the first official version of PySide2 based on Qt 5.11; now called 'Qt for Python'. This change still needs to be evaluated on our side.

We are aware of the problem you are going through with the currently provided version of the module and are actively working on providing an updated version of PySide2. We do not have specific details as to when it will be available but we hope it makes it for an update in the coming months. The update would also enable other Qt modules to be now available in PySide2, like QtMultimedia.

[malcomarmstrong]

Thanks for the reply, but the response is a little ambiguous and means that script development and updates (relative to the pipeline we are redesigning) will now possibly need another update once the issue has been resolved, of which you have said there is no definitive timeframe. The development for Max Python (whichever implementation you choose) has been way too long in coming and still does not have a complete library or documentation (pymxs being the worst, half a paragraph on a doc page and MaxPlus examples are woefully inadequate and poorly explained) meaning that its cumbersome to develop with any peace of mind. While we are glad to see that Max does have some python access, it seriously should have been held back to ensure that coding could be done sufficiently and without errors or omissions. Maya has had a great python implementation for years, why can Max not do the same? I am sure in time, it will improve, but its being left in the dark as to what we are actually getting that is putting people off. I have been trying to use pymxs as it close to what we currently use (Blur python) but as mentioned, lack of documentation and poor access to some scenes assets etc that can be done easily with Maxscript does not give confidence, at least in the relatively short term, that this will be ready in the near future. I hope that this is resolved before the next yearly release.

regards

[laurent_gibert]

Hi @malcomarmstrong,

Thanks for the feedback, this is very valuable. It is true that the implementation of Python in 3ds Max has been relatively slow over the years. We are currently revisiting this topic to make a bolder move as far as the overall development experience in 3ds Max is concerned. This would potentially involve some rework of the integration to make it more flexible, looking at the lack of guidance and clarity from the documentation stand point, and consolidating our SDKs/APIs.

If you are not already part of the beta program, I would strongly encourage you to join, as we would start discussing next steps for the developer experience in 3ds Max soon.

Thanks for taking the time to exchange with us, and hope to see you help us define the right path forward!

Regards,

Laurent

[malcomarmstrong]

Hi Laurent, I did apply for the Beta after you came in to our studio to see us earlier this year, so am hoping to hear back soon as we really need to be able to have input and some resolution to this in the best time possible. I will check my mail again to see if any info has come through.

Not knowing what is happening or even the ability to use documentation would help, but as the latter is non existent, developing with pymxs is very time consuming with trial and error.

Thanks for the reply though, I hope to hear about updates and progression soon.

regards