Specklepy ICurve backward compatibility (v2 -> v3)

Rob · 10 June 2026 12:59

Hi Specklers, @gergo,

I’m converting our in-company Python package from Speckle v2 to v3. This has actually been pretty simple so far, so that’s the good news. For it, I’m looking into backward compatibility, i.e. being able to import ‘old’ v2 data into our updated package, which apart from the Speckle dependency update still has the same object structure. As there aren’t extensive changes between the Speckle versions, this is actually working pretty well, except for one issue in the specklepy source code:

The domain setter in the ICurve interface:

github.com/specklesystems/specklepy

src/specklepy/objects/interfaces.py

75f3eddd0


      
              @abstractmethod
              def length(self) -> float:
                  pass
          
              @property
              def domain(self) -> Interval:
                  return self._domain
          
              @domain.setter
              def domain(self, value: Interval) -> None:
                  if not isinstance(value, Interval):
                      raise TypeError(f"Domain must be an Interval, got {type(value)}")
                  self._domain = value
          
          
          class IDisplayValue(Generic[T], metaclass=ABCMeta):
              @property
              @abstractmethod
              def displayValue(self) -> T:
                  pass

The problem is that this domain attribute was allowed to be None in Speckle v2. As for our use case, it wasn’t important, we simply left it to None without issues. However, in Speckle v3, with the current strict setter, this directly raises a TypeError during receiving. This means I can’t receive any old data that has some geometry defined that implements the ICurve interface. I did a quick update myself in the source code locally, and by only loosening this setter, my tests that import old data pass without issues. Simple solution could be to loosen the setter, or to call the default_factory when the domain is None.

Anyway, the solution would be pretty straightforward, so it mostly boils down to the intentions you have for Speckle v3:

Do you intend full backward compatibility for Speckle v2 → v3?
Or, if useful, could you agree on minor tweaks (as suggested here), to make it backward compatible for those that need it?

Let me know, I’d be happy to make a PR myself if that would be convenient!

Rob · 25 June 2026 16:10

@jonathon, @gergo, are you the right Specklers to tag for this?

Jedd · 25 June 2026 16:16

Sorry @Rob for the delayed response.

Do you intend full backward compatibility for Speckle v2 → v3?

When we first released v3 connectors, we did advertise some level of backwards compatibility. It was never described as “full backwards compatibility”, and had serious limitations, and did not support absolutely every v2 commit ever made.

Since then, v2 has fallen off the radar, our SDKs and connectors have continued to evolve, which has pushed more of v2 → v3 flows into undefined or broken areas.

To that end, I’m tempted to suggest we don’t make any changes to current v3 SDKs/connectors to support v2 → v3 flows. Just fixing this one problem with curves may not be enough, v2 was notorious for allowing invalid data to be sent without warning, depending on the model, there’s a good chance other incompatabities will surface.

Happy to discuss more if other members of the team have a different idea.

Rob · 1 July 2026 14:16

Thanks for your response @Jedd.
I can see your reasoning, it makes sense.

For our data, it seems that fully custom objects without any geometry are still backward compatible, which makes sense. Any native, geometry-like objects are generally not, due to these setters / validators that invalidate some of the old object data, directly breaking de-serialization. We’ll have to deal with that as a serious limitation to backward compatibility for our data.