# Why does rospy instantiate msg arrays as lists but deserialize them as tuples?

According to the ROS wiki page for msg,

In rospy, arrays are deserialized as tuples for performance reasons, but you can set fields to tuples and lists interchangeably.

I can't complain about the interchangability, but I'd expect that if msg arrays are deserialized as tuples, they would always be tuples unless the programmer explicity sets them to lists. However, I've observed that when instantiating a rospy msg using its empty constructor, any array fields are instantiated as empty lists. For example:

>>> from visualization_msgs.msg import Marker
>>> m = Marker()
>>> m.points
[]


This inconsistency means it's harder to write methods that deal with msg array fields because you have to expect the field to sometimes be an array and sometimes be a tuple. For example:

# list version -- only works if you know your marker was created by calling the constructor
marker.points.append(point)

# tuple version -- only works if you know your marker was created by deserialization
marker.points += point

# generic version
marker.points = list(marker.points) + [point]


A method that naively assumes list or tuple will work perfectly until the time you pass it the other. Then it's a long and painful bug hunt.

Just wondering, am I missing something here? Why was it designed like this? Is it a bug or a feature?

edit retag close merge delete

Sort by » oldest newest most voted

Arrays are easier to work with when constructing messages, since they can be dynamically appended to. Hence the use of arrays for newly created, empty messages.

Tuples are faster because they're a fixed size, but they can't be resized once created. Hence the use of tuples in the deserializer, where all of the array sizes are already known.

more

2

Not a Python expert, but could it also be the author(s) of rospy tried to convey the fact that on the receiving side msgs aren't really supposed to be changed? The immutability of tuples would seem to be a way to reflect that.

( 2015-09-18 01:45:41 -0600 )edit