I am sending data from Grasshopper to Python and I have some issues with the deserialization of objects made from child classes, such as Concrete (child of Material). When sending from Grasshopper, the speckle type is set as Objects.Structural.Materials.Material:Objects.Structural.Materials.Concrete. Then when deserializing in Python, it’s not able to figure out the type because it’s expecting Objects.Structural.Materials.Concrete, so we end up with a Base object as seen in the picture below.
I see that the speckle_type in the Core is intended to include the Base, so I suppose there’s a bug in specklepy?
I also just now looked a bit into specklepy and the type registry, and I think maybe there could also be issues with our custom Speckle objects library clashing with specklepy’s library, because it appears that all Objects.Structural.... types in the _type_registry are only our custom types, but there are no other Structural types from specklepy.
Edit:
So with the observation I made in the last paragraph, I believe there are two issues:
In the _type_registry the keys are never super class:child class, but only the child class
_type_registry is missing lots of types, maybe due to clashing libraries
Edit 2:
After diving into it a bit more I now realize that types from certain modules are simply not registered if the module is never imported manually by the user. So e.g. we have no types from Objects.Structural unless we import that module. So when we receive a stream that has Structural types, the way it works now is that we have to first import that module, which doesn’t really make sense to me
Than you for the detailed issue report. Your diagnosis of the issue is absolutely correct.
The reason for this behavior is python being an interpreted language, if a certain line of code is not read by the python interpreter, that code never executes. This results in the missing type definitions from the type registry, as you realized this yourself.
Great that it will be fixed! And it meantime we will indeed import the specific things we need.
However, this doesn’t address the first issue in the 1st edit, which is that the speckle_type definititon super_class:child_class is not handled in specklepy. In specklepy, the Concrete object is simply Objects.Structural.Materials.Concrete in the _type_registry, but in the Speckle stream the type is Objects.Structural.Materials.Material:Objects.Structural.Materials.Concrete
I have to say, its a bit embarrassing, because its a discrepancy between our SpeckleSharp/Core and specklepy implementations which I just pieced together.
While Core walks up on the inheritance chain to determine the speckle_type, specklepy doesn’t.
I’ve added this as a separate (urgent) ticket into our repo
Sorry for not getting the 1st issue faster, I see now how its breaking your workflow.
