GH component attributes not accessible from CPython 3 components

[James_Parrott]

I’ve noticed another quirk between Iron Python components and CPython 3 components. This is much more impactful, than having to adjust for types when returning a list. I don’t know how the internals of Pythonnet work, but it’s strange that type returns the GH API interface class, not the concrete implementation as from IronPython.

GH_Doc = ghdoc.Component.Attributes.DocObject.OnPingDocument()

comp  = next(comp 
             for comp in GH_Doc.Objects 
             if comp.NickName == x)

print('Type: %s' % type(comp))
print('__class__: %s' % comp.__class__)

try:
    comp.Params
    print("Accessed Params of component: %s" % comp)
except AttributeError:
    print("Could not access Params of component: %s" % comp)

Perhaps I’m expecting too much from the Pythonnet interop magic (or it’s just not possible or not desirable), but this is number 1 on my wish list.

A really great thing about Grasshopper is the API, that makes it possible to carry out almost anything, in Python or C# code, that an ordinary user can do manually. I’ve posted an example of “remote controlling” a completely external component, from an Iron Python component.

Issues with Passing Outputs Between Clusters in Python Script

I haven’t tried this with Clusters, with a heavy workload or with anything complicated yet, but thanks to your code, I’ve been able to ‘remotely’ run an external component in Grasshopper, from an Iron Python 2 one. So thanks very much! It feels safer to store external components in separate files. But all of those must be opened first, and the one with the controller only opened afterwards. import os import Grasshopper import rhinoscriptsyntax as rs def GH_doc_components(doc): retu…

This very closely (if not exactly) replicates in code, precisely how end users interact with a plug-in’s components. It could be used as a poor man’s Node-In-Code. Ordinarily I discourage writing code simply to re-implement what can already be done in Grasshopper. But my point is, if it was possible to write a callable that runs an external component (or chain of components) from a CPython 3 component (as well as from an Iron Python 2 one as it already is), then the entire Python 3 ecosystem of tooling and testing (e.g. my preferred tools are Pytest and Hypothesis) would be available to Grasshopper users and plug-in developers alike (working in any supported language, not just Python). Python 3 testing tools would not be limited to test Python 3 code as at present, but could also be used to test any Grasshopper component (that could be written in C# or VB as well as Python), with the Grasshopper input and output Params, the component environment, and any other components, native and third-party components, and Grasshopper connections all in the loop too.

Access_another_components_params_from_Python_comp.gh (14.4 KB)

[scottd (Scott Davidson)]

Yes, PythonNet returns the instance, not the parent class. But there are some ways to deal with that. There is quite a discussion about it here:

Change specific panel color from C#/Python component

I applied a fix for this type check problem. It’s not perfect but the problem area is complicated especially between how IronPython used to work and how Python 3 interop with dotnet runtime is expected to work. This code works now: for obj in gh.Instances.ActiveCanvas.Document.Objects: if isinstance(obj, gh.Kernel.Special.GH_Panel): if obj.NickName == Panel: obj.Properties.Colour = Color type(obj) is gh.Kernel.Special.GH_Panel will not work because the returned object …

[James_Parrott]

Cheers Scott - I missed that one with my search. This issue is basically a duplicate of RH-81135.

I’ll make do with good old unittest.