Hi everybody,
Referring to the ghPython component, I don’t like using the “type hint” option because I don’t find it intuitive as its outside the code itself and I also read somewhere that it makes the component perform slower. So me question is then, how can I input an internalized curve for example, without using the type hint “curve”?
Thank you.
HI Sup
You can use the rs.coercecurve() function to generate the Curve type.You can use the rs.coerce3dpoint() function to generate a Point3d type.and so on .like this
This is my file：
GUID.gh (3.8 KB)
You are right. This is a Grasshopper option, not a Python option, natively. But this makes working in Python with Grasshopper MUCH more useful for your users. Think about that. If you write code for yourself only, then it might be OK not to use it.
The only way to know is to profile. Without profiling (checking times) it makes no sense to compromise usability.
You cannot.
Explicit type hints can indeed be costly with large input lists (see this old thread), which is one of the reasons that I’d prefer an option to set the default typehint to No Type Hint, which will pass along data as whatever it is (I believe this should also work in your case, if I understood you correct).
Guys — hints are a first-level Grasshopper feature in GH1. You may or may not like it (I have mixed feelings), but so it is.
When your component expects a floating point number and your user inputs a curve, you must compute the length and use that length as a value. Becoming red and printing an error (failing to use hint coercion) will make your component a special case and non-standard in the Grasshopper environment.
In general, creating non-standard components is not a good plan.
I personally don’t like it (because I prefer writing straight up RhinoCommon and have profiled it and found it to be needlessly slower) and simply ask for the option to set the (i.e. my) default type hint to No Type Hint, which is not asking/making a non-standard component IMO (I might be missing something here 
). I apologise if I’ve caused any confusion previous with this, but I’m not sure how much more explicit I can state this wish.
I am sorry about that. Well, maybe GH2 will had different type conversion rules. And they may (or may not) be less impacting on performance. Still, a good Grasshopper developer, develops components with these in mind. (Some ad-hoc exceptions might be OK when performance is paramount).
Let’s see examples…
If you use No Hint, and internally your class expects a Rhino.Geometry.Brep object, and your user inputs a closed planar Rhino.Geometry.Curve, your component will not work. If, on the other hand, you use the right Type Hint (Brep), the Curve will be converted to a Brep before it is passed to the component. Your code will only have to deal with the Brep case.
You are creating something similar to the ‘UnitX vector’ component… If your input ‘F’ has Type Hint set to ‘float’ and your user inputs a curve, its length is computed. This will work in the same way as the native component. If your component does not use Hints, then it’s (slightly, or heavily, depending on how ‘important’ the conversion is) non-standard. Or you will have to check the type of the input, then if it’s a curve compute its length, for a brep compute the area, for an interval compute the span, ect… very boring code.
We fully understand your wish, but Grasshopper works in a specific way and replacing the logic will not work at this point of its release cycle. There’s the option to allow to switch to another default. But which one? not No Hint by default, because of the examples above. Actually helping users choose the ‘right’ Hint is the best we can do to beginners and for developers alike.
Finally, if you create a lot of ‘your own’ types or really want to go for custom behavior, then No Hint will make sense for you. In that case, then we may probably add an option for a default. It’s a wish, and it’s possible… and it’s here.
There is also an easy way to fix this if you really hate this default (please: develop with the conversion standards in mind). You can use this “PyN” component (user object with two type hints set to ‘No type hint’). Or create your different default component that you better like (different starting text, different hints, different names…).
Python No Hint.ghuser (2.2 KB)
Which is the default your are talking about? In mine (not the lastest version) it is ghdoc Object when geometry (rhinoscriptsyntax) (not sure what that means).
But if I leave it there and use 603419608’s suggestion of rs.coerce it works fine.
I understand what you are saying about the type hint, and it makes total sense when developing components or code intended to be used by other users. In my case I am writing for myself so maybe they don’t apply that much…
They may indeed, never come across the opposite.
I always document the expected input/output type/access mode on the hover-over parameter documentation through the (brilliant) docstring system. Which helps to both inform the user and means that one can read/understand the parameters by simply reading the source code (i.e. not having to hover over them). Less mouse/hovering/waiting annoyance, more fast/snappy keyboard funz (plus it’s great for versioning/documentation straight to .py files).
I realise that this is hardly a “standard” development methodology, but it is one that has been working very nicely for us over the past couple of years (where I increasingly use GH pretty much as an awesome GUI/DAG for accessing RhinoCommon through GHPython, yielding a fast, highly dynamic and interactive workflow). So perhaps we need to differentiate between generic compiled GH components (to which I absolutely agree that one should follow the standard behaviour(s)) and these more context/project specific scripting components written on the fly and not used by a generic “user”, in order to have a meaningful discussion about this (same for the rhinoscriptsyntax vs rhinocommon debate). It’s really rather apples to oranges in terms of usecases.
Which is why I (as the user knowing what I want) simply want the option to set my personal user default, so that I can skip all the mousey/hovery/clicky-clicky stuff.
And apologies for being annoying about this again, owe you a beer next time IRL 
Edit:
That’s a decent workaround (didn’t even consider this!), but still new ZUI inputs will default to ghdoc object no?
Did you check the user object?
Yey, Friday night’s coming! 
Don’t worry about that, it’s nice to have some thorough thinking and discussion for all details.
Im sorry to bring back this thread, but I have another related doubt:
The script below was not working because the “PointNum” variable expected an integer and it got a float (60.0).
Runtime error (TypeErrorException): range() integer end argument expected, got float.
Traceback:
line 8, in script
I solved this by plugging an “Integer” component. But how can this be solved inside the code? Isn’t there a way to tell Python that that is an integer? (Without the type hint of course)
Integer.gh (6.7 KB)
most straightforward way would be:
iSdX = int(SdX)
but that still can fail if you put in data that can’t be simply cast like that.
edit: for instance if you input strings that can represent floats it makes sense to do something like
iSdX = int(float(SdX))
Seriously, please use the int ‘Type Hint’. It is meant exactly for this. As an example, if you input a string, its text is converted to an integer and the value is used. If you input a vector, its length is computed and used as an integer value. This is how Grasshopper should work.