This is actually not correct. Only floats-that-look-like-integers will pass as floats, which is what they are. Just like strings-that-look-like-numbers will pass as
str. Except if you set a specific Hint.
This is also not entirely true.
Grasshopper generally returns Polylines as curves, and therefore PolylineCurves, but strictly speaking it would not be obliged to. It’s a decision by David to make geometry always derive from GeometryBase for particular needs.
It’s just much easier to use
TypeHint => Polyline, and all the Grasshopper-specific conversions that are required to work to make your script fully compatible with Grasshopper will be given to you, free of charge. It’s actually not sufficient to call
PolylineCurve.TryGetPolyline() to fully support all polyline conversions.
Somebody might come up with some geometry type that has no Rhino.Geometry.Curve representation, but that might have a good polyline counterpart. For example, some type of Graph. In that case, their underlying type might not have a
TryGetPolyline() method, but would still be convertible if you just used the correct Hint.
This being said, I think this conversation has already lasted overly long. Many more times than you think, scripts with
No type Hint are not fully compatible with Grasshopper and become somehow impaired versions of normal components. For example, try inputting a Polyline where a
No type Hint script expects a float. Does it work, by computing the curve length? If not, the
No type Hint strategy will make your script not on-par with the general Grasshopper standard and, if the script is not only meant for you, it will make it just less robust.
You mention you are a newcomer to Python scripting in Grasshopper. As explained above, this is only sometimes a great decision. Please analyze case-by-case if this strategy is best suiting all your needs, including especially compatibility with the generous Grasshopper automatic conversion system.