This project has moved and is read-only. For the latest updates, please go here.

Better Intellisense support for Maya/PyMEL possible?

Oct 10, 2014 at 1:42 PM
From another thread, I found a link to one of the source files to the PythonAnalyzer, which from my brief read-through seems to be responsible for adding additional inherent knowledge about certain Python modules and functions, allowing PTVS to glean information from the code that normally would only be available to the live Python interpreter.

The PyMEL library, which is a more object-oriented wrapper around Maya's Python API, has methods mirroring the original API. These functions call the original versions, but then they wrap the result in PyMEL classes before returning it. Now, there are two versions of the PyMEL library - the version used by Maya, and a separate version that contains a TON of documentation (Like, tens of megabytes!) that is intended to be used by an IDE to provide that documentation while editing. I have PTVS set up to use the doc version of PyMEL, but, while this version includes documentation, all of the functions are simply pass functions that do nothing.

Would editing the PythonAnalyzer and adding these functions and the actual object-oriented class types that they return be the correct way to get better Intellisense out of PTVS? For example, the function creates a popup menu GUI element, but actually returns an instance of pymel.core.uitypes.OptionMenu - a class which has many methods that would be very handy to have Intellisense information for while editing!

Thanks in advance, guys.
  • Dylan
Oct 10, 2014 at 4:27 PM
That's great that PyMEL has that documentation version of their code. Lots of people have lots of ideas about how to make something like that work well, though there's no consensus yet.

Our code analyzer works best with code - we pay very little attention to docstrings unless they're in a .pyd file - so something like this is a better stub for us:
def optionMenu(alwaysCallChangeCommand=True, annotation="", backgroundColor=(1.0, 1.0, 1.0), ...):
    return pymel.core.uitypes.OptionMenu()
(You can even have multiple returns in there for different return types. It's not a syntax error, so we'll analyse it fine, even if the code is unreachable.)

It's possible that the other version of PyMEL will give you better completions in PTVS, even if it's lacking docstrings. Modifying the specializations may also help, but that's a much bigger task than you're probably expecting :)

I don't think we're ever likely to feed information from docstrings into our analysis - most docstrings aren't good enough, which means we either get things wrong or have to force people to manually include/exclude functions/modules/etc. from that analysis, neither of which I want to do - but we always have handled default argument values and trivial return types well.
Oct 11, 2014 at 12:42 PM
I see, thanks! PyMEL already parses its own docstrings at runtime in order to figure out which methods to dynamically add to various classes, so maybe I could just dump that information formatted as Python method signatures like your example and use the resulting library as the version of PyMEL for PTVS... Interesting! :)