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!