Closed haixuanTao closed 2 weeks ago
Ezisting code will continue to work!
Except for ros2-bridge where you will have to change data.inner()
-> data["value"]
but I think that it is still okay as a breaking change
Ezisting code will continue to work!
Except for ros2-bridge where you will have to change
data.inner()
->data["value"]
but I think that it is still okay as a breaking change
Ok great! The ROS2 bridge change is fine I think given that we still consider it experimental.
Ezisting code will continue to work! Except for ros2-bridge where you will have to change
data.inner()
->data["value"]
but I think that it is still okay as a breaking changeOk great! The ROS2 bridge change is fine I think given that we still consider it experimental.
Yup. It makes the current implementation of the ros2-bridge closer to the rest of dora API
…ebuggability.
Currently having a custom PyEvent make debugging very hard as fields are hidden within the class PyEvent that is defined within Rust Code.
Python user are getting really confused about this obscure class.
This PR transforms the class into a standard python dictionary.
It also makes external event and dora event expose the same user API meaning to access the data people just use:
data = event["value"]
instead ofdata = event.inner()