Wildcard imports are not picked up by autocomplete engine

[johannesrave]

Heyhey, I'm a Dynamo-user, but coming from the Autodesk-Alias-side. I haven't ever opened Revit in my life, and I don't need it or the Revit-stubs, I just need to program generative geometry for Alias in Python. I have just spent the better part of a weekend trying to get autocomplete to work in Atom for the stubs released in this package. I'm having a hard time wrapping my head around all the different dependencies, maybe someone can help me here. I am on Windows 10 on a fresh install of Atom 1.30, actually reinstalled just to get this working. I have followed the instructions installing python-autocomplete, got it working and going from there did the following. I first tried using the ipy64.exe (and its path) in the python autocomplete settings, and pointed the "package"-setting to the cloned github respository: C:\Users*user\github\ironpython-stubs\release\stubs.min My test, after restarting Atom, is always to start typing "Vector" in this file: `import clr clr.AddReference('ProtoGeometry') from Autodesk.DesignScript.Geometry import `

I don't get it to autocomplete "Vector", or "Point", or one of the class methods, nothing comes up. I then tried leaving the python-version-field empty, pointing explicitely to my python 3.7 installed with anaconda (registered in the environment variable), and then installed a python 2.7 and pointed to that. Regarding the stubs, like I wrote, I first tried pointing the "package"-field to the cloned repo, then copied them to the package-site folder in the IronPython directory leaving the field blank, then point explicitely to that folder, then making a C:\stubs\ folder and copying stuff in there. For some reason, when I start typing "clr", I get autocomplete, but not for any of the classes or inputs I know from DesignScript in Dynamo. Any ideas? Am I just impatient, and it needs to crawl all those stubs first? But how can I tell when it has finished? How could I debug this problem? Maybe this is the wrong place for this, but I thought if we get this solved here someone else might be able to find it later.

[johannesrave]

The ´all´ list in ´init.py´ is incomplete, which means ´import *´ can't work. When I import stuff explicitely, it's working just like described in the wiki. Thanks!

[gtalarico]

Were you able to get it to work?

Python path should be pointed to or allowed to pick up your systems python.exe (not ironpython, ipy etc) You would follow the steps as outlined by the autocomplete plugin provider.

By adding the stubs to the plug-ins packages setting it should pick up other things like clr and everything else in the stubs.

As you correctly noticed, using wildcard asterisks imports does not work because the stub modules are not configured to support it. This is not unusual for python extensions that use on static code analysis.

I generally don't use wildcard anyway, instead you can do something like this:

from Autodesk.DesignScript import Geometry as g g.Vecor

This should help with autocomplete, but also makes it easier to know from what import the Vector class came from

[johannesrave]

Heyhey, yes, and thanks for the very fast answer. Everything works like you described in the wiki. I am even using the ipy64.exe in autocomplete, though I don't know whether that is helping me in any way - I thought it might be relevant somehow, maybe for autocompleting some NET-stuff? Either way, the python-version didn't seem to make a difference (except, I expect, between python 2 and 3 for some syntax-stuff?)

MAYBE the fact that the modules have to be imported explicitly could be added to the wiki? Or maybe that is obvious to more professional programmers?

Either way I had lots of fun plugging a python-from-string into my graph for the first time yesterday and being able to autocomplete all the classes etc. I'd be absolutely lost without this, since I know almost none of the functions or methods yet, and I'm making up stuff as I go. Thanks a lot!

The only thing I am missing was the Math.MapTo function, even after searching through all the stubs. If I understood correctly, it isn't a standard function in NET, but was included by the Dynamo developers (see "11. built in functions" at the very end in dynamobim.org/wp-content/links/DesignScriptDocumentation.pdf) Maybe I need to find the relevant dll file and then generate stubs from that?

Thanks again.

[gtalarico]

am even using the ipy64.exe in autocomplete

This will work, but it should not help you access dotnet stuff, so I would recommend pointing it to a version of regular python 3 for better performance and stability.

Let see if I can explain what's happening behind the scenes to help you understand this better:

Python is a dynamically typed language, so it's hard for any editor or IDE to know what type a given object is, and it needs that to provide autocompletion. Most editors use python + a library called, which uses static code analysis to determine types and then query its methods and properties to offer autocomplete options.

In other words, when you use python autocomplete in editors like sublime, atom, and vscode, they stream your source code to whichver version of python they can find (using system, or allow you to point to one) and then use the Jedi Package to determine autocomplete options.

Pointing your autocomplete plugin to python 2, 3, or ironpython might work equally on some code but not others, it really depends on how successful the analysis within Jedi get's executed. Jedi does not execute the code, it only analysis it, so the python path version is not related to the python version your source code is targetting, but the engine Jedi will use to do its thing.

When it comes to .NET, the clr module allows IronPython to access objects inside Dlls. Only ironpyton can do that. But even so, Jedi will not understand clr and .NET specific module loading procedures, so you would not get autocompletion for objects inside those dlls anyway. Jedi Issues: https://github.com/davidhalter/jedi/issues/1197 https://github.com/davidhalter/jedi/issues/1197#issuecomment-412425693

That's where these stubs come in. They use a library call Generator3 to crawl through predefined dlls, and then create stub classes that mirror the objects inside the dlls property wise.. By adding the stubs to your autocomplete/jedi path, the stubs will trick Jedi into using the stubs as a source for the static analysis

Math.MapTo function

If it was added after I last generated these stubs it might be missing and the stubs need to be regenerated using the latest dlls.

I'd be absolutely lost without this, since I know almost none of the functions or methods yet, and I'm making up stuff as I go. Thanks a lot!

Don't forget you can always use print(dir(object)) or OUT = dir(object) (dynamo) to get available properties. Happy it helped

MAYBE the fact that the modules have to be imported explicitly could be added to the wiki? Or maybe that is obvious to more professional programmers?

Wildcard imports are not recommended but they should work with Jedi, but they don't because the stubs do not have that capability, so I will add a note. PS: If you haven't yet check out pep8's recommendations for imports and much more.

[gtalarico]

Added note to wiki on wild imports

[gtalarico]

https://github.com/gtalarico/ironpython-stubs/wiki#limitations

[johannesrave]

thanks a ton for the in-depth explanation! off to read pep8, and generate some stubs :)