> ROS messages are strongly typed. It's not really a question of Python
> favoring duck-typing, because it has to express the type and
> dependency requirements of what it interfaces with.
the original request was to add a some user transparency to types by
making the service_class field optional in the ServiceProxy class.
this is possible because rospy can deduce the ros service type from
the handshake.
rosen,
PS: it is interesting you mention Google Protocol Buffers; it seems
that the usage and functionality of ros messages is converging to
them.
>> There are cases where being able to call a service without knowing its
>> type could make it robust to the plethora of custom messages created
>> by ROS users.
>>
>> As for overlooking package dependencies, with python this is not a
>> problem. If the package path is sent with the type, then rospy can
>> auto-generate the python class without relying on a pre-generated
>> class to include; and I'm sure you can come up with a caching scheme
>> to make this quicker the next time around.
>
> Google Protocol Buffers do auto-generate the Python class from their
> description, so it is a possibility. However, the predominant request
> I get is to make rospy have better performance and less latency. I'm
> exploring whether or not rosh provides a natural boundary to express
> these opposing requirements.
>
> - Ken
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
(text/plain)