Some questions about the Python stubs and API docs

[jgillmanjr (Jason Gillman Jr.)]

Hello!

While I was reading the article about programmatically creating and assigning specific materials that @nathanletwory wrote (thanks, by the way!), I had a couple questions as a result of PyCharm nagging at me, as well as looking at the actual API documentation.

To be clear - the script I wrote seems to be working just fine, I just had questions. I’m not sure of the best way to organize this post so… here we go!

Material GUIDs
In the article, Rhino.Render.RenderMaterial.PaintMaterialGuid was referenced, however in my cases I was looking for the emission type - no big deal as I found it in the Rhino.Render.ContentUuids class.

When passed in as an argument, it’s being seen as a property vs. the expected RenderContent type. I’m not the smartest guy, and admittedly I don’t use the @property decorator all that often, but it looks like that decorator is also used in the RenderMaterial class. Is ithe difference in behavior (no error was thrown when using the PaintMaterialGuid property) because RenderMaterial is subclassing RenderContent?

ShowContentChooserFlags and ChangeContexts
As for Rhino.Render.RenderContent.ShowContentChooserFlags.None, that is being viewed as Any by the method. Doing some investigation, ShowContentChooserFlags doesn’t show as a member of that class in the stub library. But the thing that confused me was that it doesn’t show as a member of that class in the API documentation either.

Rather, the docs show it as an enumeration called RenderContent.ShowContentChooserFlags under the Rhino.Render module/namespace, while in the stub library it just lives as a class under the Rhino.Render module.

Same situation for RenderContent.ChangeContexts

Is this just a limitation of stubbing out .NET in Python? I did notice that the None attribute was commented out for ShowContentChooserFlags, which does make perfect sense.

Hopefully the above doesn’t appear too derpy. I’ve never really done any .NET development, while on the inverse, I use Python almost daily, so this had me scratching my head.

Thanks for any insight!

-Jason

[nathanletwory (Nathan 'jesterKing' Letwory)]

@jgillmanjr

When passed in as an argument, it’s being seen as a property vs. the expected RenderContent type. I

I think PyCharm is probably getting confused between all the different Rhino.Render.RenderContent.Create signatures. Maybe the fact that you use named parameters isn’t helping. Perhaps PyCharm is happier if you leave out the parameter names (type=, flags=, doc=)?

@jgillmanjr

But the thing that confused me was that it doesn’t show as a member of that class in the API documentation either.

ShowContentChooserFlags is an enum, not a class. and most certainly None is a member of that enumeration: https://developer.rhino3d.com/api/RhinoCommon/html/T_Rhino_Render_RenderContent_ShowContentChooserFlags.htm. This leads me to believe you are using something different to rely on for your API documentation.

Are you by any chance using GitHub - gtalarico/ironpython-stubs: Autocomplete stubs for common IronPython/.NET libraries for the stubs? If so this is quite outdated, as they are based on Rhino 5. You should update the stubs to reflect the very latest Rhino 7 service release. There are some (very light) instructions on the README of that repository how to build updated stubs. You’ll have to edit https://github.com/gtalarico/ironpython-stubs/blob/master/ironstubs/default_settings.py to ensure the correct Rhino 7 install location is used. With updated stubs also the Create method signatures will be most likely identified better.

[jgillmanjr (Jason Gillman Jr.)]

@nathanletwory

I think PyCharm is probably getting confused between all the different Rhino.Render.RenderContent.Create signatures. Maybe the fact that you use named parameters isn’t helping. Perhaps PyCharm is happier if you leave out the parameter names ( type= , flags= , doc= )?

It seems to have the signatures fine, but just complaining about the (what it’s seeing as) wrong types being used as args.

@nathanletwory

ShowContentChooserFlags is an enum, not a class. and most certainly None is a member of that enumeration: RenderContent.ShowContentChooserFlags Enumeration. This leads me to believe you are using something different to rely on for your API documentation.

In the documentation, you are correct, it shows as an enum named RenderContent.ShowContentChooserFlags in the Rhino.Render module, however in the Ptyhon stub library it just shows as a class (presumably because enums aren’t a “standard” thing in Python - but that’s only a guess).

This is the stub library I’m using: GitHub - mcneel/pythonstubs: Python stubs for .NET assemblies

Here’s a link to the line for ShowConentChooserFlags in the github repo.

Of course with that said, this probably won’t be much of an issue for long since you guys are bringing CPython support into version 8