Message field name same as python reserved keyword causes syntax error when importing generated message

[ErikOrjehag]

Bug report

Required Info:

• Operating System:
  • Ubuntu 18.04
• Installation type:
  • binaries
• Version or commit hash:
  • dashing
• DDS implementation:
  • Fast-RTPS
• Client library (if applicable):
  • rclpy

Steps to reproduce issue

msg-file with the following contents

geometry_msgs/Point from
geometry_msgs/Point to

Expected behavior

Import message containing field named "from".

Actual behavior

Gets python runtime error:

  File "/opt/dredgebot_ws/install/dredgebot_behaviours/lib/python3.6/site-packages/dredgebot_behaviours/actions/make_coverage_plan.py", line 22, in <module>
    from dredgebot_msgs.msg import LineSegment
  File "/opt/dredgebot_ws/install/dredgebot_msgs/lib/python3.6/site-packages/dredgebot_msgs/msg/__init__.py", line 1, in <module>
    from dredgebot_msgs.msg._line_segment import LineSegment  # noqa: F401
  File "/opt/dredgebot_ws/install/dredgebot_msgs/lib/python3.6/site-packages/dredgebot_msgs/msg/_line_segment.py", line 82
    self.from = kwargs.get('from', Point())
            ^
SyntaxError: invalid syntax

Additional information

The message file is built using colcon without issues but when the message is imported in python we get an runtime error as described above. We suspect that the keyword "from" is a reserved symbol in python which results in a "SyntaxError". Changing the name "from"--->"start" in the msg-file fixes the problem. We suspect that this is a problem with all reserved keywords in python such as "for", "in", "is" etc but have not tried.

[dirk-thomas]

Until a language specific name mangling is implemented to avoid keywords as described in ros2/design#172 your only option is to avoid using keywords in message definitions.

[samiamlabs]

A warning when building/generating the messages until that is implemented would be nice though. I don't know how common it is to use reserved keywords as filelds but it can be a bit tricky to understad the cause of this bug based on the runtime error messages.

[dirk-thomas]

A warning when building/generating the messages until that is implemented would be nice though.

That would indeed be nice (but probably also require most of the complexity an actual solution will require). Any pull requests towards this would be more than welcome.