fix default value of lists to not expand to N items in the generated code

[dirk-thomas]

For an example field uint32[10] foo the generated code look as follows:

Without this patch: self.foo = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

With this patch: self.foo = [0] * 10

And now imagine N being 134217728 as in ros/ros_comm#808 💣

I would propose to also backport this patch to Indigo and Jade after it has been merged.

[wjwwood]

+1

[ghost]

I'm having trouble today with a custom message that contains the field:

[test.msg]
std_msgs/String[2] strings

which I run genmsg_py.py on. When I instantiate this message in python, both objects in "strings" are the same object, so that I cannot set them to different values. Investigating the generated .py for the message, it has the syntax:

self.strings = [std_msgs.msg.String()] * 2

which seems like a mistake, where it should read:

self.strings = [std_msgs.msg.String(), std_msgs.msg.String()]

, say. Is this a rare case that hasn't yet been spotted? Or am I just using it wrong...

[dirk-thomas]

@benmitch Thank you for reporting this. This indeed is a regression of this patch.

In your specific example you shouldn't use std_msgs/String[2] for the field type. Instead of std_msgs/String you should use the primitive type string: so the field should be string[2] which doesn't have the problem.

But this is still a problem for any array of message types. Please see #74 which should address the problem for fixed-size arrays of non-primitive types.