Code Completion for ghpythonlib.components (node-in-code) in Visual Studio



I did some work on remote debugging again and it works very well with Rhino 6 WIP and the Python Tools for Visual Studio. Now I’m trying to get all the benefits form using Visual Studio as an editor for GhPython scripts, mainly I want a working object browser and code completion and help (IntelliSense). That’s not problem for thinks like rhinoscriptsyntax but I don’t know a good way to get it to work with ghpythonlib.components.

I could see a way to use the introspection to generate s kind of dummy library containing only definitions and the docstrings for all the Grasshopper components, but it’s probably quite a bit of work there is probably a better way.

Any ideas?

See you

(Giulio Piacentino) #2

Hi Florian

Sorry, I am not aware of better ways. I would just experiment like you did.
The ghpythonlib.components library is generated off loaded GHAs. This means that if you have a new plug-in, more functions will be available.

I think this library is not the easiest to document at present.



Giulio Piacentino
for Robert McNeel & Associates

(Lukasz Domagala) #3

I’ve been trying to setup visual studio code to work with Rhino but to begin with I can not find ipy.exe anywhere in rhino folder. Have you ever tried to use vs code for rhino python?

(Giulio Piacentino) #4

You can use Visual Studio Code only as an editor, at present you cannot change the Rhino interpreter/debugger. There is also no ipy.exe shipped with Rhino. If it were, you could use it to interpret stuff outside of Rhino, but you would have to setup communication with Rhino to run anything geometrical in it.

(Lukasz Domagala) #5

I see
So it looks like I’m stuck with rhino python editor :frowning: the problem is that in rhino python editor I can’t see all available modules (like json, pickle, random etc.). is there any way to display them?

(qythium) #6

Hey, I’ve actually done exactly what @frist mentioned above, using reflection to recurse through the entire Rhino namespace in GhPython, and write the docstrings and function signatures to a dummy python folder structure, which I then reference in Sublime Text’s linter:

Huge timesaver, especially on a Mac where there’s no inbuilt editor in Rhino/Grasshopper!
It’s definitely still rough around the edges though, I’m not quite sure about releasing it yet…

(Lukasz Domagala) #7

That looks really cool!

At the moment I’m trying this


Not quite sure what is meant by “see”, but not all modules are listed in the builtin intellisense, but some (like random) are:


But just because they are not “intellisensed”, doesn’t mean they aren’t available (like json and pickle):



There is a method for getting a list of all available modules, but afraid I do not remember how in IronPython. In CPython you could go like so:

That said, you can always have a look/search in the IronPython distribution that ships with Rhino (pure Python modules are under Lib, but some modules are also in the .dlls:

(Lukasz Domagala) #9

Thank you Anders that’s been helpful.
I could never see random on any Rhino :face_with_hand_over_mouth:

But yes I know that I can load these anyway without intellisense but this isn’t handy when you’re trying to learn python :slight_smile:


Looks like it might be different from version to version. This is Rhino 5 in Windows 10:


Might be something for @piac to have a look at :male_detective:


Hi qythium,
I’m very happy to hear that the idea actually worked. Unfortunately I did not do any work on this, mainly because I did a lot of C# programming recently. Being able to generate the docstrings and function signatures in some semi automatic way would be very helpful, not only to me, but to a lot people.

I hope you will decide to publish your solution. In case there is something that I might be able to help with, I surely would try to do so. At least I could test your solution under Windows 10, Rhino 5 and 6 and Visual Studio 2017.

See you

PS: And the nice thing is, that in Rhino 6 debugging using Visual Studio works very nicely (well, actually I did not test this in with the final release, but it worked in a beta version). This plus the signatur/docstring files would make VS really useful.


For RhinoCommon (and other .NET assemblies) one can use Gui Talarico’s IronPython Stubs. I’ve been using these in Sublime Text (there are instructions for atom and visual studio code as well) to get intellisense for all the Revit APIs. Haven’t tried it with RhinoCommon, but believe that should work out of the box as well.

(Giulio Piacentino) #13

@qythium that sounds very cool.

I am busy on another project right now, but I think @Alain or @stevebaer know more / could help.

(Steve Baer) #14

I do call it “Intelliclunk” instead of “Intellisense”. Our autocomplete functionality needs a rewrite. We have ideas on how to vastly improve this, but there are currently other bigger fires to put out.

(qythium) #15

Wow… can’t believe I spent all that work trying to reinvent the wheel there! :no_mouth:
I couldn’t quite figure out how to run the stub-generation scripts, but looking through the code it looks like exactly what I was attempting to do, except way more robust.
This should definitely be more widespread knowledge!


Haha, very accurate indeed. I find myself using the “the modes of introspection which are available in the language itself” to inspect modules, assemblies, namespaces, objects etc. printing to the GHPython console (a coding workflow that is pretty neutered on the Dynamo side of things).

Edit: Think I uploaded the wrong file in that old post: Here’s the one for inspecting the content of a .NET assembly: (9.0 KB)



This should definitely be more widespread knowledge!

Indeed, I also didn’t know about it. Thanks for mentioning it Anders.

@qythium: I’d be cool it you could let us know if you were able to make use of IronPython Stubs. It look really promising, unfortunately I’ll be to buddy to give it a try in the next few week.

See you

(qythium) #18

Yes, I’ll probably look into it closely this weekend.
One more thing I realised is that their stub functions don’t have return values defined, which defeats the point of the linter’s static type analysis features - i.e. being able to do this:

I’ll probably fork the repo and try to make some improvements in that direction :slight_smile:

Also, their release packages seem to be missing big parts of the Grasshopper namespace, e.g. Grasshopper.Kernel.Special, not sure what’s up with that.


Make sure to log those issues on the github repo :wink:

Edit: The * import style might break some intellisense (and is problematic for several reasons)

(qythium) #20

Yeah, I realise it’s bad Pythonic style, but SublimeJedi has no problems with it, and also I restrict myself to only using it for Rhino.Geometry for the convenience ( and easy translation to and from C# ).

Re: object introspection in the Grasshopper canvas - I’ll just share a little utility script (inspired by this blog post) (4.2 KB)