GHPython Default Type Hint

Exactly, an admirable goal to which adding the option to set default type hint would help greatly :raising_hand_man:

If I may weigh in, as I kinda fit in all groups of users.

What about leave the hints as they are, making a checkbox somewhere to keep the set hint as default and put it somewhere inside guid-named xml file in an undisclosed location? Reading the setting upon launch of Grasshopper, to reduce slowdown in performance. Respectively if you set a new default hint a Rhino restart to be required.

As for the part of me that is still quite noobish in programming. How difficult would it be, or how much slowdown in performance could be expected, if you using reflection and (for the most inexperienced) set the type depending on whatever comes in with the wire? Another check box somewhere in the menu, a “Noob mode” if you will?

1 Like

We will probably go with something in this direction after all. A per-component default Hint, that can be saved and loaded. This way, I think we will cover more ground with less confusion.

This might not be necessary, we will see.

This has a lot of “what ifs” associated with it. What if some numbers are ints, some are floats? What if some text looks like number (but is still text)? This might be a playground for some users who want to write some special-purpose plug-in, but generally I think that the user can just demonstrate design intention and pick the right Hint. It’s not that bad.

2 Likes

I doubt noobs will try to implement “special” stuff. :slight_smile:
As for the “what ifs”. To me an integer is an integer if you pass 1 from a panel then it’s “1” and it should be considered as a string.

image
image
image


That’s mathematically an integer but type-wise it’s a float. For Grasshopper. “Rounding” affects the rounding, not the type. I am not sure why it was chosen this way, but such is @DavidRutten’s design.

Yes, but not everyone would agree I think. Especially the “noob” you wish to help. If you pick the right Hint, it will be just converted to the right type and passed to you in the right form. For the computation-time savvy guys: this costs in terms of computation if the conversion happens, if it doesn’t need to happen, then it’s just a quick type check.

That would disregard a widely used precedent, since panel values are treated as numbers when used as inputs to most standard components.

We’re talking about GhPython only @Joseph_Oster.

I’m not, and I’ve followed this thread from the beginning, thank you very much.

The thing is “noobs” rarely change the Type Hint of GhPython, if it has to be adjusted for them without thinking about it they hook up a wire to GhPython and don’t ever consider changing the type hint. Then there has to be some rules these users must follow.

“1” is a string - is one of those supposed rules.

Also there are, even now, issues that arise from using numbers passed directly from panel. This is something that is mentioned in many tutorials and courses. One should use number slider, digital scroller, etc. or must pass the wire through one of these:

image

If the proposed “noob mode” is unchecked pass whatever you like and be sure to set the proper Type Hint.

Hi Giulio, apologies for reviving this one. I was just wondering if this has seen further attention?

For context: I’ve been running our inhouse GHPython training courses. And have structured the order of information to not introduce rhinoscriptsyntax until we start fiddling with the Rhino document. Meaning the participants can ignore learning about GUID/coercing till after understanding basic Python and RhinoCommon geometry types. Which is of course problematic with the hardcoded default type hint being what it is.

Hi @AndersDeleuran, I’m no longer on this project - it’s been so for two years. I’m still providing some support when I can. You can @-mention @eirannejad or @Alain about this.

1 Like

Hi Anders,
I added the items discussed here to my list.
I can’t promise how soon I’ll get to it but I’ll do my best.

1 Like

Cheers Alain, that’s great to hear. Much appreciated :beers:

RH-54143 is fixed in Rhino 7 Service Release 25 Release Candidate

1 Like

It’s great to see this get some attention. That said, this new feature (i.e. copying type hint of neighboring inputs) does not address/resolve the topic issue, as the default type hint is still hardcoded to ghdoc Object when geometry (rhinoscriptsyntax):


One solution might be to simply add a toggle here that says No default type hint:

Also, I might be misunderstanding it, but this new feature does not appear to work 100%. It’s also ambiguous which neighbour a new input parameter is suppose to copy from:

Hi,

The description doesn’t describe well what’s going on. I’ll change it.

Changing the default was not an option so the default hint is still the same.

Like you say determining which neighbour to copy from would be ambiguous so the way it works is that if a GhPython component’s input parameters are all set to “No Type Hint” then any parameter added after that will be set to “No Type Hint”.

This seems to be a reasonable way to solve the problem without any disruption.

1 Like

Although obscure, this does appear to work as intended and will definitely reduce the manual type hint setting.

I just tested it this morning on the project I’m working on. And got this error while adding/removing input parameters, after which the GHPython component quickly flashed white. Not sure if this is related to this new feature, but I’ve never experienced it before:

1 Like

That problem doesn’t look related the new feature but it’s not impossible. So far I haven’t been able to reproduce it. Can you easily reproduce it?

No I only get it the one time. Will be sure to report back if it happens again and I can reproduce it. Thanks again.

1 Like

RH-54143 is fixed in Rhino 7 Service Release 25