Autocomplete while editing python scripts outside of Rhino

Here’s a way to get autocomplete on both Windows and Mac for editing python scripts that use RhinoCommon and Grasshopper.


Works nicely! If anyone figures out a way to get this working in Vim, please let me know ;).

It seems similar to denfromufa/ironpython-stubs, have you tried it?

1 Like

To be fair, that is a fork of Gui’s work at GitHub - gtalarico/ironpython-stubs: Autocomplete stubs for common IronPython/.NET libraries

I have looked at those packages and they are very nice. The issue with them is that they are mock libraries so it is very hard to actually run a python script for Rhino with those libraries on your python search path. The stub files that I created follow the guidelines of some recent python PEPs so hopefully support will show up in other editors over time as this is a standard.

A big advantage of using these stub files is that you can use them in combination with the new rhinosinside package discussed here:

I am hoping to write another article about this use case soon.


Hi Steve,
That github repo included instructions for using stubs with other editors (atom, sublime and vs code) . I don’t know if they have the limitation you describe

I used them by simply adding them to my project path in Pycharm so I could get edit more comfortably with autocomplete, for later execution within Rhino.
I also set up pycharm for Python 2.7 compatibility

They will. Don’t get me wrong, the stubs approach that Gui wrote works great with the exception of actually running and debugging your python script in the editor. Most of the time that isn’t actually possible so it doesn’t matter. With the new rhinoinside package this all changes.

Hmm not sure - the instructions refer specifically to the Jedi autocomplete engine, not the site packages folder or Python path but like I say, I haven’t tried :woozy_face:

I apologize, I do think I was wrong. It looks like the stubs are added as an extra location in the editor and not part of the standard python path.

Would it be possible to add some kind of scriptcontext proxy in the stubs? So we can import scriptcontext and can get to a proxy document, and everything still work when we run in Rhino?

Or maybe there is some other way to import the scriptcontext that will work in both environments? I tried a couple thoughts but none panned out.

I have after some work gotten gtalarico/ironpython-stubs to work in Vim. I have tried but not succeeded in getting the Rhino-Packages to work however.

Here are the steps in case someone else prefers working in Vim. These instructions assumes that you have a Linux environment with an installation of Vim that has been compiled with python support, and that you have python2 installed. Other completion plugins might interefere with jedi-vim.

  1. Install Vim plugin davidhalter/jedi-vim using your prefered method.
  2. Clone or download gtalarico/ironpython-stubs. The repo will be referenced in the next step.
  3. Append the path to the stubs to the PYTHONPATH variable in your shell profile (.bash_profile/.bashrc/.zshrc) using the command export PYTHONPATH=${PYTHONPATH}:/path/to/iron-python-stubs/release/stubs.min
  4. Put let g:jedi-vim#force_py_version = '2' in your .vimrc if you have python3 in your environment.
  5. You are now ready to complete using jedi-vim, the standard keymap is <C>-<Space>. I use ervandew/supertab to map completions to <Tab>.

As I said, I’ve tried to use this method to complete with Rhino-Stubs. I tried installing the package using pip2 and adding the path to the relevant site-packages directory but for some reason jedi-vim doesn’t complete Rhino methods.

Edit: I wrote this up with some more context on my blog and I have opened an issue to have it added to the ironpython-stubs wiki.

1 Like

Well done! Hmm maybe I should do the same for Pycharm :thinking:

Why not use @stevebaer’s python package if you are using PyCharm?

Yes good point. I have recently changed computer and I haven’t yet set up Pycharm so I’ll now give that a go. I might write up the stubs process for others as well … after my holidays :sunglasses:

1 Like

FYI; I just updated all of the stubs packages on to be based off of this week’s V7 WIP. A lot of functionality has added to our SDKs since the last time I did this. Please let me know if you experience any issues.


New stubs are available based on help from @eirannejad. The stubs now work cleaner in VSCode with all overloads for methods and constructors getting properly displayed. The experience in PyCharm is pretty much the same as with the previous stubs libraries.

pip install --user --upgrade Rhino-stubs


Hi Steve,

I succesfully installed the Rhino-stubs in PyCharm CE.

However it’s not working as I expected for autocompleting.
If I import Rhino like I’m used to in the rhino-pythoneditor I do not get an autocomplete for, for example Rhino.Geometry:


Might there also be an easy solution to this that I’m missing?

In addition:
These Rhino-stubs are from the WIP right? And there ar no available for V6


It doesn’t look like PyCharm is recognizing your installation of Rhino stubs. You might need to look at you PyCharm project settings to see if the package is installed.

The stubs are just there to assist with autocomplete so it doesn’t matter much if you are focused on V6 or V7 work.

@Willem can you try in Pycharm:

import Rhino.Geometry as rg


does that work?

Hi David,

That is indeed working and was my point, but I see that was not clear:



I’d rather not have to import all Rhino namespaces individually

I though this was related to the Rhino Namespace but any ‘sub’ will not autocomplete:


Hi @stevebaer and @DavidLeon

After some digging and testing I found that this is expected behavior and the auto-completion like in the Rhino Python Editor is not.

However I did find a solution in defining an __all__ in the __init__.pyi files.
For that I wrote the script below to be run in the Rhino-stubs root.

import os

start_dir = os.path.dirname(__file__)

for root, dirs, files in os.walk(start_dir ):
    init_files = [f for f in files if os.path.basename(f) == '__init__.pyi']
    if init_files and dirs:
        str_dirs = ["'{}'".format(dir) for dir in dirs]
        all_str = '__all__ =['
        all_str += ','.join(str_dirs)
        all_str += ']\n'
        #assume single __init__.pyi per directory
        init_file = os.path.join(root,init_files[0])
        with open(init_file, 'r') as file:
            init_data =
        #ignore existing '_all__'
        if init_data.startswith('__all__ =['):
            lines = init_data.split('\n')
            init_data = '\n'.join(lines[1:])
        new_init_data = all_str + init_data
        with open(init_file, 'w') as file:

__init__.pyi files now look like this:

__all__ =['ApplicationSettings','Collections','Commands','Display','DocObjects','FileIO','Geometry','Input','NodeInCode','PlugIns','Render','Runtime','UI']
from typing import Tuple, Set, Iterable, List

class RuntimeEnvironment:
    Unset = 0
    #None = 1

And autocompletion in pycharm is working like so:

I’m not sure how harmful it is to add the __all__ declaration to the stubs but I suppose it’s not.
I’m going to run the script above over my own module structure to have this type of autocompletion for those as well.


Interesting; I could definitely add this to the pyi files if it helps. Play with it for a bit and let me know if it continues to work as expected. We’ll also need to test this in VS Code to make sure it doesn’t break anything there.
Thanks Willem

1 Like