Dear Ehsan Iran-Nejad (Lead Developer of the Rhino 8 Script Editor) @ehsan, and Giulio Piacentino (Creator of ghpythonlib and treehelpers) @piac,
Subjetc: Regression in Rhino 8 (Python 3): ghpythonlib type handling breaks code symmetry and treehelpers compatibility
I would like to report an interoperability regression when transitioning from the classic GHPython component (IronPython 2.7) to the new Grasshopper Python 3 component in Rhino 8. Whilst calling native Grasshopper components via ghpythonlib.components worked seamlessly in Rhino 7, the new environment introduces type-handling issues that disrupt code symmetry and workflow efficiency, particularly in educational contexts where code clarity is essential.
When attempting to build simple, modular functions to propagate geometry within Grasshopper, we encounter an underlying type-handling issue that affects all geometry types (Points, Curves, Breps, etc.):
1. The treehelpers incompatibility with native .NET collections: When a ghpythonlib function processes a list of objects (e.g. a list of points), it returns a native .NET collection (System.Collections.Generic.List). Because treehelpers.list_to_tree strictly expects native Python lists, it fails to parse the .NET collection and wraps the data as generic GH_Goo, leading to the standard “Data conversion failed from Goo to [Geometry]” error.
2. The inability to apply a universal, symmetrical workaround: To bypass the treehelpers issue, users are forced to explicitly cast outputs using list(). However, ghpythonlib simplifies outputs based on the input: if we pass a single item (like one Point3d or one Brep), it returns a single item rather than a collection. Calling list() on this output triggers a TypeError (e.g. 'Point3d' object is not iterable).
This structural behaviour forces users to write asymmetrical, type-checking code: one approach for functions handling single items, and a different approach for functions handling lists.
In Rhino 7 (IronPython 2.7), this data bridge was seamless. The DLR handled the .NET collections automatically, and list_to_tree accepted ghpythonlib outputs directly, allowing for clean, universal functions regardless of whether the input was a single item or a list.
Could you look into updating treehelpers so it can natively recognise and parse .NET IEnumerable types, or update ghpythonlib to cast these collections back to native Python lists? Addressing this at the core level would restore the workflow parity we had in Rhino 7 and greatly improve code readability for all developers and students.
Thank you for your time and the continuous improvements to Rhino 8.
Kind Regards,
Gonçalo Castro Henriques, UFRJ - Federal University Rio de Janeiro
