I feel the need to leave this as part of the discussion as it might help push Autodesk by making their users aware of the problems.
You are wrong.
It is not a misconception based on my experience and the one from my coworkers who have way more time me working with pymxs in AAA production env (as Im doing now with them).
It is true pymxs is a wrapper for maxscript, and I think thats a very good step towards integrability, but they dont translate intuitively. The example above is one of many that we have encountered: there is no ‘creative’, ‘intuitive’, ‘imaginative’ way to create Tools nor Plugins as a translation of maxscript, so much so there is no actual way to do it, and there is no documentation saying so (until now). There is a lot of instances in which Python syntax clashes with maxscript, and you need to trial and error which type of parameter and how it needs to be fed to the function that you discovered might be related (string parameters comes to mind). And that doesnt mean you might find the way.
In an AAA production environment with deadlines and goals, I dont want to purely rely on imagination when a proper documentation could save a lot of problems and time, I dont have time to ‘decipher’ how the wrapper works, I need to solve the problem I have at hands. That should be a given in the documentation and thats just a bare minimum. You can actually visit the new documentation and see how examples can change sharply between how is done in maxscript and in pymxs. Im not saying this is the rule, but it is far from uncommon.
Autodesk itself (through forum answers from their employees) have acknowledge this in the past, it is not hard to find.
pymxs has a serious problem of documentation and they took a step further towards solving it.
Denying it wont help anybody.